Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
doc:formations:hebergement:service:apache [2021/08/30 18:10] – [Sous Apache] jeremie | doc:formations:hebergement:service:apache [2023/07/03 12:35] (Version actuelle) – [serveur web NGINX] jeremie |
---|
C'est devenu simplissime avec Letsencrypt (un consortium solide qui founit des certificats gratuits tout à fait valables): | C'est devenu simplissime avec Letsencrypt (un consortium solide qui founit des certificats gratuits tout à fait valables): |
| |
add-apt-repository ppa:certbot/certbot | apt install certbot python3-certbot-nginx # nginx pour nginx, logique |
apt install python-certbot-apache # a) si vous utilisez Apache2 | |
apt install python-certbot-nginx # b) si vous utilisez nginx | # Ou pour la toute dernière version: |
| # add-apt-repository ppa:certbot/certbot |
| # apt install python-certbot-apache # a) si vous utilisez Apache2 |
| # apt install python-certbot-nginx # b) si vous utilisez nginx |
| |
Il faudra vérifier la validité du ''ServerName mondomaine.com;'' dans ''/etc/apache2/sites-available/your_domain.conf'', puis recharger éventuellement apache avec ''systemctl reload apache2'' | Il faudra vérifier la validité du ''ServerName mondomaine.com;'' dans ''/etc/apache2/sites-available/your_domain.conf'', puis recharger éventuellement apache avec ''systemctl reload apache2'' |
| |
:!: il est recommandé d'écrire le "your_domain.conf" sous une forme exacte, par exemple "sub.domain.com.conf". On évite des ambiguités ainsi et on permet l'automatisation des certificats (ci-dessous). | :!: il est recommandé d'écrire le "your_domain.conf" sous une forme exacte, par exemple "sub.domain.com.conf". On évite des ambiguités ainsi et on permet l'automatisation des certificats (ci-dessous). |
| |
| |
==== Création et installation ==== | ==== Création et installation ==== |
#!/bin/sh | #!/bin/sh |
# vive linux | # vive linux |
certbot -q --nginx $(grep server_name /etc/nginx/sites-enabled/*|grep -v fastcgi|sed 's/.*server_name \(.*\)\s*;\s*#*.*/\1/'| tr ' ' '\n'|sort -u|grep .|xargs -L 1 echo -n " -d") | # Retirez le -q des options de certbot pour une version avec confirmation |
| xargs -a <(sed -n 's/^\s*[^#]server_name\s*\([^;]*\)\s*;.*/ -d \1/p' /etc/nginx/sites-enabled/*|sort -u) certbot --nginx |
| |
Voilà en outre un exemple de définition de site avant le passage de certbot (toujours pour nginx!): | Voilà en outre un exemple de définition de site avant le passage de certbot (toujours pour nginx!): |
</code> | </code> |
| |
**Remarque**: le robot letsencrypt fonctionne en "posant" un fichier de validation dans un dossier ''.well-known'' à la racine du site, puis tente d'y accéder en HTTP depuis l'extérieur. S'il y a une configuration qui l'en empêche, on peut le rediriger et se faciliter la vie avec une clause dédiée de ce type (dans le "listen" HTTP port 80): | **Remarque**: le robot letsencrypt fonctionne en "posant" un fichier de validation dans un dossier ''.well-known'' à la racine du site, puis tente d'y accéder en HTTP depuis l'extérieur. S'il y a une configuration qui l'en empêche, on peut le rediriger et se faciliter la vie avec une clause dédiée de ce type (dans le "listen" HTTP port 80). Si le root est var/www/html (par défaut): |
| |
location /.well-known/acme-challenge/ { | location /.well-known/acme-challenge/ { |
# This path must be served over HTTP for ACME domain validation. | alias /var/www/html/.well-known/acme-challenge/; |
# We map this to a special path where our TLS cert provisioning | |
# tool knows to store challenge response files. | |
alias /home/user-data/ssl/lets_encrypt/webroot/.well-known/acme-challenge/; | |
} | } |
| |
| |
==== Redirection forcée vers HTTPS ==== | ==== Redirection forcée vers HTTPS ==== |
| |
==== Sous Apache ==== | ==== Sous Apache ==== |
| |
Exemple complet de proxying vers un Nextcloud restreint au LAN, qui tourne dans un docker sur le port local 12345, et qui est associé à un sous domaine dédié "files.monsite.com". :!: l'exécution du script ''certbot'' de Let's Encrypt se chargera du reste de la configuration HTTPS. Le ''DocumentRoot'' ne sert réellement qu'a la vérification du challenge de celui-ci. On peut les tester avec ''certbot %%--%%apache %%--%%dry-run certonly -d files.monsite.com'': | Exemple complet de proxying vers un Nextcloud restreint au LAN, qui tourne dans un docker sur le port local 12345, et qui est associé à un sous domaine dédié''files.monsite.com''. |
| |
| L'exécution du script ''certbot'' de Let's Encrypt se chargera du reste de la configuration HTTPS. On peut les tester avec ''certbot %%--%%apache %%--%%dry-run certonly -d files.monsite.com''. |
| |
| :!: à noter le ''DocumentRoot'' qui ne sert ici qu'au test du challenge (il peut se trouver n'importe où ''www-data'' pourra écrire temporairement). |
| |
<code> | <code> |