One place for hosting & domains

      héberger

      Comment héberger un site web en utilisant Cloudflare et Nginx sur Ubuntu 18.04


      L’auteur a choisi la Electronic Frontier Foundation comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Cloudflare est un service qui se situe entre le visiteur et le serveur du propriétaire du site web, agissant comme un proxy inverse pour les sites web. Cloudflare fournit un Réseau de Diffusion de Contenu (CDN), ainsi que des services d’atténuation des DDoS et de serveurs de noms de domaine distribués.

      Nginx est un serveur web populaire qui héberge certains des sites les plus importants et les plus fréquentés d’Internet. Il est courant que des organisations desservent des sites web avec Nginx et utilisent Cloudflare comme fournisseur de CDN et de DNS.

      Dans ce tutoriel, vous allez sécuriser votre site web servi par Nginx avec un certificat Origin CA de Cloudflare et ensuite configurer Nginx pour utiliser des requêtes d’extraction authentifiées. Les avantages de cette configuration sont que vous bénéficiez du CDN et de la résolution DNS rapide de Cloudflare tout en vous assurant que toutes les connexions passent par Cloudflare. Cela empêche toute requête malveillante d’atteindre votre serveur.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin des éléments suivants :

      Étape 1 – Génération d’un certificat Origin CA TLS

      Origin CA de Cloudflare vous permet de générer un certificat TLS gratuit signé par Cloudflare, à installer sur votre serveur Nginx. En utilisant le certificat TLS généré par Cloudflare, vous pouvez sécuriser la connexion entre les serveurs de Cloudflare et votre serveur Nginx.

      Pour générer un certificat avec Origin CA, connectez-vous à votre compte Cloudflare dans un navigateur web. Sélectionnez le domaine que vous souhaitez sécuriser et naviguez jusqu’à la section SSL/TLS de votre tableau de bord Cloudflare. De là, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et cliquez sur le bouton Create Certificate (Créer un certificat)  :

      Option de création de certificat dans le tableau de bord de Cloudflare

      Laissez l’option par défaut Let Cloudflare generate a private key and a CSR (Laisser Cloudflare générer une clé privée et une RSE) sélectionnée.

      Options de l'interface graphique d'Origin CA

      Cliquez sur Next (Suivant) et vous verrez un dialogue avec le Origin Certificate (certificat d’origine) et la Private key (clé privée). Vous devez transférer à la fois le certificat d’origine et la clé privée de Cloudflare vers votre serveur. Pour des raisons de sécurité, les informations relatives à la clé privée ne s’afficheront plus. Copiez donc la clé sur votre serveur avant de cliquer sur Ok.

      Boîte de dialogue illustrant le certificat d'origine et la clé privée

      Nous utiliserons le répertoire /etc/ssl sur le serveur pour contenir les fichiers de certificat d’origine et de clé privée. Le dossier existe déjà sur le serveur.

      Tout d’abord, copiez le contenu du certificat d’origine affiché dans la boîte de dialogue de votre navigateur.

      Ensuite, sur votre serveur, ouvrez /etc/ssl/cert.pem dans votre éditeur de texte préféré :

      • sudo nano /etc/ssl/cert.pem

      Ajoutez le contenu du certificat dans le fichier. Ensuite, sauvegardez et quittez l’éditeur.

      Retournez ensuite à votre navigateur et copiez le contenu de la clé privée. Ouvrez le fichier /etc/ssl/key.pem pour le modifier :

      • sudo nano /etc/ssl/key.pem

      Collez la clé privée dans le fichier, enregistrez le fichier et quittez l’éditeur.

      Remarque : parfois, lorsque vous copiez le certificat et la clé à partir du tableau de bord Cloudflare et que vous les collez dans les fichiers correspondants sur le serveur, des lignes vierges sont insérées. Nginx considérera ces certificats et ces clés comme non valides, assurez-vous donc qu’il n’y a pas de lignes blanches dans vos fichiers.

      Attention : le certificat Origin AC de Cloudflare n’est fiable que sur Cloudflare et ne doit donc être utilisé que par les serveurs d’origine qui sont activement connectés à Cloudflare. Si, à un moment donné, vous mettez en pause ou désactivez Cloudflare, votre certificat d’AC d’origine affichera une erreur de certificat non fiable.

      Maintenant que vous avez copié les fichiers de clés et de certificats sur votre serveur, vous devez mettre à jour la configuration de Nginx pour les utiliser.

      Étape 2 – Installation du certificat d’origine AC dans Nginx

      Dans la section précédente, vous avez généré un certificat d’origine et une clé privée en utilisant le tableau de bord de Cloudflare et avez enregistré les fichiers sur votre serveur. Vous allez maintenant mettre à jour la configuration de Nginx pour votre site afin d’utiliser le certificat d’origine et la clé privée pour sécuriser la connexion entre les serveurs de Cloudflare et votre serveur.

      Tout d’abord, assurez-vous que UFW autorisera le trafic HTTPS. Activez Nginx Full, qui ouvrira à la fois le port 80 (HTTP) et le port 443 (HTTPS) :

      • sudo ufw allow 'Nginx Full'

      Relancez maintenant UFW :

      Enfin, vérifiez que vos nouvelles règles sont autorisées et que UFW est actif :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Vous êtes maintenant prêt à ajuster votre bloc serveur Nginx. Nginx crée un bloc serveur par défaut lors de l’installation. Supprimez-le s’il existe encore, car vous avez déjà configuré un bloc de serveur personnalisé pour votre domaine :

      • sudo rm /etc/nginx/sites-enabled/default

      Ensuite, ouvrez le fichier de configuration Nginx pour votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Le dossier devrait ressembler à ceci :

      /etc/nginx/sites-available/your_domain

      server {
              listen 80;
              listen [::]:80;
      
              root /var/www/your_domain/html;
              index index.html index.htm index.nginx-debian.html;
      
              server_name your_domain www.your_domain;
      
              location / {
                      try_files $uri $uri/ =404;
              }
      }
      
      

      Nous allons modifier le fichier de configuration de Nginx pour faire ce qui suit :

      • Ecoutez sur le port 80 et redirigez toutes les requêtes pour qu’elles utilisent le protocole https.
      • Écoutez sur le port 443 et utilisez le certificat d’origine et la clé privée que vous avez ajoutés dans la section précédente.

      Modifiez le fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/nginx/sites-available/your_domain

      server {
          listen 80;
          listen [::]:80;
          server_name your_domain www.your_domain;
          return 302 https://$server_name$request_uri;
      }
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl        on;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
      
          server_name your_domain www.your_domain;
      
          root /var/www/your_domain/html;
          index index.html index.htm index.nginx-debian.html;
      
      
          location / {
                  try_files $uri $uri/ =404;
          }
      }
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, procédez à un test pour vous assurer qu’il n’y a aucune erreur de syntaxe dans aucun de vos fichiers Nginx :

      Si aucun problème n’a été trouvé, redémarrez Nginx pour permettre vos modifications :

      • sudo systemctl restart nginx

      Allez maintenant dans la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Overview (Vue d’ensemble), et changez le mode de cryptage SSL/TLS en mode Full (strict). Ceci informe Cloudflare de toujours crypter la connexion entre Cloudflare et votre serveur Nginx d’origine.

      Activez le mode SSL Full(strict) dans le tableau de bord de Cloudflare

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Vous verrez votre page d’accueil s’afficher et le navigateur vous indiquera que le site est sécurisé.

      Dans la section suivante, vous allez mettre en place des Authenticated Origin Pulls (Extractions à l’Origine Authentifiée) pour vérifier que votre serveur d’origine parle bien à Cloudflare et non à un autre serveur. Ce faisant, Nginx sera configuré pour n’accepter que les requêtes qui utilisent un certificat client valide de Cloudflare ; toutes les requêtes qui ne sont pas passées par Cloudflare seront abandonnées.

      Le certificat Origin CA aidera Cloudflare à vérifier qu’il parle au bon serveur d’origine. Cette étape utilisera l’authentification du client TLS pour vérifier que votre serveur Nginx d’origine parle à Cloudflare.

      Dans le cadre d’un handshake TLS authentifié par le client, les deux parties fournissent un certificat à vérifier. Le serveur d’origine est configuré pour n’accepter que les requêtes qui utilisent un certificat client Cloudflare valide. Les requêtes qui ne sont pas passées par Cloudflare seront abandonnées car elles n’auront pas le certificat de Cloudflare. Cela signifie que les pirates ne peuvent pas contourner les mesures de sécurité de Cloudflare, ni se connecter directement à votre serveur Nginx.

      Cloudflare présente des certificats signés par une AC avec le certificat suivant :

      -----BEGIN CERTIFICATE-----
      MIIGCjCCA/KgAwIBAgIIV5G6lVbCLmEwDQYJKoZIhvcNAQENBQAwgZAxCzAJBgNV
      BAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMRQwEgYDVQQLEwtPcmln
      aW4gUHVsbDEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZv
      cm5pYTEjMCEGA1UEAxMab3JpZ2luLXB1bGwuY2xvdWRmbGFyZS5uZXQwHhcNMTkx
      MDEwMTg0NTAwWhcNMjkxMTAxMTcwMDAwWjCBkDELMAkGA1UEBhMCVVMxGTAXBgNV
      BAoTEENsb3VkRmxhcmUsIEluYy4xFDASBgNVBAsTC09yaWdpbiBQdWxsMRYwFAYD
      VQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlhMSMwIQYDVQQD
      ExpvcmlnaW4tcHVsbC5jbG91ZGZsYXJlLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQAD
      ggIPADCCAgoCggIBAN2y2zojYfl0bKfhp0AJBFeV+jQqbCw3sHmvEPwLmqDLqynI
      42tZXR5y914ZB9ZrwbL/K5O46exd/LujJnV2b3dzcx5rtiQzso0xzljqbnbQT20e
      ihx/WrF4OkZKydZzsdaJsWAPuplDH5P7J82q3re88jQdgE5hqjqFZ3clCG7lxoBw
      hLaazm3NJJlUfzdk97ouRvnFGAuXd5cQVx8jYOOeU60sWqmMe4QHdOvpqB91bJoY
      QSKVFjUgHeTpN8tNpKJfb9LIn3pun3bC9NKNHtRKMNX3Kl/sAPq7q/AlndvA2Kw3
      Dkum2mHQUGdzVHqcOgea9BGjLK2h7SuX93zTWL02u799dr6Xkrad/WShHchfjjRn
      aL35niJUDr02YJtPgxWObsrfOU63B8juLUphW/4BOjjJyAG5l9j1//aUGEi/sEe5
      lqVv0P78QrxoxR+MMXiJwQab5FB8TG/ac6mRHgF9CmkX90uaRh+OC07XjTdfSKGR
      PpM9hB2ZhLol/nf8qmoLdoD5HvODZuKu2+muKeVHXgw2/A6wM7OwrinxZiyBk5Hh
      CvaADH7PZpU6z/zv5NU5HSvXiKtCzFuDu4/Zfi34RfHXeCUfHAb4KfNRXJwMsxUa
      +4ZpSAX2G6RnGU5meuXpU5/V+DQJp/e69XyyY6RXDoMywaEFlIlXBqjRRA2pAgMB
      AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1Ud
      DgQWBBRDWUsraYuA4REzalfNVzjann3F6zAfBgNVHSMEGDAWgBRDWUsraYuA4REz
      alfNVzjann3F6zANBgkqhkiG9w0BAQ0FAAOCAgEAkQ+T9nqcSlAuW/90DeYmQOW1
      QhqOor5psBEGvxbNGV2hdLJY8h6QUq48BCevcMChg/L1CkznBNI40i3/6heDn3IS
      zVEwXKf34pPFCACWVMZxbQjkNRTiH8iRur9EsaNQ5oXCPJkhwg2+IFyoPAAYURoX
      VcI9SCDUa45clmYHJ/XYwV1icGVI8/9b2JUqklnOTa5tugwIUi5sTfipNcJXHhgz
      6BKYDl0/UP0lLKbsUETXeTGDiDpxZYIgbcFrRDDkHC6BSvdWVEiH5b9mH2BON60z
      0O0j8EEKTwi9jnafVtZQXP/D8yoVowdFDjXcKkOPF/1gIh9qrFR6GdoPVgB3SkLc
      5ulBqZaCHm563jsvWb/kXJnlFxW+1bsO9BDD6DweBcGdNurgmH625wBXksSdD7y/
      fakk8DagjbjKShYlPEFOAqEcliwjF45eabL0t27MJV61O/jHzHL3dknXeE4BDa2j
      bA+JbyJeUMtU7KMsxvx82RmhqBEJJDBCJ3scVptvhDMRrtqDBW5JShxoAOcpFQGm
      iYWicn46nPDjgTU0bX1ZPpTpryXbvciVL5RkVBuyX2ntcOLDPlZWgxZCBp96x07F
      AnOzKgZk4RzZPNAxCXERVxajn/FLcOhglVAKo5H0ac+AitlQ0ip55D2/mf8o72tM
      fVQ6VpyjEXdiIXWUq/o=
      -----END CERTIFICATE-----
      

      Vous pouvez également télécharger le certificat directement à partir de Cloudflare ici.

      Copiez ce certificat.

      Puis, créez le fichier /etc/ssl/cloudflare.crt pour y placer le certificat de Cloudflare  :

      • sudo nano /etc/ssl/cloudflare.crt

      Ajoutez le certificat au fichier. Ensuite, enregistrez le fichier et quittez l’éditeur.

      Mettez maintenant à jour votre configuration Nginx pour utiliser les Extractions d’Origine Authentifiée TLS. Ouvrez le fichier de configuration de votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Ajoutez les directives ssl_client_certificate et ssl_verify_client, comme indiqué dans l’exemple suivant :

      /etc/nginx/sites-available/your_domain

      . . .
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl        on;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
          ssl_client_certificate /etc/ssl/cloudflare.crt;
          ssl_verify_client on;
      
          . . .
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, testez Nginx pour vous assurer qu’il n’y a pas d’erreurs de syntaxe dans votre configuration Nginx :

      Si aucun problème n’a été trouvé, redémarrez Nginx pour permettre vos modifications :

      • sudo systemctl restart nginx

      Enfin, pour activer les Extractions Authentifiées, ouvrez la section SSL/TLS dans le tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’Origine) et cochez l’option Authenticated Origin Pulls.

      Activez les Extractions d'Origine Authentifiée

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Comme auparavant, vous verrez s’afficher votre page d’accueil.

      Pour vérifier que votre serveur n’accepte que les demandes signées par l’AC de Cloudflare, basculez l’option Authenticated Origin Pulls pour la désactiver, puis rechargez votre site web. Le message d’erreur suivant devrait apparaître :

      Message d'erreur

      Votre serveur d’origine génère une erreur si une requête n’est pas signée par l’AC de Cloudflare.

      Remarque : la plupart des navigateurs mettent les requêtes en cache. Pour voir le changement ci-dessus, vous pouvez donc utiliser le mode de navigation Incognito/Privé dans votre navigateur. Pour éviter que Cloudflare ne mette les requêtes en cache pendant que vous configurez votre site web, naviguez jusqu’à l’aperçu dans le tableau de bord Cloudflare et basculez en Development Mode (Mode Développement).

      Maintenant que vous savez qu’il fonctionne correctement, retournez à la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et activez à nouveau l’option Authenticated Origin Pulls pour l’activer.

      Conclusion

      Dans ce tutoriel, vous avez sécurisé votre site web alimenté par Nginx en cryptant le trafic entre Cloudflare et le serveur Nginx à l’aide d’un certificat Origin CA de Cloudflare. Vous avez ensuite configuré des Authenticated Origin Pulls (Extractions d’Origine Authentifiée) sur le serveur Nginx pour vous assurer qu’il n’accepte que les requêtes des serveurs Cloudflare, empêchant ainsi toute autre personne de se connecter directement au serveur Nginx.



      Source link

      Comment héberger un site web en utilisant Cloudflare et Nginx sur Ubuntu 20.04


      L’auteur a choisi la Electronic Frontier Foundation comme récipiendaire d’un don dans le cadre du programme Write for DOnations.

      Introduction

      Cloudflare est un service qui se situe entre le visiteur et le serveur du propriétaire du site web, agissant comme un proxy inverse pour les sites web. Cloudflare fournit un Réseau de Diffusion de Contenu (CDN), ainsi que des services d’atténuation des DDoS et de serveurs de noms de domaine distribués.

      Nginx est un serveur web populaire qui héberge certains des sites les plus importants et les plus fréquentés d’Internet. Il est fréquent que des entreprises exploitent des sites web avec Nginx et utilisent Cloudflare comme fournisseur de CDN et de DNS.

      Dans ce tutoriel, vous allez sécuriser votre site web servi par Nginx avec un certificat Origin CA de Cloudflare et ensuite configurer Nginx pour utiliser des requêtes pull authentifiées. Les avantages de cette configuration tiennent au fait que vous bénéficiez du CDN et de la résolution DNS rapide de Cloudflare tout en vous assurant que toutes les connexions passent par Cloudflare. Cela empêche toute requête malveillante d’atteindre votre serveur.

      Conditions préalables

      Pour terminer ce tutoriel, vous aurez besoin des éléments suivants :

      Étape 1 – Génération d’un certificat Origin CA TLS

      L’Origin CA de Cloudflare vous permet de générer un certificat TLS gratuit signé par Cloudflare à installer sur votre serveur Nginx. En utilisant le certificat TLS généré par Cloudflare, vous pouvez sécuriser la connexion entre les serveurs de Cloudflare et votre serveur Nginx.

      Pour générer un certificat avec Origin CA, connectez-vous à votre compte Cloudflare dans un navigateur web. Sélectionnez le domaine que vous souhaitez sécuriser et naviguez jusqu’à la section SSL/TLS de votre tableau de bord Cloudflare. De là, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et cliquez sur le bouton Create Certificate (Créer un certificat) :

      Option de création de certificat dans le tableau de bord de Cloudflare

      Laissez l’option par défaut de Let Cloudflare generate a private key and a CSR (Laisser Cloudflare générer une clé privée et une RSE) sélectionnée.

      Options de l'interface graphique d'Origin CA

      Cliquez sur Next (Suivant) et vous verrez un dialogue avec le Origin Certificate (certificat d’origine) et la Private key (clé privée). Vous devez transférer à la fois le certificat d’origine et la clé privée de Cloudflare vers votre serveur. Pour des raisons de sécurité, les informations relatives à la clé privée ne s’afficheront plus. Copiez donc la clé sur votre serveur avant de cliquer sur Ok.

      Dialogue montrant le certificat d'origine et la clé privée

      Vous utiliserez le répertoire /etc/ssl du serveur pour conserver les fichiers de certificat d’origine et la clé privée. Le dossier existe déjà sur le serveur.

      Tout d’abord, copiez le contenu du certificat d’origine affiché dans la boîte de dialogue de votre navigateur.

      Ensuite, sur votre serveur, ouvrez /etc/ssl/cert.pem dans votre éditeur de texte préféré :

      • sudo nano /etc/ssl/cert.pem

      Ajoutez le contenu du certificat dans le fichier. Ensuite, sauvegardez et quittez l’éditeur.

      Retournez ensuite à votre navigateur et copiez le contenu de la clé privée. Ouvrez le fichier /etc/ssl/key.pem pour le modifier :

      • sudo nano /etc/ssl/key.pem

      Collez la clé privée dans le fichier, enregistrez le fichier et quittez l’éditeur.

      Note : parfois, lorsque vous copiez le certificat et la clé à partir du tableau de bord Cloudflare et que vous les collez dans les fichiers correspondants sur le serveur, des lignes vierges sont insérées. Nginx considérera ces certificats et ces clés comme non valides. Par conséquent, veillez à ce qu’il n’y ait pas de lignes blanches dans vos fichiers.

      Attention : le certificat Origin CA de Cloudflare n’est fiable que sur Cloudflare et ne doit donc être utilisé que par les serveurs d’origine qui sont activement connectés à Cloudflare. Si, à un moment donné, vous mettez en pause ou désactivez Cloudflare, votre certificat Origin CA affichera une erreur de certificat non fiable.

      Maintenant que vous avez copié les fichiers de clés et de certificats sur votre serveur, vous devez mettre à jour la configuration de Nginx pour les utiliser.

      Étape 2 – Installation du certificat d’origine AC dans Nginx

      Dans la section précédente, vous avez généré un certificat d’origine et une clé privée en utilisant le tableau de bord de Cloudflare et avez enregistré les fichiers sur votre serveur. Vous allez maintenant mettre à jour la configuration de Nginx pour votre site afin d’utiliser le certificat d’origine et la clé privée pour sécuriser la connexion entre les serveurs de Cloudflare et votre serveur.

      Tout d’abord, assurez-vous que UFW autorisera le trafic HTTPS. Activez Nginx Full, qui ouvrira à la fois le port 80 (HTTP) et le port 443 (HTTPS) :

      • sudo ufw allow 'Nginx Full'

      Relancez maintenant UFW :

      Enfin, vérifiez que vos nouvelles règles sont autorisées et que UFW est actif :

      Vous verrez un résultat similaire à ce qui suit :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6)

      Vous êtes maintenant prêt à ajuster votre bloc serveur Nginx. Nginx crée un bloc serveur par défaut lors de l’installation. Supprimez-le s’il existe encore, car vous avez déjà configuré un bloc de serveur personnalisé pour votre domaine :

      • sudo rm /etc/nginx/sites-enabled/default

      Ensuite, ouvrez le fichier de configuration Nginx pour votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Le dossier devrait ressembler à ceci :

      /etc/nginx/sites-available/your_domain

      server {
              listen 80;
              listen [::]:80;
      
              root /var/www/your_domain/html;
              index index.html index.htm index.nginx-debian.html;
      
              server_name your_domain www.your_domain;
      
              location / {
                      try_files $uri $uri/ =404;
              }
      }
      
      

      Vous allez modifier le fichier de configuration de Nginx pour faire ce qui suit :

      • Ecoutez sur le port 80 et redirigez toutes les requêtes pour utiliser le https.
      • Écoutez sur le port 443 et utilisez le certificat d’origine ainsi que la clé privée ajoutés dans la section précédente.

      Modifiez le fichier de manière à ce qu’il ressemble à ce qui suit :

      /etc/nginx/sites-available/your_domain

      server {
          listen 80;
          listen [::]:80;
          server_name your_domain www.your_domain;
          return 302 https://$server_name$request_uri;
      }
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
      
          server_name your_domain www.your_domain;
      
          root /var/www/your_domain/html;
          index index.html index.htm index.nginx-debian.html;
      
      
          location / {
                  try_files $uri $uri/ =404;
          }
      }
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, vérifiez qu’il n’y a aucune erreur de syntaxe dans vos fichiers de configuration Nginx :

      Si vous ne trouvez aucun problème, redémarrez Nginx pour permettre vos modifications :

      • sudo systemctl restart nginx

      Allez maintenant dans la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Overview (Vue d’ensemble), et changez le mode de cryptage SSL/TLS en mode Full (strict). Ceci informe Cloudflare de toujours crypter la connexion entre Cloudflare et votre serveur Nginx d’origine.

      Activez le mode SSL Full(strict) dans le tableau de bord de Cloudflare

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Vous verrez votre page d’accueil s’afficher et le navigateur vous indiquera que le site est sécurisé.

      Dans la section suivante, vous allez mettre en place des Authenticated Origin Pulls (Extractions à l’Origine Authentifiée) pour vérifier que votre serveur d’origine parle bien à Cloudflare et non à un autre serveur. Ce faisant, Nginx sera configuré pour n’accepter que les requêtes qui utilisent un certificat client valide de Cloudflare ; toutes les requêtes qui ne sont pas passées par Cloudflare seront abandonnées.

      Le certificat Origin CA aidera Cloudflare à vérifier qu’il parle au bon serveur d’origine. Cette étape utilisera l’authentification du client TLS pour vérifier que votre serveur Nginx d’origine parle à Cloudflare.

      Dans une poignée de main TLS authentifiée par le client, les deux parties fournissent un certificat à vérifier. Le serveur d’origine est configuré pour n’accepter que les requêtes qui utilisent un certificat client valide de Cloudflare. Les requêtes qui ne sont pas passées par Cloudflare seront abandonnées car elles n’auront pas le certificat de Cloudflare. Cela signifie que les attaquants ne peuvent pas contourner les mesures de sécurité de Cloudflare et se connecter directement à votre serveur Nginx.

      Cloudflare présente des certificats signés par une autorité de certification (AC) avec le certificat suivant :

      -----BEGIN CERTIFICATE-----
      MIIGCjCCA/KgAwIBAgIIV5G6lVbCLmEwDQYJKoZIhvcNAQENBQAwgZAxCzAJBgNV
      BAYTAlVTMRkwFwYDVQQKExBDbG91ZEZsYXJlLCBJbmMuMRQwEgYDVQQLEwtPcmln
      aW4gUHVsbDEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzETMBEGA1UECBMKQ2FsaWZv
      cm5pYTEjMCEGA1UEAxMab3JpZ2luLXB1bGwuY2xvdWRmbGFyZS5uZXQwHhcNMTkx
      MDEwMTg0NTAwWhcNMjkxMTAxMTcwMDAwWjCBkDELMAkGA1UEBhMCVVMxGTAXBgNV
      BAoTEENsb3VkRmxhcmUsIEluYy4xFDASBgNVBAsTC09yaWdpbiBQdWxsMRYwFAYD
      VQQHEw1TYW4gRnJhbmNpc2NvMRMwEQYDVQQIEwpDYWxpZm9ybmlhMSMwIQYDVQQD
      ExpvcmlnaW4tcHVsbC5jbG91ZGZsYXJlLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQAD
      ggIPADCCAgoCggIBAN2y2zojYfl0bKfhp0AJBFeV+jQqbCw3sHmvEPwLmqDLqynI
      42tZXR5y914ZB9ZrwbL/K5O46exd/LujJnV2b3dzcx5rtiQzso0xzljqbnbQT20e
      ihx/WrF4OkZKydZzsdaJsWAPuplDH5P7J82q3re88jQdgE5hqjqFZ3clCG7lxoBw
      hLaazm3NJJlUfzdk97ouRvnFGAuXd5cQVx8jYOOeU60sWqmMe4QHdOvpqB91bJoY
      QSKVFjUgHeTpN8tNpKJfb9LIn3pun3bC9NKNHtRKMNX3Kl/sAPq7q/AlndvA2Kw3
      Dkum2mHQUGdzVHqcOgea9BGjLK2h7SuX93zTWL02u799dr6Xkrad/WShHchfjjRn
      aL35niJUDr02YJtPgxWObsrfOU63B8juLUphW/4BOjjJyAG5l9j1//aUGEi/sEe5
      lqVv0P78QrxoxR+MMXiJwQab5FB8TG/ac6mRHgF9CmkX90uaRh+OC07XjTdfSKGR
      PpM9hB2ZhLol/nf8qmoLdoD5HvODZuKu2+muKeVHXgw2/A6wM7OwrinxZiyBk5Hh
      CvaADH7PZpU6z/zv5NU5HSvXiKtCzFuDu4/Zfi34RfHXeCUfHAb4KfNRXJwMsxUa
      +4ZpSAX2G6RnGU5meuXpU5/V+DQJp/e69XyyY6RXDoMywaEFlIlXBqjRRA2pAgMB
      AAGjZjBkMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMB0GA1Ud
      DgQWBBRDWUsraYuA4REzalfNVzjann3F6zAfBgNVHSMEGDAWgBRDWUsraYuA4REz
      alfNVzjann3F6zANBgkqhkiG9w0BAQ0FAAOCAgEAkQ+T9nqcSlAuW/90DeYmQOW1
      QhqOor5psBEGvxbNGV2hdLJY8h6QUq48BCevcMChg/L1CkznBNI40i3/6heDn3IS
      zVEwXKf34pPFCACWVMZxbQjkNRTiH8iRur9EsaNQ5oXCPJkhwg2+IFyoPAAYURoX
      VcI9SCDUa45clmYHJ/XYwV1icGVI8/9b2JUqklnOTa5tugwIUi5sTfipNcJXHhgz
      6BKYDl0/UP0lLKbsUETXeTGDiDpxZYIgbcFrRDDkHC6BSvdWVEiH5b9mH2BON60z
      0O0j8EEKTwi9jnafVtZQXP/D8yoVowdFDjXcKkOPF/1gIh9qrFR6GdoPVgB3SkLc
      5ulBqZaCHm563jsvWb/kXJnlFxW+1bsO9BDD6DweBcGdNurgmH625wBXksSdD7y/
      fakk8DagjbjKShYlPEFOAqEcliwjF45eabL0t27MJV61O/jHzHL3dknXeE4BDa2j
      bA+JbyJeUMtU7KMsxvx82RmhqBEJJDBCJ3scVptvhDMRrtqDBW5JShxoAOcpFQGm
      iYWicn46nPDjgTU0bX1ZPpTpryXbvciVL5RkVBuyX2ntcOLDPlZWgxZCBp96x07F
      AnOzKgZk4RzZPNAxCXERVxajn/FLcOhglVAKo5H0ac+AitlQ0ip55D2/mf8o72tM
      fVQ6VpyjEXdiIXWUq/o=
      -----END CERTIFICATE-----
      

      Vous pouvez également télécharger le certificat directement sur le site de Cloudflare ici.

      Copiez ce certificat.

      Puis, créez le fichier /etc/ssl/cloudflare.crt pour contenir le certificat de Cloudflare :

      • sudo nano /etc/ssl/cloudflare.crt

      Ajoutez le certificat au fichier. Ensuite, enregistrez le fichier et quittez l’éditeur.

      Mettez maintenant à jour votre configuration Nginx pour utiliser les Extractions d’Origine Authentifiée TLS. Ouvrez le fichier de configuration de votre domaine :

      • sudo nano /etc/nginx/sites-available/your_domain

      Ajoutez les directives ssl_client_certificate et ssl_verify_client, comme indiqué dans l’exemple suivant :

      /etc/nginx/sites-available/your_domain

      . . .
      
      server {
      
          # SSL configuration
      
          listen 443 ssl http2;
          listen [::]:443 ssl http2;
          ssl_certificate         /etc/ssl/cert.pem;
          ssl_certificate_key     /etc/ssl/key.pem;
          ssl_client_certificate /etc/ssl/cloudflare.crt;
          ssl_verify_client on;
      
          . . .
      

      Enregistrez le fichier et quittez l’éditeur.

      Ensuite, testez Nginx pour vous assurer qu’il n’y a pas d’erreurs de syntaxe dans votre configuration Nginx :

      Si aucun problème n’a été trouvé, redémarrez Nginx pour que vos modifications soient prises en compte :

      • sudo systemctl restart nginx

      Enfin, pour activer les Extractions Authentifiées, ouvrez la section SSL/TLS dans le tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’Origine) et cochez l’option Authenticated Origin Pulls.

      Activez les Extractions d'Origine Authentifiée

      Visitez maintenant votre site web à l’adresse https://your_domain pour vérifier qu’il est correctement configuré. Comme auparavant, vous verrez s’afficher votre page d’accueil.

      Pour vérifier que votre serveur n’accepte que les demandes signées par l’AC de Cloudflare, basculez l’option Authenticated Origin Pulls pour la désactiver, puis rechargez votre site web. Le message d’erreur suivant devrait apparaître :

      Message d'erreur

      Votre serveur d’origine génère une erreur si l’AC de Cloudflare ne signe pas une requête.

      Remarque : la plupart des navigateurs mettent les requêtes en cache. Pour voir le changement ci-dessus, vous pouvez donc utiliser le mode de navigation Incognito/Privé dans votre navigateur. Pour éviter que Cloudflare ne mette les requêtes en cache pendant que vous configurez votre site web, naviguez jusqu’à l’aperçu dans le tableau de bord Cloudflare et basculez en Development Mode (Mode Développement).

      Maintenant que vous savez qu’il fonctionne correctement, retournez à la section SSL/TLS du tableau de bord Cloudflare, naviguez jusqu’à l’onglet Origin Server (Serveur d’origine) et activez à nouveau l’option Authenticated Origin Pulls pour l’activer.

      Conclusion

      Dans ce tutoriel, vous avez sécurisé votre site web alimenté par Nginx en cryptant le trafic entre Cloudflare et le serveur Nginx à l’aide d’un certificat Origin CA de Cloudflare. Vous avez ensuite configuré des Authenticated Origin Pulls (Extractions d’Origine Authentifiée) sur le serveur Nginx pour vous assurer qu’il n’accepte que les requêtes des serveurs Cloudflare, empêchant ainsi toute autre personne de se connecter directement au serveur Nginx.



      Source link

      Comment héberger un site Web avec Caddy sur Ubuntu 18.04


      L’auteur a choisi le Free and Open Source Fund pour recevoir une donation dans le cadre du programme Write for DOnations.

      Introduction

      Caddy est un serveur Web basé sur la simplicité et la sécurité, qui est doté d’un certain nombre de fonctionnalités utiles pour l’hébergement de sites Web. Par exemple, il peut obtenir et gérer automatiquement les certificats TLS de Let’s Encrypt pour activer le HTTPS, et il inclut la prise en charge de HTTP/2. HTTPS est un système de sécurisation du trafic entre vos utilisateurs et votre serveur, et il est en passe de devenir en composant indispensable de tout site Web en production. Sans lui, Chrome et Firefox avertiront les utilisateurs que votre site Web est “Non sécurisé” si ceux-ci tentent de soumettre des informations de connexion.

      Auparavant, la méthode recommandée pour installer Caddy consistait à télécharger des binaires pré-construits à partir du site Web du projet Caddy. Toutefois, en raison des modifications apportées au fonctionnement de la licence de Caddy, vous n’êtes plus autorisé à utiliser ces binaires pré-construits à des fins commerciales, même si vous utilisez Caddy en interne au sein d’une entreprise, sauf si vous payez un droit de licence. Heureusement, le code source de Caddy est encore entièrement open source et vous pouvez construire Caddy vous-même pour éviter de rencontrer des problèmes de licence.

      Dans ce tutoriel, vous allez construire Caddy à partir de son code source et l’utiliser pour héberger un site Web sécurisé avec HTTPS. Cela implique de le compiler, de le configurer en utilisant un Caddyfile et d’installer des plugins. Enfin, vous apprendrez à mettre à jour votre installation lorsqu’une nouvelle version est disponible.

      Conditions préalables

      Étape 1 — Construction de Caddy

      Dans cette étape, vous construirez Caddy à partir de son code source avec la possibilité d’ajouter ultérieurement des plugins, le tout sans modifier le code source de Caddy.

      Pour les besoins de ce tutoriel, vous stockerez le code source sous ~/caddy. Créez ce répertoire en exécutant la commande suivante :

      Naviguez jusqu’à lui :

      Vous stockerez le code source pour l’exécution et la personnalisation de Caddy dans un fichier nommé caddy.go. Créez-le en utilisant la commande suivante :

      Ajoutez les lignes suivantes :

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Ce code importe Caddy directement de Github (en utilisant Git) et le lance à partir de la fonction d’entrée main. Si vous souhaitez activer la télémétrie, décommentez la ligne caddymain.EnableTelemetry et réglez la valeur sur true. Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Pour que caddy.go puisse utiliser les dépendances importées, vous devrez l’initialiser en tant que module :

      Output

      go: creating new go.mod: module caddy

      À ce stade, vous êtes prêt à construire la version de base de Caddy à partir du code source ci-dessus en exécutant :

      Il y aura beaucoup de sorties, détaillant les bibliothèques téléchargées par Go comme dépendances nécessaires à la compilation. L’exécutable résultant est stocké sous $GOPATH/bin, comme expliqué dans les conditions préalables.

      Lorsqu’il a terminé, essayez d’exécuter Caddy :

      Vous verrez une sortie semblable à ce qui suit :

      Output

      Activating privacy features... done. Serving HTTP on port 2015 http://:2015 WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with `ulimit -n 8192`.

      Cela signifie que Caddy a démarré avec succès, et est disponible sur le port 2015. Vous pouvez ignorer le message d’avertissement, car cette limite sera ajustée ultérieurement sans votre intervention. Pour quitter, appuyez sur CTRL + C.

      Vous avez maintenant construit et exécuté Caddy. Dans l’étape suivante, vous installerez Caddy en tant que service afin qu’il se lance automatiquement au démarrage, puis vous ajusterez ses paramètres de propriété et d’autorisation pour assurer la sécurité du serveur.

      Étape 2 – Installation de Caddy

      Maintenant que vous avez vérifié que vous êtes capable de construire et d’exécuter Caddy, il est temps de configurer un service systemd afin que Caddy puisse être lancé automatiquement au démarrage du système. Pour en savoir plus sur systemd, consultez notre tutoriel Les fondamentaux de Systemd.

      Pour commencer, déplacez le binaire Caddy vers /usr/local/bin, l’emplacement standard pour les binaires qui ne sont pas gérés par le gestionnaire de packages d’Ubuntu et qui ne sont pas essentiels au fonctionnement du système :

      • sudo mv $GOPATH/bin/caddy /usr/local/bin/

      Ensuite, transférez la propriété du binaire Caddy à l’utilisateur root :

      • sudo chown root:root /usr/local/bin/caddy

      Cela empêchera d’autres comptes de modifier l’exécutable. Cependant, même si l’utilisateur root possède Caddy, il est conseillé de l’exécuter uniquement en utilisant d’autres comptes non root présents sur le système. Cela permet de s’assurer qu’en cas de compromission de Caddy (ou d’un autre programme), l’attaquant ne pourra pas modifier le binaire, ou exécuter des commandes en tant que root.

      Ensuite, définissez les permissions du fichier binaire à 755 – cela donne à root des permissions complètes de lecture/écriture/exécution pour le fichier, alors que les autres utilisateurs ne pourront que le lire et l’exécuter :

      • sudo chmod 755 /usr/local/bin/caddy

      Comme le processus Caddy ne s’exécutera pas en tant que root, Linux l’empêchera de se lier aux ports 80 et 443 (les ports standard pour HTTP et HTTPS, respectivement), car il s’agit d’opérations privilégiées. Afin d’être facilement accessible sur votre domaine, Caddy doit être relié à l’un de ces ports, selon le protocole. Sinon, il vous faudrait ajouter un numéro de port spécifique à l’URL du domaine dans votre navigateur pour visualiser le contenu qu’il servira.

      Pour permettre à Caddy de se lier à des ports bas sans s’exécuter en tant que root, exécutez la commande suivante :

      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      L’utilitaire setcap définit les capacités des fichiers. Dans cette commande, il attribue la capacité CAP_NET_BIND_SERVICE au binaire Caddy, ce qui permet à un exécutable de se lier à un port inférieur à 1024.

      Vous avez maintenant fini de configurer le binaire Caddy, et vous êtes prêt à commencer à écrire la configuration de Caddy. Créez un répertoire dans lequel vous stockerez les fichiers de configuration de Caddy en exécutant la commande suivante :

      Ensuite, définissez les autorisations d’utilisateur et de groupe appropriées pour celui-ci :

      • sudo chown -R root:www-data /etc/caddy

      Le fait de définir l’utilisateur comme root et le groupe comme www-data garantit que Caddy aura un accès en lecture et en écriture au dossier (via le groupe www-data) et que seul le compte du super-utilisateur aura les mêmes droits de lecture et de modification. www-data est l’utilisateur et le groupe par défaut pour les serveurs Web sur Ubuntu.

      Dans une étape ultérieure, vous activerez le provisionnement automatique des certificats TLS à partir de Let’s Encrypt. Pour préparer cette étape, créez un répertoire pour stocker tous les certificats TLS que Caddy obtiendra et donnez-lui les mêmes règles de propriété que le répertoire /etc/caddy :

      • sudo mkdir /etc/ssl/caddy
      • sudo chown -R root:www-data /etc/ssl/caddy

      Caddy doit être capable d’écrire des certificats dans ce répertoire et de lire à partir de celui-ci afin de chiffrer les requêtes. Pour cette raison, modifiez les permissions du répertoire /etc/ssl/caddy afin qu’il ne soit accessible que par root et www-data :

      • sudo chmod 0770 /etc/ssl/caddy

      Ensuite, créez un répertoire pour stocker les fichiers que Caddy hébergera :

      Ensuite, définissez le propriétaire et le groupe du répertoire sur www-data :

      • sudo chown www-data:www-data /var/www

      Caddy lit sa configuration à partir d’un fichier appelé Caddyfile, stocké sous /etc/caddy. Créez le fichier sur le disque en exécutant :

      • sudo touch /etc/caddy/Caddyfile

      Pour installer le service Caddy, téléchargez le fichier d’unité systemd du référentiel Github Caddy dans /etc/systemd/system en exécutant :

      • sudo sh -c 'curl https://raw.githubusercontent.com/caddyserver/caddy/master/dist/init/linux-systemd/caddy.service > /etc/systemd/system/caddy.service'

      Modifiez les permissions du fichier de service afin qu’il ne puisse être modifié que par son propriétaire, root :

      • sudo chmod 644 /etc/systemd/system/caddy.service

      Puis, rechargez le système pour détecter le service Caddy :

      • sudo systemctl daemon-reload

      Vérifiez si systemd a détecté le service Caddy en exécutant systemctl status :

      • sudo systemctl status caddy

      Vous verrez une sortie semblable à :

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: e Active: inactive (dead) Docs: https://caddyserver.com/docs

      Si vous voyez cette même sortie, alors le nouveau service a été correctement détecté par systemd.

      Dans le cadre de la configuration initiale du serveur, vous avez activé ufw, le pare-feu non compliqué, et autorisé les connexions SSH. Pour que Caddy puisse servir le trafic HTTP et HTTPS à partir de votre serveur, vous devez les autoriser dans ufw en exécutant la commande suivante :

      • sudo ufw allow proto tcp from any to any port 80,443

      Le résultat sera :

      Output

      Rule added Rule added (v6)

      Utilisez ufw status pour vérifier si vos changements ont fonctionné :

      Vous verrez la sortie suivante :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 80,443/tcp ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 80,443/tcp (v6) ALLOW Anywhere (v6)

      Votre installation de Caddy est maintenant terminée, mais elle n’est pas configurée pour servir quoi que ce soit. Dans l’étape suivante, vous allez configurer Caddy pour qu’il serve les fichiers du répertoire /var/www.

      Étape 3 – Configuration de Caddy

      Dans cette section, vous allez écrire la configuration de base de Caddy pour servir des fichiers statiques à partir de votre serveur.

      Commencez par créer un fichier HTML de base dans /var/www, appelé index.html :

      • sudo nano /var/www/index.html

      Ajoutez les lignes suivantes :

      /var/www/index.html

      <!DOCTYPE html>
      <html>
      <head>
        <title>Hello from Caddy!</title>
      </head>
      <body>
        <h1 style="font-family: sans-serif">This page is being served via Caddy</h1>
      </body>
      </html>
      

      Lorsqu’il est affiché dans un navigateur Web, ce fichier affichera un titre avec le texte This page is being served by Caddy (Cette page est servie par Caddy). Enregistrez et fermez le fichier.

      Ouvrez le fichier de configuration Caddyfile que vous avez créé précédemment pour le modifier :

      • sudo nano /etc/caddy/Caddyfile

      Ajoutez les lignes suivantes :

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip
      }
      

      Il s’agit d’une configuration de base de Caddy, qui déclare que le port 80 de votre serveur doit être servi avec des fichiers provenant de /var/www et compressés à l’aide de gzip pour réduire le temps de chargement des pages côté client.

      Dans la majorité des cas, Caddy vous permet de personnaliser davantage les directives de configuration. Par exemple, vous pouvez limiter la compression gzip aux seuls fichiers HTML et PHP, et fixer le niveau de compression à 6 (1 étant le plus bas et 9 le plus élevé) en étendant la directive avec des accolades et en énumérant des sous-directives en dessous :

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip {
            ext .html .htm .php
            level 6
        }
      }
      

      Lorsque vous avez terminé, enregistrez et fermez le fichier.

      Caddy dispose d’un grand nombre de directives différentes pour de nombreux cas d’utilisation. Par exemple, la directive fastcgi peut être utilisée pour activer PHP. La directive markdown peut être utilisée pour convertir automatiquement les fichiers Markdown en HTML avant de les servir, ce qui peut être utile pour créer un simple blog.

      Pour vérifier que tout fonctionne correctement, lancez le service Caddy :

      • sudo systemctl start caddy

      Ensuite, lancez systemctl status pour obtenir des informations sur le statut du service Caddy :

      • sudo systemctl status caddy

      Vous verrez ce qui suit :

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 11:17:49 UTC; 11s ago Docs: https://caddyserver.com/docs Main PID: 3893 (caddy) Tasks: 7 (limit: 1152) CGroup: /system.slice/caddy.service └─3893 /usr/local/bin/caddy -log stdout -log-timestamps=false -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp Mar 12 11:17:49 caddy-article-update systemd[1]: Started Caddy HTTP/2 web server. Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO] Caddy version: v1.0.5 Mar 12 11:17:49 caddy-article-update caddy[3893]: Activating privacy features... done. Mar 12 11:17:49 caddy-article-update caddy[3893]: Serving HTTP on port 80 Mar 12 11:17:49 caddy-article-update caddy[3893]: http:// Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO] Serving http:// Mar 12 11:17:49 caddy-article-update caddy[3893]: [INFO][cache:0xc00007a7d0] Started certificate maintenance routine Mar 12 11:17:49 caddy-article-update caddy[3893]: [WARNING] Sending telemetry (attempt 1): Post "https://telemetry.caddyserver.com/v1/update/6a8159c4-3427-42 Mar 12 11:17:57 caddy-article-update caddy[3893]: [WARNING] Sending telemetry (attempt 2): Post "https://telemetry.caddyserver.com/v1/update/6a8159c4-3427-42 ...

      Vous pouvez maintenant naviguer vers l’adresse IP de votre serveur dans un navigateur Web. Votre exemple de page Web affichera :

      Message de Caddy

      Vous avez maintenant configuré Caddy pour servir des fichiers statiques à partir de votre serveur. Dans l’étape suivante, vous allez étendre les fonctionnalités de Caddy grâce à l’utilisation de plugins.

      Étape 4 – Utilisation de plugins

      Les plugins offrent un moyen de modifier et d’étendre le comportement de Caddy. En général, ils proposent davantage de directives de configuration à utiliser, en fonction de votre cas d’utilisation. Dans cette section, vous ajouterez et utiliserez des plugins en installant le plugin minify. Il supprime les espaces excédentaires et nettoie le code qui sera envoyé au client, ce qui réduit encore l’encombrement et les temps de chargement.

      Le référentiel GitHub du plugin minify est hacdias/caddy-minify.

      Naviguez jusqu’au répertoire avec le code source que vous avez créé à la première étape :

      Pour ajouter un plugin à Caddy, vous devez l’importer dans le fichier caddy.go que vous avez utilisé pour construire Caddy. Ouvrez caddy.go​​​ pour le modifier :

      Importez le plugin minify en ajoutant la ligne surlignée, comme ceci :

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      
          _ "github.com/hacdias/caddy-minify"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Enregistrez et fermez le fichier.

      Certains plugins peuvent nécessiter quelques légers ajustements de configuration, alors assurez-vous de lire la documentation pour ceux que vous installez. Vous trouverez une liste des plugins les plus populaires dans le volet gauche de la documentation de Caddy, sous Plugins.

      À chaque fois que vous ajoutez un nouveau plugin, vous devez reconstruire Caddy. En effet, Go est un langage de programmation compilé, ce qui signifie que le code source est transformé en code machine avant l’exécution. Votre modification de la déclaration d’importation a mis à jour le code source, mais n’affectera pas le binaire tant qu’il n’aura pas été compilé.

      Utilisez la commande go install pour compiler Caddy :

      Lorsque c’est terminé, déplacez le binaire généré vers /usr/local/bin et définissez les autorisations pour le binaire comme vous l’avez fait précédemment. Vous devez suivre ces étapes à chaque fois que vous reconstruisez Caddy afin d’assurer sa fonctionnalité et sa sécurité :

      • sudo mv $GOPATH/bin/caddy /usr/local/bin/
      • sudo chown root:root /usr/local/bin/caddy
      • sudo chmod 755 /usr/local/bin/caddy
      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      Pour commencer à utiliser le plugin minify, vous devez ajouter la directive minify à votre Caddyfile. Ouvrez-le pour le modifier :

      • sudo nano /etc/caddy/Caddyfile

      Activez le plugin en ajoutant la ligne suivante au bloc de configuration :

      /etc/caddy/Caddyfile

      :80 {
        root /var/www
        gzip
        minify
      }
      

      Maintenant, redémarrez votre serveur en utilisant systemctl :

      • sudo systemctl restart caddy

      Caddy est maintenant lancé et va minifier tous les fichiers qu’il sert, y compris le fichier index.html que vous avez créé précédemment. Vous pouvez observer la « minification » à l’œuvre en récupérant le contenu de votre domaine à l’aide de curl :

      Vous verrez la sortie suivante. Notez que tous les espaces blancs inutiles ont été supprimés, ce qui montre que le plugin minify fonctionne.

      Output

      <!doctype html><title>Hello from Caddy!</title><h1 style=font-family:sans-serif>This page is being served via Caddy</h1>

      Dans cette étape, vous avez appris à étendre Caddy avec des plugins. Ensuite, vous activerez HTTPS en installant le plugin tls.dns.digitalocean.

      Étape 5 – Activation du TLS automatique avec Let’s Encrypt

      Dans cette section, vous allez activer le provisionnement et le renouvellement automatique du certificat Let’s Encrypt, en utilisant les enregistrements DNS TXT pour la vérification.

      Pour vérifier l’utilisation des enregistrements DNS TXT, vous installerez un plugin pour l’interface avec l’API DigitalOcean, appelé tls.dns.digitalocean. La procédure d’installation est presque identique à celle de l’installation du plugin minify à l’étape précédente. Pour commencer, ouvrez caddy.go :

      Ajoutez le référentiel du plugin à importer :

      ~/caddy/caddy.go

      package main
      
      import (
          "github.com/caddyserver/caddy/caddy/caddymain"
      
          _ "github.com/hacdias/caddy-minify"
      
          _ "github.com/caddyserver/dnsproviders/digitalocean"
      )
      
      func main() {
          // caddymain.EnableTelemetry = false
          caddymain.Run()
      }
      

      Compilez-le en exécutant :

      Assurez-vous que Caddy est arrêté via systemctl, puis terminez l’installation du plugin en copiant le binaire Caddy nouvellement construit et en définissant une fois de plus sa propriété et ses autorisations :

      • sudo systemctl stop caddy
      • sudo mv $GOPATH/bin/caddy /usr/local/bin/
      • sudo chown root:root /usr/local/bin/caddy
      • sudo chmod 755 /usr/local/bin/caddy
      • sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

      Ensuite, configurez Caddy pour qu’il fonctionne avec l’API DigitalOcean pour établir des enregistrements DNS. Caddy doit accéder à ce jeton en tant que variable d’environnement pour configurer le DNS de DigitalOcean, vous allez donc éditer son fichier d’unité systemd :

      • sudo nano /etc/systemd/system/caddy.service

      Trouvez la ligne commençant par Environment= dans la section [Service]. Cette ligne définit les variables d’environnement qui doivent être transmises au processus Caddy. Ajoutez un espace à la fin de cette ligne, puis ajoutez une variable DO_AUTH_TOKEN, suivie du jeton que vous venez de générer :

      /etc/systemd/system/caddy.service

      [Service]
      Restart=on-abnormal
      
      ; User and group the process will run as.
      User=www-data
      Group=www-data
      
      ; Letsencrypt-issued certificates will be written to this directory.
      Environment=CADDYPATH=/etc/ssl/caddy DO_AUTH_TOKEN=your_token_here
      

      Enregistrez et fermez ce fichier, puis rechargez le démon systemd comme vous l’avez fait précédemment pour vous assurer que la configuration est mise à jour :

      • sudo systemctl daemon-reload

      Exécutez systemctl status pour vérifier que vos modifications de configurations étaient correctes :

      • sudo systemctl status caddy

      La sortie devrait ressembler à ceci :

      Output

      ● caddy.service - Caddy HTTP/2 web server Loaded: loaded (/etc/systemd/system/caddy.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: https://caddyserver.com/docs ...

      Vous devrez apporter quelques légères modifications à votre Caddyfile, alors ouvrez-le pour l’éditer :

      • sudo nano /etc/caddy/Caddyfile

      Ajoutez les lignes surlignées au Caddyfile, en veillant à remplacer your_domain par votre domaine (au lieu du seul port :80) et en commentant gzip :

      /etc/caddy/Caddyfile

      your_domain {
        root /var/www
        #gzip
        minify
        tls {
            dns digitalocean
        }
      }
      

      L’utilisation d’un domaine plutôt que d’un simple port pour le nom d’hôte amènera Caddy à servir des requêtes via HTTPS. La directive tls configure le comportement de Caddy lors de l’utilisation de TLS, et la sous-directive dns spécifie que Caddy doit utiliser le système DNS-01, plutôt que HTTP-01.

      Votre site Web est ainsi prêt à être déployé. Démarrez Caddy avec systemctl puis activez-le avec la commande enable, afin qu’il s’exécute au démarrage :

      • sudo systemctl start caddy
      • sudo systemctl enable caddy

      Si vous naviguez sur votre domaine, vous serez automatiquement redirigé vers HTTPS, avec le même message affiché.

      Votre installation de Caddy est maintenant complète et sécurisée, et vous pouvez la personnaliser davantage en fonction de votre cas d’utilisation.

      Si vous souhaitez mettre à jour Caddy lorsqu’une nouvelle version sort, vous devrez mettre à jour le fichier go.mod (stocké dans le même répertoire), qui ressemble à ceci :

      ~/caddy/go.mod

      module caddy
      
      go 1.14
      
      require (
              github.com/caddyserver/caddy v1.0.5
              github.com/caddyserver/dnsproviders v0.4.0
              github.com/hacdias/caddy-minify v1.0.2
      )
      

      La partie surlignée est la version de Caddy que vous utilisez. Lorsqu’une nouvelle version est publiée sur Github (voir la page des balises de sortie), vous pouvez remplacer celle qui existe dans go.mod par celle-ci et compiler Caddy selon les deux premières étapes. Vous pouvez faire de même pour tous les plugins importés.

      Conclusion

      Caddy est maintenant installé et configuré sur votre serveur, et sert des pages statiques sur le domaine souhaité, sécurisé par des certificats TLS Let’s Encrypt gratuits.

      Une bonne étape suivante consisterait à trouver un moyen d’être averti lorsque de nouvelles versions de Caddy sont publiées. Par exemple, vous pourriez utiliser le flux Atom pour les sorties Caddy, ou un service dédié tel que dependencies.io.

      Vous pouvez consulter la documentation de Caddy pour plus d’informations sur la configuration de Caddy.



      Source link