Proxyfier un site et subpath différent

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<VirtualHost *:8080>
  ServerName DOMAIN.FR

  SSLEngine on
  SSLCertificateFile    fullchain1.pem
  SSLCertificateKeyFile privkey1.pem

  SSLProxyEngine on
  SSLProxyVerify none
  SSLProxyCheckPeerCN off
  SSLProxyCheckPeerName off
  SSLProxyCheckPeerExpire off
  ProxyPreserveHost off
  ProxyRequests on

  ## Root path
  ProxyPass / https://<https website>/
  ProxyPassReverse / https://<https website>/
  

  ## Root subpath with websocket application
  ProxyPass /subpath/api/websocket ws://localhost:5800/api/websocket
  ProxyPassReverse /subpath/api/websocket ws://localhost:5800/api/websocket
  ProxyPass /subpath/ http://localhost:5800/
  ProxyPassReverse /subpath/ http://localhost:5800/
  RewriteEngine on
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /subpath/(.*)  ws://localhost:5800/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /subpath/(.*)  http://localhost:5800/$1 [P,L]
  
</VirtualHost>

Proxification derière un proxy existant (Apache < 5.2)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

<VirtualHost *:443>

  ServerName DOMAIN

  SSLEngine on
  SSLProtocol -ALL +TLSv1.2
  # New cipher suite optionnal
  SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
  SSLHonorCipherOrder on
  SSLCertificateFile "CER.pem"
  SSLCertificateKeyFile "KEY.pem"
  SSLCACertificateFile "ca_SSL_chain.pem"

  ProxyPass / http://localhost:8081/ nocanon
  ProxyPassReverse / http://localhost:8081/
  RequestHeader set X-Forwarded-Proto "https"
  AllowEncodedSlashes NoDecode
  ProxyPass /subpath/ https://<https website>/
  ProxyPassReverse /subpath/ https://<https website>/

  SSLProxyEngine on
  SSLProxyVerify none
  SSLProxyCheckPeerCN off
  SSLProxyCheckPeerName off
  SSLProxyCheckPeerExpire off
  ProxyRemote https://<https website>/ 'http://<proxy_url>:<proxy port>'
  ProxyPreserveHost Off
  ProxyRequests Off

  RewriteEngine On
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /subpath/(.*)  https://<https website>/$1 [P,L]

  <Proxy https://<https website>/>
    Order deny,allow
    Allow from all
    SetEnv Proxy-Chain-Auth On
    RequestHeader set Proxy-Authorization "Basic <base64 encoded usrname:password>"
    #SetEnv proxy-initial-not-pooled 1
  </Proxy>

  ErrorLog logs/error_log
  CustomLog logs/access_log common

</VirtualHost>

Montage d’une pipeline DevOps pour Let’s Encrypt

Afin de faciliter mes futurs projecs et de pouvoir les sécuriser, j’ai décider d’utiliser Let’s Encrypt de façon automatique.

Il était déja possible d’utiliser Let’s Encrypt pour certifier un nom de domain ou sous domaine, aujourd’hui il est possible de certifier via un wilcard, ce qui nous permet de couvrir le totalité des nom de domaines / sous-domaines et futurs sous-domaines sous la forme *.mon-domaine.fr

Integration de Let’s Encrypt dans une pipeline

Avec ce concept de wildcard, il est maintenant possible de gérer un seul certificat pour l’ensemble des domaines, ce qui automatise déjà la création d’un certificat par projet.

Pour automatiser cette génération, j’ai intégré Let’s Encrypt dans une pipeline Gitlab-ci, ce qui permet de nous passer d’un serveur pour le faire.

=> Lien vers le job de la pipeline de génération

Cette Pipeline est appellée automatiquement tous les 1er du mois avec Gitscheldule (semblable à cron).

Déploiement et livraison des certificats

Avec cette Pipeline Gitlab-Ci, une partie n’est pas couverte, c’est celle du chargement du certificat sur le serveur de l’application.

Deux cas sont étudiées:

• Site hebergé avec Git-Pages, comme ce porte folio, les certificats doivent donc être poussés vers Gitlab directement
• Site hebergé sur un serveur classique, il faudra donc pouvoir récupérer les fichiers directement et les faire portés par apache/nginix etc..

Cas Gitlab-Pages

Gitlab Fournit une Api avec laquelle il est possible de pousser directement les certificats sur un domaine associé.

J’ai donc développé un script qui parcours la totalités de mes projets Gitlab, cherche si ils contiennent des Gitlab-Pages et si ils sont attachés à un nom de domaine.

Dans ce cas le certificat est récupéré de la pile de cache de la pipeline Let’Encrypt et est poussé directement par api sur le domaine du Gitlab-page.

=> Lien vers le script

Cas récuperation des livrables

Afin de pouvoir récupérer les certificats pour pouvoir les exploiter sur un autre serveur, j’ai utilisé les artifacts dans la pipeline Gitab-Ci.

La fonction artifacts permet d’archiver un contenu présent dans un job Gitlab-ci et de le proposer en téléchargement une fois la pipeline terminée.

Cette fonction peut être utile dans de nombreux cas, par exemple récuperer les sources/livrables d’une complation, récuperer des logs etc..

Il est donc possible de récuperer les certificats génénerés via l’interface Gitlab ou par API, c’est cette dernière qui nous intéresse.

Effectivement il suffit d’ajouter la commande suivante dans une tache cron mensuelle sur le serveur en question, et les certificats seront automatiquement actualisés

1

curl --output certificats.zip -L --header "PRIVATE-TOKEN: $TOKEN" https://gitlab.com/api/v4/projects/8641028/jobs/artifacts/master/download?job=certbot-renew

=> Lien vers le job de la pipeline de déploiement