ProHoster > Blog > administration > Vers une automatisation de l'émission de SSL

Vers une automatisation de l'émission de SSL

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 où nous pouvons acheter SSL).
  • Générer la RSE.
  • Envoyez-le au fournisseur.
  • Vérifiez la propriété du domaine.
  • Obtenir un certificat.
  • Convertissez le certificat au format souhaité (facultatif). Par exemple, de pem à PKCS #12.
  • Installez le certificat sur le serveur Web.

Relativement rapide, facile et compréhensible. Cette option est tout à fait adaptée si nous avons au maximum une dizaine de projets. Et s'il y en a plus et qu'ils ont au moins trois environnements ? Développement classique - mise en scène - production. Dans ce cas, il convient de penser à automatiser ce processus. Je propose d'approfondir un peu le problème et de trouver une solution qui minimisera davantage le temps passé à créer et à maintenir les certificats. L'article contiendra 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 société est .net, et, par conséquent, IIS et d'autres liés à la vis. 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 de base

Société K représentée par l'auteur. URL (par exemple) : société.tld

Le projet X est l'un de nos projets, dans lequel je suis arrivé à la conclusion que nous devons encore nous diriger vers un gain de temps maximal lorsque nous travaillons avec des certificats. Ce projet comporte quatre environnements : dev, test, staging et production. Le développement et les tests sont de notre côté, la mise en scène et la production sont du côté du client.

Une caractéristique du projet est qu'il comporte un grand nombre de modules qui sont disponibles en tant que sous-domaines.

C'est-à-dire que nous avons l'image suivante :

dev
Teste
Staging
Vidéo

projetX.dev.company.tld
projetX.test.company.tld
staging.projectX.tld
projetX.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 générique acheté est utilisé, il n'y a pas de questions ici. Mais il ne couvre que le premier niveau du sous-domaine. Par conséquent, s'il existe un certificat pour *.projectX.tld, il fonctionnera pour staging.projectX.tld, mais pas pour module1.staging.projectX.tld. Je ne veux pas en acheter un séparé.

Et ce n'est que sur l'exemple d'un projet d'une entreprise. Et le projet, bien sûr, n'est pas seul.

Les raisons générales pour s'attaquer à ce problème ressemblent à ceci :

  • тносительно недавно 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 SSL pour les besoins internes des projets et de l'entreprise dans son ensemble.
  • Stockage centralisé des enregistrements de certificat, qui résout en partie le problème de la validation de domaine à l'aide du DNS et du renouvellement automatique ultérieur, et résout également le problème de la confiance du client. Néanmoins, CNAME est plus fiable sur le serveur de la société partenaire/exécuteur que sur une ressource tierce.
  • Eh bien, enfin, dans ce cas, l'expression « mieux vaut avoir que ne pas avoir » convient parfaitement.

Sélection 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 quelques autres projets) est hébergé par 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 vérifier 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 a un utilitaire - certbot, ce qui vous permet d'automatiser partiellement (ou complètement pour certains fournisseurs DNS) ce processus. Pour Windows idem à partir de trouvé et testé options pour les clients ACME sur lesquelles j'ai opté WinACME.

Et l'enregistrement du domaine a été créé, passons à la création d'un certificat :

Vers une automatisation de l'émission de SSL

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 :

  1. Création manuelle d'enregistrements DNS (la mise à jour automatique n'est pas prise en charge)
  2. Création d'enregistrements DNS à l'aide du serveur acme-dns (pour plus de détails, voir ici.
  3. Création d'enregistrements DNS à l'aide de votre propre script (similaire au plugin cloudflare pour certbot).

A première vue, le troisième point est tout à fait adapté, mais si le fournisseur DNS ne supporte pas cette fonctionnalité ? Et nous avons besoin d'un cas général. Et le cas général est celui des enregistrements CNAME, tout le monde les prend en charge. Par conséquent, nous nous arrêtons au point 2 et 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 l'utiliserai à l'avenir.

Exigence obligatoire pour le bon fonctionnement du serveur est la création des enregistrements NS et A pour son domaine. Et le premier moment désagréable que j'ai rencontré est que cloudflare (du moins en mode gratuit) ne permet pas de créer simultanément un enregistrement NS et A pour le même host. Non pas que ce soit un problème, mais en liaison, c'est possible. Le support a répondu que leur panel ne permettait pas de faire cela. Peu importe, créons 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, nous devrions résoudre le problème d'hôte acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

Et ici 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 ont été créés, passons à la configuration et au démarrage du serveur ACME-DNS. Je vais le vivre sur le serveur Ubuntu dans docker conteneur, mais vous pouvez l'exécuter partout où il y a golang. Windows est 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

Utilisons vim avec votre éditeur de texte préféré et collons l'exemple dans config.cfg des configurations.

Pour un travail réussi, il suffit de corriger les sections general 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"
…

Créez également, en option, 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

Prêt. Tu peux courir.

$ docker-compose up -d

À ce stade, l'hôte doit commencer à résoudre acme.2nd.pp.ua, et apparaissent 404 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'apparaît pas - docker logs -f <container_name> pour aider, bon, les logs sont assez lisibles.

Nous pouvons commencer à créer un certificat. Ouvrez powershell en tant qu'administrateur et lancez winacme. Nous sommes intéressés par les élections :

  • 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)
  • Lorsqu'on vous demande un lien vers le serveur ACME-DNS, entrez l'URL du serveur créé (https) en réponse. URL du serveur acme-dns : https://acme.2nd.pp.ua

En réponse, le client émet un enregistrement qui doit être ajouté 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.

Vers une automatisation de l'émission de SSL

Nous créons l'entrée nécessaire et nous nous assurons qu'elle a été créée correctement :

Vers une automatisation de l'émission de SSL

$ 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 requise dans winacme et poursuivons le processus de création d'un certificat :

Vers une automatisation de l'émission de SSL

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, vous créez également une tâche dans le planificateur, à l'avenir, le processus de mise à jour du certificat se produira automatiquement.

Source: habr.com

Ajouter un commentaire