Très souvent, nous devons travailler avec des certificats SSL. Rappelons le processus de création et d'installation d'un certificat (dans le cas général pour la plupart).
- Trouvez un fournisseur (un site sur lequel nous pouvons acheter SSL).
- Générez la RSE.
- Envoyez-le à votre fournisseur.
- Vérifiez la propriété du domaine.
- Obtenez un certificat.
- Convertissez le certificat au format souhaité (facultatif). Par exemple, de pem à PKCS # 12.
- Installez le certificat sur le serveur Web.
Relativement rapide, pas compliqué et compréhensible. Cette option est tout à fait appropriée si nous avons un maximum d'une douzaine de projets. Et s'il y en a plus, et qu'ils ont au moins trois environnements? Dev classique - mise en scène - production. Dans ce cas, vous devriez penser à automatiser ce processus. Je vous suggère de creuser plus profondément le problème et de trouver une solution qui minimise le temps nécessaire pour créer et maintenir des certificats à l'avenir. L'article présentera une analyse du problème et un petit guide de répétition.
Je ferai une réservation à l'avance: la principale spécialisation de notre entreprise est .net, et, par conséquent, IIS et les autres fenêtres issues de Windows. Par conséquent, le client ACME et toutes ses actions seront également décrits en termes d'utilisation de Windows.
Pour qui est-ce pertinent et quelques données sources
Société K représentée par l'auteur. URL (par exemple): company.tld
Le projet X est l'un de nos projets, avec lequel je suis arrivé à la conclusion que, tout de même, vous devez vous orienter vers un gain de temps maximal lorsque vous travaillez avec des certificats. Ce projet comprend quatre environnements: développement, test, mise en scène et production. Le développement et le test sont de notre côté, la mise en scène et la production sont du côté client.
Une caractéristique du projet est qu'il dispose d'un grand nombre de modules disponibles en tant que sous-domaines.
Autrement dit, nous avons l'image suivante:
Pour la production, le certificat générique acheté est utilisé, il n'y a pas de questions. Mais il ne couvre que le premier niveau du sous-domaine. En conséquence, s'il existe un certificat pour * .projectX.tld - alors il fonctionnera pour staging.projectX.tld, mais pour module1.staging.projectX.tld il ne le fait pas déjà. Mais je n'ai pas envie d'en acheter un autre.
Et ce n'est là qu'un exemple d'un projet d'une entreprise. Et le projet, bien sûr, n'en est pas un.
Les raisons courantes pour lesquelles tout le monde s'attaque à ce problème ressemblent à ceci:
- Plus récemment, Google a proposé de réduire la durée de validité maximale des certificats SSL . Avec toutes les conséquences.
- Faciliter le processus d'émission et de maintenance de SSL pour les besoins internes des projets et de l'entreprise dans son ensemble.
- Stockage centralisé des enregistrements de certificat, qui résout partiellement le problème de la vérification de domaine à l'aide du DNS et des mises à jour automatiques ultérieures, et résout également le problème de confiance du client. Néanmoins, CNAME provoque plus de confiance sur le serveur de la société partenaire / contractant que sur une ressource tierce.
- Eh bien, enfin, dans ce cas, l'expression «mieux vaut avoir que pas» convient parfaitement.
Choix d'un fournisseur SSL et étapes préparatoires
Parmi les options disponibles pour les certificats SSL gratuits, cloudflare et letsencrypt ont été pris en compte. Le DNS pour cela (et certains autres projets) est hébergé sur cloudflare, mais je ne suis pas fan de l'utilisation de leurs certificats. Par conséquent, il a été décidé d'utiliser letsencrypt.
Pour créer un certificat SSL générique, vous devez confirmer la propriété du domaine. Cette procédure implique la création d'un enregistrement DNS (TXT ou CNAME), avec sa vérification ultérieure lors de l'émission d'un certificat. Linux dispose d'un utilitaire appelé certbot , qui vous permet d'automatiser partiellement (ou complètement pour certains fournisseurs DNS) ce processus. Pour Windows, parmi les options client ACME trouvées et testées , j'ai opté pour WinACME .
Et l'enregistrement du domaine est créé, nous procédons à la création du certificat:
Nous sommes intéressés par la dernière conclusion, à savoir les options disponibles pour vérifier la propriété du domaine pour l'émission d'un certificat générique:
- Création manuelle d'enregistrements DNS (la mise à jour automatique n'est pas prise en charge)
- Création d'enregistrements DNS à l'aide du serveur acme-dns (plus de détails peuvent être trouvés ici .
- Création d'enregistrements DNS à l'aide de votre propre script (analogue du plugin cloudflare pour certbot).
À première vue, le troisième point est tout à fait approprié, mais si le fournisseur DNS ne prend pas en charge cette fonctionnalité? Et nous avons besoin d'un cas général. Et le cas général est celui des enregistrements CNAME, tous les soutiennent. Par conséquent, nous nous arrêtons au point 2 et allons configurer notre serveur ACME-DNS.
Configuration du serveur ACME-DNS et du processus d'émission de certificat
Par exemple, j'ai créé le domaine 2nd.pp.ua, et à l'avenir je vais l'utiliser.
Une condition préalable au bon fonctionnement du serveur est la création d'enregistrements NS et A pour son domaine. Et le premier moment désagréable que j'ai rencontré - cloudflare (au moins en mode d'utilisation gratuite) ne vous permet pas de créer simultanément un enregistrement NS et A pour le même hôte. Non pas que c'était un problème, mais en reliure c'est possible. Le support a répondu que leur panel ne le permet pas. Peu importe, créez deux entrées:
acmens.2nd.pp.ua. IN A 35.237.128.147 acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.
À ce stade, l'hôte acmens.2nd.pp.ua doit résoudre.
$ ping acmens.2nd.pp.ua PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data
Mais acme.2nd.pp.ua ne sera pas résolu, car le serveur DNS qui le dessert n'est pas encore en cours d'exécution.
Les enregistrements sont créés, allez configurer et exécuter le serveur ACME-DNS. Je vais l'avoir en direct sur le serveur Ubuntu dans le conteneur Docker , mais vous pouvez l'exécuter partout où il y a du golang. Windows va bien aussi, mais je préfère toujours un serveur Linux.
Créez les répertoires et fichiers nécessaires:
$ mkdir config $ mkdir data $ touch config/config.cfg
Profitez vim votre éditeur de texte préféré et insérez un exemple de configuration dans config.cfg.
Pour réussir, ajustez simplement les sections générales et api:
[general] listen = "0.0.0.0:53" protocol = "both" domain = "acme.2nd.pp.ua" nsname = "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" …
Si vous le souhaitez, créez également un fichier de composition de docker 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 fait. Vous pouvez courir.
$ docker-compose up -d
À ce stade, l'hôte acme.2nd.pp.ua devrait commencer à acme.2nd.pp.ua et 404 devrait apparaître sur https://acme.2nd.pp.ua
$ ping acme.2nd.pp.ua PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data. $ curl https://acme.2nd.pp.ua 404 page not found
Si cela n'apparaissait pas - docker logs -f <container_name> à l'aide, heureusement, les journaux sont tout à fait lisibles.
Nous pouvons commencer à créer un certificat. Ouvrez Powershell en tant qu'administrateur et exécutez Winacme. Nous sommes intéressés par l'élection:
- M: créer un nouveau certificat (options complètes)
- 2: entrée manuelle
- 2: [dns-01] Créez des enregistrements de vérification avec acme-dns ( https://github.com/joohoi/acme-dns )
- Lorsque nous sommes interrogés sur le lien vers le serveur ACME-DNS, nous entrons l'URL du serveur créé (https) en réponse. URL du serveur acme-dns: https://acme.2nd.pp.ua
Sur le serveur, le client émet une entrée qui doit être ajoutée au serveur DNS existant (procédure unique):
[INFO] Creating new acme-dns registration for domain 1nd.pp.ua Domain: 1nd.pp.ua Record: _acme-challenge.1nd.pp.ua Type: CNAME Content: c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua. Note: Some DNS control panels add the final dot automatically. Only one is required.
Nous créons l'enregistrement nécessaire et nous nous assurons qu'il a été créé correctement:
$ dig CNAME _acme-challenge.1nd.pp.ua +short c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Nous confirmons que nous avons créé l'entrée nécessaire dans winacme et continuons le processus de création du certificat:
Comment utiliser certbot en tant que client est décrit ici .
Ceci termine le processus de création d'un certificat, vous pouvez l'installer sur un serveur Web et l'utiliser. Si, lors de la création d'un certificat, une tâche dans le planificateur est également créée, le processus de renouvellement de certificat se produira automatiquement à l'avenir.