Apache2 tips & tricks

Web

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
46
<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>


Pipeline Devops pour Let's Encrypt

Web

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