Technologies informatiques,
Recherche et développement

Outils pour utilisateurs

Outils du site

Vous êtes ici : index » doc » formations » hebergement » service » apache
Piste :
doc:formations:hebergement:service:apache

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
doc:formations:hebergement:service:apache [2021/08/30 17:05] – [Sous Apache] jeremiedoc:formations:hebergement:service:apache [2023/07/03 12:35] (Version actuelle) – [serveur web NGINX] jeremie
Ligne 108: Ligne 108:
 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 ====
Ligne 132: Ligne 136:
   #!/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!):
Ligne 188: Ligne 193:
 </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 ====
  
Ligne 345: Ligne 349:
 ==== 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.+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>
Ligne 365: Ligne 373:
  </Location>  </Location>
  
- <Location "/">+ <LocationMatch "^/(?!\.well-known/)">
  Order Deny,Allow  Order Deny,Allow
  Deny from all  Deny from all
  Allow from 127.0.0.1  Allow from 127.0.0.1
  Allow from 192.168.1  Allow from 192.168.1
- </Location>+ </LocationMatch>
  
 </VirtualHost> </VirtualHost>
 </code> </code>
  
doc/formations/hebergement/service/apache.1630343127.txt.gz · Dernière modification : 2021/08/30 17:05 de jeremie