Il arrive assez souvent que nous devions travailler avec des certificats SSL. Rappelons le processus de création et d'installation d'un certificat (en général, pour la plupart des cas).
- Trouver un fournisseur (un site où nous pouvons acheter un certificat SSL).
- Générer une CSR.
- L'envoyer à son fournisseur.
- Confirmer la propriété du domaine.
- Obtenir le certificat.
- Convertir le certificat dans le format souhaité (facultatif). Par exemple, de PEM en PKCS #12.
- Installer le certificat sur le serveur web.
Relativement rapide, pas compliqué et clair. Cette option convient parfaitement si nous avons au maximum une dizaine de projets. Mais si nous en avons plus, avec au moins trois environnements chacun ? Classique dev — staging — production. Dans ce cas, il vaut la peine de réfléchir à l'automatisation de ce processus. Je propose d'approfondir un peu le problème et de trouver une solution qui minimisera à l'avenir le temps consacré à la création et à la maintenance des certificats. L'article comportera une analyse du problème et un petit guide pour la répétition.
Je préviens à l'avance : la spécialisation principale de notre entreprise est .net, et par conséquent, IIS et autres dérivés Windows. Par conséquent, le client ACME et toutes les actions pour lui seront également décrits du point de vue de l'utilisation de Windows.
Pour qui cela est pertinent et certaines données sources
La société K représentée par l'auteur. URL (à titre d'exemple) : company.tld
Le projet X — l'un de nos projets, en travaillant sur lequel j'en suis arrivé à la conclusion que nous devons en effet tendre vers un maximum d'économie de temps dans le travail avec les certificats. Ce projet a quatre environnements : dev, test, staging et production. Dev et test sont de notre côté, staging et production sont du côté du client.
Une particularité du projet est qu'il comprend un grand nombre de modules, accessibles sous forme de sous-domaines.
C'est-à-dire, nous avons le tableau suivant :
Dev
Test
Staging
Production
projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.tld
module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld
module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld
…
…
…
…
moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld
Pour la production, un certificat wildcard acheté est utilisé, ce qui ne pose pas de problème. Cependant, il ne couvre que le premier niveau de sous-domaine. Par conséquent, si un certificat est pour *.projectX.tld, il fonctionnera pour staging.projectX.tld, mais pas pour module1.staging.projectX.tld. Et acheter un certificat séparé ne donne pas envie.
Et c'est juste un exemple d'un projet d'une seule entreprise. Naturellement, il n'y a pas qu'un seul projet.
Les raisons générales pour s'occuper de cette question ressemblent à peu près à ceci :
- Assez récemment, Google a proposé de réduire la durée maximale de validité des certificats SSL.. Avec toutes les conséquences qui en découlent.
- Faciliter le processus d'émission et de maintenance SSL pour les besoins internes des projets et de l'entreprise dans son ensemble.
- Un stockage centralisé des enregistrements de certificats, qui résout en partie le problème de la vérification de domaine via DNS et de la mise à jour automatique, ainsi que la question de la confiance des clients. En effet, un CNAME sur le serveur de l'entreprise du partenaire/exécutant, inspire plus de confiance qu'une ressource externe.
- Et enfin, dans ce cas, l'expression « mieux vaut avoir que ne pas avoir » s'applique parfaitement.
Choix du fournisseur SSL et étapes préparatoires
Parmi les options gratuites de certificats SSL, j'ai examiné cloudflare et letsencrypt. DNS pour cela (et quelques autres projets) est géré par cloudflare, mais je ne suis pas partisan d'utiliser leurs certificats. Donc, il a été décidé d'utiliser letsencrypt.
Pour créer SSL wildcard le certificat doit confirmer la propriété du domaine. Cette procédure implique la création d'un certain enregistrement DNS (TXT ou CNAME), suivi de sa vérification lors de l'émission du certificat. Sous Linux, il existe un utilitaire — certbot, qui permet d'automatiser ce processus partiellement (ou complètement pour certains fournisseurs DNS). Pour Windows, parmi les options trouvées et vérifiées des clients ACME, je me suis arrêté sur WinACME..
L'enregistrement pour le domaine est créé, passons à la création du certificat :
Nous sommes intéressés par le dernier affichage, à savoir — les options disponibles pour confirmer la propriété du domaine pour l'émission du certificat wildcard :
- Création manuelle des enregistrements DNS (la mise à jour automatique n'est pas supportée)
- Création des enregistrements DNS via un serveur acme-dns (vous pouvez lire plus de détails ici.
- Création des enregistrements DNS à l'aide d'un script personnalisé (l'équivalent d'un plugin cloudflare pour certbot).
À première vue, le troisième point semble tout à fait adéquat, mais que faire si le fournisseur DNS ne prend pas en charge cette fonctionnalité ? Nous avons besoin d'un cas général. Et le cas général concerne les enregistrements CNAME, que tous prennent en charge. Par conséquent, nous nous arrêtons au point 2 et nous allons configurer notre serveur ACME-DNS.
Configuration du serveur ACME-DNS et processus d'émission de certificat
Par exemple, j'ai créé le domaine 2nd.pp.ua et je vais l'utiliser par la suite.
Une exigence obligatoire pour le bon fonctionnement du serveur est la création des enregistrements NS et A pour son domaine. Et le premier point désagréable auquel j'ai été confronté — cloudflare (du moins en mode d'utilisation gratuit) ne permet pas de créer simultanément un enregistrement NS et un enregistrement A pour le même hôte. Ce n'est pas un problème en soi, mais cela peut être fait dans bind. Le support a répondu que leur panneau ne le permet pas. Pas de souci, créons deux enregistrements :
acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.
À ce stade, notre hôte devrait résoudre acmens.2nd.pp.ua.
$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) octets de données
Et voici acme.2nd.pp.ua ne résoudra pas, car le serveur DNS qui le gère n'est pas encore démarré.
Les enregistrements sont créés, passons à la configuration et au démarrage du serveur ACME-DNS. Il vivra sur mon serveur ubuntu dans docker un conteneur, mais on peut le lancer partout où il y a golang. Windows convient aussi, mais je préfère tout de même un serveur Linux.
Créons les répertoires et fichiers nécessaires :
$ mkdir config
$ mkdir data
$ touch config/config.cfg
Utilisons vim, votre éditeur de texte préféré, et insérons dans config.cfg un exemple configuration.
Pour un fonctionnement réussi, il suffit de modifier les sections général et api :
[general]
l' écoute = "0.0.0.0:53"
protocole = "les deux"
domaine = "acme.2nd.pp.ua"
nomns = "acmens.2nd.pp.ua"
nsadmin = "admin.2nd.pp.ua"
records =
"acme.2nd.pp.ua. A 35.237.128.147",
"acme.2nd.pp.ua. NS acmens.2nd.pp.ua.", ]
...
[api]
...
tls = "letsencrypt"
…
Également, si vous le souhaitez, créons un fichier docker-compose dans le répertoire principal du service :
version: '3.7'
services:
acmedns:
image: joohoi/acme-dns:latest
ports:
- "443:443"
- "53:53"
- "53:53/udp"
- "80:80"
volumes:
- ./config:/etc/acme-dns:ro
- ./data:/var/lib/acme-dns
C'est prêt. Vous pouvez démarrer.
$ docker-compose up -d
À ce stade, l'hôte devrait commencer à se résoudre acme.2nd.pp.ua, et apparaître 404 sur https://acme.2nd.pp.ua
$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) octets de données.
$ curl https://acme.2nd.pp.ua
404 page non trouvée
Si cela ne s'est pas produit — docker logs -f en aide, heureusement, les journaux sont tout à fait lisibles.
Nous pouvons commencer à créer le certificat. Ouvrons PowerShell en tant qu'administrateur et exécutons winacme. Nous nous intéressons aux choix :
- M : Créer un nouveau certificat (options complètes)
- 2 : Saisie manuelle
- 2 : [dns-01] Créer des enregistrements de vérification avec acme-dns (https://github.com/joohoi/acme-dns)
- À la question sur le lien vers le serveur ACME-DNS, nous entrons en réponse l'URL du serveur créé (https). URL du serveur acme-dns : https://acme.2nd.pp.ua
Le client délivre l'enregistrement à ajouter au serveur DNS existant (procédure unique) :
[INFO] Création d'une nouvelle inscription acme-dns pour le domaine 1nd.pp.ua
Domaine : 1nd.pp.ua
Enregistrement : _acme-challenge.1nd.pp.ua
Type : CNAME
Contenu : c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note : Certains panneaux de contrôle DNS ajoutent automatiquement le point final.
Un seul est requis.
Créons l'enregistrement nécessaire et vérifions qu'il a été créé correctement :
$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Confirmons que nous avons créé l'enregistrement requis dans winacme, et continuons le processus de création du certificat :
Comment utiliser certbot en tant que client est décrit ici.
À ce stade, le processus de création du certificat est terminé, vous pouvez l'installer sur le serveur web et l'utiliser. Si lors de la création du certificat, une tâche est également créée dans le planificateur, le processus de mise à jour du certificat se fera automatiquement par la suite.
Source : habr.com
