Intégration d’une PKI OpenSSL avec le protocole ACME pour l’automatisation des certificats internes

1. Introduction : Automatiser votre PKI interne avec ACME

La gestion manuelle des certificats SSL/TLS pour les services internes – qu’il s’agisse de serveurs web, de bases de données, d’API ou de tableaux de bord internes – représente un défi constant. Cette tâche engendre une charge opérationnelle significative, un risque d’expiration des certificats et des incohérences potentielles. Le protocole ACME (Automatic Certificate Management Environment), popularisé par Let’s Encrypt pour la sécurisation des certificats publics, offre une solution robuste pour automatiser également la gestion des certificats au sein des infrastructures à clés publiques (PKI) privées. L’adoption d’ACME en interne s’inscrit dans une tendance plus large d’automatisation et de gestion de l’infrastructure “as code”, visant non seulement la gratuité des certificats mais surtout une efficacité opérationnelle accrue et une posture de sécurité renforcée par la réduction des interventions manuelles.

Cet article a pour objectif principal de guider le lecteur à travers le processus d’intégration de son infrastructure PKI existante, basée sur OpenSSL, avec une autorité de certification (AC) compatible ACME. Cette intégration permettra l’émission, le renouvellement et, dans une certaine mesure, la révocation automatisés des certificats pour les points de terminaison internes. En mettant en œuvre une telle solution, les administrateurs peuvent considérablement alléger la charge de travail liée à la gestion des certificats internes et améliorer la sécurité globale en garantissant que tous les services internes utilisent des connexions TLS valides et fiables.

Nous explorerons les concepts fondamentaux, les choix architecturaux, la mise en place d’une AC émettrice de certificats ACME (en utilisant Smallstep CA comme exemple principal), la configuration des clients ACME courants et l’utilisation des certificats ainsi obtenus.

2. Comprendre les composants essentiels

Avant de plonger dans la mise en œuvre, il est crucial de revoir les concepts clés qui sous-tendent cette intégration.

2.1. Bref rappel : PKI OpenSSL (AC Racine, AC Intermédiaire, Chaîne de certification)

Une infrastructure à clés publiques (PKI) est un système complet permettant de créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques.4 Au cœur de toute PKI se trouve l’Autorité de Certification Racine (AC Racine). Elle constitue l’ancre de confiance ultime. Ses clés privées doivent être protégées avec le plus grand soin, idéalement conservées hors ligne.

Pour des raisons de sécurité et de flexibilité, l’AC Racine ne signe généralement pas directement les certificats d’entité finale (les certificats pour les serveurs ou les utilisateurs). Elle signe plutôt des certificats pour des Autorités de Certification Intermédiaires (AC Intermédiaires). Ces AC Intermédiaires sont ensuite responsables de l’émission des certificats d’entité finale. Cette structure hiérarchique crée une chaîne de confiance : le certificat d’entité finale est signé par une AC Intermédiaire, dont le certificat est lui-même signé par l’AC Racine. Cette hiérarchie est fondamentale pour la scalabilité et la sécurité ; la séparation des rôles est un modèle de conception critique. Une PKI “plate”, où une unique AC Racine émettrait tous les certificats, serait moins sécurisée et plus difficile à gérer. La compromission de l’AC Racine entraînerait la compromission de l’ensemble. Les AC Intermédiaires limitent l’impact d’une compromission et permettent une application plus flexible des politiques.

La sécurité de l’ensemble de la PKI repose sur la protection de la clé privée de l’AC Racine, ce qui influence directement la décision d’utiliser une AC Intermédiaire pour l’intégration ACME.

OpenSSL est l’outil de prédilection pour gérer ces opérations. Des commandes comme openssl genpkey (pour générer des clés), openssl req (pour créer des requêtes de signature de certificat - CSR), openssl x509 (pour visualiser et manipuler des certificats) et openssl ca (pour signer des certificats) sont couramment utilisées. Le fichier de configuration d’OpenSSL, typiquement openssl.cnf, joue un rôle central en définissant les politiques de l’AC et les extensions des certificats.5 Ce fichier contient des sections importantes comme [ ca ] pour les directives de l’AC, [ req ] pour les informations des requêtes de certificat, et des sections de politique pour contrôler les champs du sujet des certificats.
Figure 1 : Hiérarchie d’une PKI typique

2.2. Bref rappel : Protocole ACME (Serveur, Client, Commande, Défis, Autorisation)

Le protocole ACME (Automated Certificate Management Environment), standardisé par la RFC 8555, est conçu pour automatiser le cycle de vie des certificats X.509.1 Il facilite les interactions entre les autorités de certification et les serveurs des utilisateurs, permettant le déploiement automatisé d’une infrastructure à clés publiques à très faible coût.

Les acteurs principaux du protocole ACME sont :

• Le Client ACME : un logiciel qui s’exécute sur le serveur ou l’appareil de l’utilisateur nécessitant un certificat. Des clients populaires incluent Certbot et acme.sh.
• Le Serveur ACME : un logiciel qui s’exécute au niveau d’une autorité de certification.

La communication entre le client et le serveur ACME s’effectue via des messages au format JSON transmis sur HTTPS.

Le flux général d’obtention d’un certificat est le suivant :

1. Le client ACME crée un compte auprès du serveur ACME.
2. Le client soumet une “commande” (order) pour un nouveau certificat, spécifiant les identifiants (noms de domaine) souhaités.
3. Le serveur ACME répond en présentant des “défis” (challenges) pour chaque identifiant. Ces défis servent à prouver que le client contrôle effectivement les domaines pour lesquels il demande un certificat.
4. Le client ACME tente de relever ces défis (par exemple, en plaçant un fichier spécifique sur un serveur web pour le défi HTTP-01, ou en créant un enregistrement DNS spécifique pour le défi DNS-01).
5. Une fois le défi relevé, le client notifie le serveur.
6. Le serveur ACME vérifie que le défi a été correctement complété.
7. Si la vérification est réussie, le client soumet une Requête de Signature de Certificat (CSR).
8. Le serveur ACME vérifie la CSR et émet le certificat.

La standardisation des interactions par ACME, qui étaient auparavant manuelles ou propriétaires, a permis l’émergence d’un vaste écosystème de clients et de serveurs compatibles. Cette automatisation abaisse considérablement la barrière à l’utilisation du TLS, conduisant à une meilleure sécurité pour un plus grand nombre de services, tant publics que privés.

3. Architecture de votre PKI compatible ACME

L’objectif est d’intégrer une AC Racine OpenSSL existante avec le protocole ACME. La stratégie architecturale privilégiée consiste à maintenir l’AC Racine OpenSSL existante hors ligne. Celle-ci signera un certificat d’AC Intermédiaire pour un serveur dédié qui agira comme AC émettrice compatible ACME. Cette AC Intermédiaire en ligne gérera toutes les interactions avec les clients ACME et émettra les certificats d’entité finale.6 Le modèle “racine hors ligne, intermédiaire en ligne” est une pratique exemplaire pour la sécurité et la gestion opérationnelle des PKI. Appliquer ce modèle à l’intégration ACME en est une extension naturelle.

Pour le rôle de l’AC Intermédiaire émettrice ACME, nous utiliserons Smallstep CA (step-ca). Ce choix est justifié par ses fonctionnalités adaptées :

• Conçu pour fonctionner comme une AC intermédiaire.
• Fonctionnalité de serveur ACME intégrée.
• Bonne documentation pour l’intégration avec des racines externes.

Cette approche présente plusieurs avantages :

• Sécurité : La clé privée de l’AC Racine OpenSSL, hautement sensible, reste hors ligne et n’est utilisée qu’occasionnellement pour signer ou renouveler le certificat de l’AC Intermédiaire. Tout système connecté à un réseau, comme un serveur ACME, est intrinsèquement plus exposé qu’un système isolé. Déléguer les fonctions ACME à une AC Intermédiaire limite les conséquences d’une éventuelle compromission.
• Flexibilité : Le serveur ACME (step-ca) peut être géré, mis à jour, voire remplacé, sans impacter directement l’AC Racine.
• Conformité/Politique : L’AC Racine conserve le contrôle ultime, tandis que lAC Intermédiaire peut avoir des politiques spécifiquement adaptées à l’émission automatisée via ACME. La décision d’utiliser Smallstep CA est influencée par son support explicite de cette architecture (signature par une racine externe) et ses capacités ACME natives, simplifiant la solution globale. L’approche générale d’une PKI structurée avec des intermédiaires est courante. Cette architecture respecte et s’appuie sur cette structure présumée.

4. Mise en place de Smallstep CA comme votre AC Intermédiaire émettrice ACME

Cette section détaille la configuration de step-ca pour qu’elle agisse comme une AC Intermédiaire signée par votre AC Racine OpenSSL existante.

4.1. Installation et Initialisation de step-ca

L’installation de l’interface de ligne de commande step et du serveur step-ca est la première étape. Les instructions officielles de Smallstep fournissent les détails pour différents systèmes d’exploitation.

Une fois installée, la commande step ca init initialise une nouvelle PKI. Elle pose une série de questions pour configurer l’AC :

• Nom de la PKI (ex : Ma PKI Interne).
• Noms DNS ou adresses IP pour l’AC (ex : ca.internal.example.com, 10.0.0.5).
• Adresse d’écoute pour l’AC (ex : :8443).
• Nom du premier “provisioner” (un mécanisme d’authentification pour obtenir des certificats).
• Mot de passe pour ce provisioner et pour la clé de l’AC.

Il est important de noter que step ca init crée par défaut sa propre AC Racine et une AC Intermédiaire signée par cette racine. Nous allons remplacer certains de ces artefacts pour utiliser notre propre chaîne de confiance basée sur l’AC Racine OpenSSL existante. La commande step ca init fournit un point de départ pratique et la structure de configuration nécessaire, même si certains des artefacts générés sont temporaires. Les fichiers et répertoires clés créés par step ca init (généralement dans $HOME/.step ou $STEPPATH) incluent :

• certs/root_ca.crt : Le certificat de l’AC Racine auto-générée.
• secrets/root_ca_key : La clé privée de l’AC Racine auto-générée.
• certs/intermediate_ca.crt : Le certificat de l’AC Intermédiaire auto-générée.
• secrets/intermediate_ca_key : La clé privée de l’AC Intermédiaire auto-générée.
• config/ca.json : Le fichier de configuration principal de step-ca.
• config/defaults.json : Les paramètres par défaut pour le client step.

4.2. Génération d’une CSR pour l’AC Intermédiaire step-ca (La “Voie Sécurisée”)

Pour intégrer notre AC Racine OpenSSL, nous suivons une approche où la clé privée de l’AC Intermédiaire step-ca est générée localement sur le serveur step-ca et ne le quitte pas. C’est plus sécurisé que de générer la paire de clés sur la machine de l’AC Racine et de transférer la clé privée.

1. Après step ca init, supprimez la clé privée de la racine auto-générée (elle ne sera pas utilisée) et remplacez le certificat racine auto-généré par le certificat public de votre AC Racine OpenSSL existante :

shred -u $(step path)/secrets/root_ca_key
mv /chemin/vers/votre/root_ca_openssl.crt $(step path)/certs/root_ca.crt

2. Utilisez la commande step certificate create pour générer une nouvelle clé privée pour l’AC Intermédiaire step-ca et une CSR correspondante :

step certificate create "ACME Intermédiaire Mon Organisation" \
    intermediate_acme.csr intermediate_acme.key \
    --profile intermediate-ca --csr \
    --no-password --insecure

• Adaptez le nom commun ("ACME Intermédiaire Mon Organisation") et les noms de fichiers (intermediate_acme.csr, intermediate_acme.key).
• --profile intermediate-ca : Spécifie que la CSR est pour une AC intermédiaire. Cette extension est critique.
• --csr : Indique de générer une CSR au lieu d’un certificat auto-signé.
• --no-password --insecure : La clé privée intermediate_acme.key sera écrite sur le disque sans chiffrement par mot de passe à ce stade. step-ca la chiffrera ultérieurement avec son mot de passe principal lors de son chargement. Si une protection par mot de passe est souhaitée à ce niveau, omettez ces options.

La CSR (intermediate_acme.csr) est maintenant prête à être transférée de manière sécurisée à la machine hébergeant l’AC Racine OpenSSL pour signature.

4.3. Signature de la CSR de l’AC Intermédiaire par votre AC Racine OpenSSL hors ligne

Cette étape est la plus sensible du point de vue de la sécurité et doit être réalisée avec la plus grande prudence. L’AC Racine OpenSSL doit être sur une machine isolée (air-gapped) ou un module matériel de sécurité (HSM).

1. Transfert sécurisé de la CSR : Transférez le fichier intermediate_acme.csr vers la machine de l’AC Racine (par exemple, via une clé USB chiffrée).

2. Configuration d’OpenSSL (openssl.cnf) pour l’AC Racine : Assurez-vous que le fichier openssl.cnf de votre AC Racine dispose d’une section dédiée à la signature des certificats d’AC Intermédiaire (souvent nommée v3_intermediate_ca ou similaire). Cette section doit impérativement contenir :

• basicConstraints = critical, CA:TRUE
• Idéalement, pathlen:0 si cette AC Intermédiaire ne signera que des certificats d’entité finale et pas d’autres AC : basicConstraints = critical, CA:TRUE, pathlen:0.
• keyUsage = critical, keyCertSign, cRLSign Des politiques (policy) appropriées doivent également être définies pour correspondre aux composants du nom du sujet si nécessaire. La justesse des extensions v3_intermediate_ca est cruciale ; une absence de CA:TRUE empêcherait le certificat de fonctionner comme une AC Intermédiaire.

3. Commande OpenSSL pour la signature :
   Utilisez la commande openssl ca pour signer la CSR :

openssl ca -config /chemin/vers/root_ca_openssl.cnf \
           -extensions v3_intermediate_ca \
           -days 3650 -notext -md sha256 \
           -in /chemin/vers/intermediate_acme.csr \
           -out /chemin/vers/signed_intermediate_acme.crt

• Adaptez /chemin/vers/root_ca_openssl.cnf au fichier de configuration de votre AC Racine.
• Adaptez -days 3650 (10 ans) à la durée de validité souhaitée pour l’AC Intermédiaire.
• Adaptez les chemins pour intermediate_acme.csr et le certificat de sortie signed_intermediate_acme.crt. Même avec des objectifs d’automatisation via ACME, les opérations fondamentales de la PKI, surtout celles impliquant l’AC Racine, exigent des procédures strictes et une surveillance humaine.

4.Transfert sécurisé du certificat signé : Transférez le certificat signé signed_intermediate_acme.crt (et le certificat public de l’AC Racine OpenSSL, s’il n’est pas déjà sur la machine step-ca) vers la machine step-ca.

4.4. Configuration de step-ca avec l’AC Intermédiaire signée et votre AC Racine OpenSSL

Maintenant, configurez step-ca pour utiliser la nouvelle chaîne de certificats :

1. Le certificat de votre AC Racine OpenSSL doit déjà être dans $(step path)/certs/root_ca.crt (suite à l’étape 4.2).
2. Placez le certificat de l’AC Intermédiaire nouvellement signé (ex: signed_intermediate_acme.crt) dans $(step path)/certs/intermediate_ca.crt.
3. Placez la clé privée de l’AC Intermédiaire générée à l’étape 4.2 (ex: intermediate_acme.key) dans $(step path)/secrets/intermediate_ca_key.
4. Assurez-vous que le mot de passe principal de step-ca (utilisé pour chiffrer les clés comme intermediate_ca_key sur le disque) est défini de manière sécurisée et accessible à step-ca au démarrage (par exemple, via la variable d’environnement STEPPASSPHRASE ou un fichier de mot de passe)
5. Vérifiez le fichier $(step path)/config/ca.json. Les chemins pour root, crt (certificat intermédiaire) et key (clé intermédiaire) doivent pointer vers les fichiers corrects que vous venez de mettre en place. Le fichier ca.json est au cœur de la configuration de step-ca. Une cartographie correcte de la chaîne de certificats et des clés est essentielle pour que step-ca fonctionne comme une AC Intermédiaire sous l’AC Racine *OpenSSL.

{
    "root": "$(step path)/certs/root_ca.crt",
    "federatedRoots":,
    "crt": "$(step path)/certs/intermediate_ca.crt",
    "key": "$(step path)/secrets/intermediate_ca_key",
    //... autres configurations...
    "authority": {
        //... provisioners, etc....
    }
}

6. Si nécessaire, amorcez la confiance pour l’interface de ligne de commande step envers cette nouvelle configuration d’AC :

step ca bootstrap --ca-url https://<votre-hote-ca>:<port> \
                  --fingerprint $(step certificate fingerprint $(step path)/certs/root_ca.crt)

L’amorçage des clients (y compris l’interface step elle-même sur l’hôte de l’AC) avec l’empreinte de la nouvelle AC Racine OpenSSL est essentiel pour qu’ils fassent confiance aux certificats émis par cette instance de step-ca. 7. Démarrez step-ca en spécifiant le fichier de configuration et, si besoin, le fichier de mot de passe :

step-ca $(step path)/config/ca.json --password-file $(step path)/secrets/password.txt

(Adaptez la gestion du mot de passe à votre configuration).

5. Configuration de la fonctionnalité ACME dans Smallstep CA

step-ca utilise des “provisioners” pour contrôler la manière dont les certificats sont émis. Pour activer le protocole ACME, un provisioner de type ACME doit être ajouté. Les provisioners ne sont pas seulement des activateurs de protocoles comme ACME ; ils sont aussi des points où les politiques d’émission (domaines autorisés, durées des certificats, modèles X.509 spécifiques) peuvent être définies, offrant un contrôle granulaire.

Pour ajouter un provisioner ACME :

1. Utilisez la commande suivante (remplacez mon-acme-interne par le nom souhaité pour votre provisioner) :

step ca provisioner add mon-acme-interne --type ACME

Cette commande modifie ca.json ou la base de données backend si la gestion des provisioners à distance est activée. 2. Si la gestion des provisioners à distance n’est pas utilisée, redémarrez step-ca ou envoyez-lui un signal SIGHUP pour que les modifications prennent effet.

Les clients ACME ont besoin d’une “URL de répertoire” pour découvrir les capacités et les points de terminaison du serveur ACME. Pour step-ca, cette URL est typiquement de la forme :
https://<votre-hote-ca>:<port>/acme/<nom-du-provisioner>/directory
Par exemple, si step-ca est accessible à https://ca.example.com:8443 et que le provisioner ACME s’appelle mon-acme-interne, l’URL du répertoire sera :
https://ca.example.com:8443/acme/mon-acme-interne/directory.
Le nom donné au provisioner ACME fait directement partie de cette URL, que les clients devront utiliser précisément.

Des options avancées pour les provisioners ACME peuvent exister, comme les types de défis autorisés ou l’exigence d’une liaison de compte externe (EAB - External Account Binding).

6. Configuration des clients ACME pour votre AC ACME privée

Une fois step-ca configuré et opérationnel avec un provisioner ACME, l’étape suivante consiste à configurer les clients ACME (comme Certbot, acme.sh, etc.) sur vos serveurs internes pour qu’ils demandent et gèrent automatiquement les certificats auprès de votre nouvelle AC privée.

6.1. Considérations clés

Deux aspects sont cruciaux lors de la configuration de n’importe quel client ACME pour une AC privée :

1. Pointer vers l’URL du répertoire ACME correcte : Chaque client ACME doit être configuré pour utiliser l’URL du répertoire spécifique de votre instance step-ca et du provisioner ACME que vous avez créé (par exemple, https://ca.example.com:8443/acme/mon-acme-interne/directory).

2. Faire confiance à votre AC Racine OpenSSL : C’est une étape CRITIQUE. Par défaut, les clients ACME font confiance aux AC publiques connues. Pour une AC privée, les clients doivent être explicitement configurés pour faire confiance au certificat de votre AC Racine OpenSSL.**

Les méthodes courantes incluent l’utilisation d’une variable d’environnement (par exemple, REQUESTS_CA_BUNDLE pour Certbot, LEGO_CA_CERTIFICATES pour lego), d’un drapeau en ligne de commande (par exemple, –ca-bundle pour acme.sh), ou l’ajout du certificat de l’AC Racine au magasin de confiance système de la machine cliente (à utiliser avec prudence en raison de la confiance élargie que cela accorde).23 L’ajout de la racine personnalisée au magasin de confiance du système est pratique mais accorde une confiance large. Configurer explicitement la confiance par client/application offre un contrôle plus fin et est généralement plus sécurisé pour les environnements de production, conformément au principe du moindre privilège.

6.2. Tableau comparatif des types de défis ACME

Les clients ACME doivent prouver le contrôle des domaines via des défis. Le choix du type de défi dépend de l’environnement interne.

6.3. Exemple détaillé : Certbot

Certbot est un client ACME populaire développé par l’EFF.

1. Demande d’un certificat :
   Pour demander un certificat pour mon-service.interne.example.com en utilisant le mode standalone (Certbot démarre son propre serveur web temporaire) :

sudo REQUESTS_CA_BUNDLE=/chemin/vers/votre/root_ca_openssl.crt \
    certbot certonly --standalone \
    -d mon-service.interne.example.com \
    --server https://ca.example.com:8443/acme/mon-acme-interne/directory \
    --non-interactive --agree-tos --email admin@example.com

• REQUESTS_CA_BUNDLE : Indique à Certbot de faire confiance à votre AC Racine OpenSSL.
• --standalone : Mode de défi. Alternativement, --webroot -w /var/www/html si un serveur web est déjà en cours d’exécution.
• -d : Le domaine pour lequel demander le certificat.
• --server : L’URL du répertoire de votre serveur ACME step-ca.

2. Automatisation des renouvellements : La commande certbot renew tente de renouveler tous les certificats gérés par Certbot qui approchent de leur expiration. Pour automatiser cela avec cron, assurez-vous que la variable REQUESTS_CA_BUNDLE est définie dans l’environnement du cron :

0 */12 * * * root REQUESTS_CA_BUNDLE=/chemin/vers/votre/root_ca_openssl.crt certbot renew --quiet

Étant donné que step-ca émet par défaut des certificats de courte durée (24 heures), les paramètres de renouvellement par défaut de Certbot (conçus pour les certificats de 90 jours de Let’s Encrypt) sont inadéquats et doivent être ajustés. Il est crucial d’ajuster la fréquence du cron et le paramètre renew_before_expiry dans les fichiers de configuration de renouvellement de Certbot (par exemple, /etc/letsencrypt/renewal/mon-service.interne.example.com.conf). Par exemple, pour un certificat de 24 heures, vous pourriez vouloir renouveler toutes les 8 heures et définir :renew_before_expiry = 8 hours

3. Révocation d’un certificat : Pour révoquer un certificat :

sudo REQUESTS_CA_BUNDLE=/chemin/vers/votre/root_ca_openssl.crt \
    certbot revoke --cert-path /etc/letsencrypt/live/mon-service.interne.example.com/fullchain.pem \
    --reason unspecified \
    --server https://ca.example.com:8443/acme/mon-acme-interne/directory

Notez que step-ca lui-même gère le statut de révocation réel (via CRL/OCSP). Certbot ne fait qu’envoyer la requête de révocation. Certbot peut également vérifier l’état OCSP pour un renouvellement anticipé si un certificat est révoqué.28

6.4. Exemple détaillé : acme.sh

acme.sh est un autre client ACME populaire, écrit en shell Unix.

1. Demande d’un certificat : Pour demander un certificat pour mon-service.interne.example.com en utilisant le mode standalone :

acme.sh --issue -d mon-service.interne.example.com --standalone \
    --server https://ca.example.com:8443/acme/mon-acme-interne/directory \
    --ca-bundle /chemin/vers/votre/root_ca_openssl.crt

• --ca-bundle : Indique à acme.sh de faire confiance à votre AC Racine OpenSSL.
• --server : L’URL du répertoire de votre serveur ACME step-ca. D’autres modes de défi sont disponibles, comme --dns dns_cf si vous utilisez Cloudflare pour votre DNS interne et avez une clé API.

2. Automatisation des renouvellements : acme.sh installe généralement sa propre tâche cron. Il se souvient des paramètres --ca-bundle et --server utilisés lors de l’émission initiale pour les renouvellements.
   Pour les certificats de courte durée, il peut être nécessaire de forcer le renouvellement ou d’ajuster la fréquence. acme.sh utilise un flag --days qui peut être trop grossier pour des certificats de 24h, d’où la recommandation d’utiliser --force dans les tâches cron.
   Un exemple de cron pour forcer le renouvellement toutes les 8 heures pour un certificat de 24 heures :

0 */8 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" --force > /dev/null

Les différences de comportement entre les clients, comme la mémorisation des configurations par acme.sh, peuvent simplifier les lignes de commande de renouvellement, mais leur logique de renouvellement par défaut peut également nécessiter un ajustement pour des durées de certificat très courtes.

3. Révocation d’un certificat :
   Pour révoquer un certificat :

acme.sh --revoke -d mon-service.interne.example.com \
    --server https://ca.example.com:8443/acme/mon-acme-interne/directory \
    --ca-bundle /chemin/vers/votre/root_ca_openssl.crt \
    --ecc # Si la clé est ECC

Spécifiez une raison avec --revoke-reason <0-10> (0 pour non spécifié).

6.5. (Optionnel) Bref exemple : step ca CLI comme client ACME

L’interface de ligne de commande step elle-même peut agir comme un client ACME pour un serveur step-ca.

1. Demande d’un certificat :Assurez-vous que step ca bootstrap a été exécuté pour configurer l’interface CLI pour l’AC.

step ca certificate mon-service.interne.example.com my-service.crt my-service.key \
    --provisioner mon-acme-interne

Cela suppose que l’interface CLI step est déjà configurée pour faire confiance à l’AC Racine et connaît l’URL de l’AC grâce à l’amorçage.
L’utilisation de step ca comme client offre une intégration étroite si step-ca est le serveur, simplifiant potentiellement l’amorçage et la confiance. Cependant, il peut être moins riche en fonctionnalités pour des configurations de serveurs diverses que des clients dédiés.

2. Renouvellement :

step ca renew my-service.crt my-service.key --force

L’automatisation nécessiterait de scripter cela avec des vérifications (par exemple, step certificate needs-renewal).30

3. Révocation : La commande générale step ca revoke serait utilisée, mais les détails spécifiques au mode client ACME pour la révocation ne sont pas entièrement couverts dans les informations disponibles.12

step ca revoke --cert my-service.crt --key my-service.key <numéro-de-série-ou-domaine>

6.6. Tableau récapitulatif :

Configuration des clients ACME pour Smallstep CA
Le tableau suivant résume les configurations clés pour les clients ACME populaires avec step-ca.

Ce tableau fournit une référence rapide pour les options de configuration essentielles, améliorant la facilité d’utilisation pratique de cet article.

7. Utilisation de vos certificats émis par ACME

L’objectif final de l’obtention de certificats est de les utiliser pour sécuriser les communications. Une fois que vos clients ACME ont obtenu les certificats (généralement un fichier fullchain.pem contenant le certificat du serveur et la chaîne intermédiaire, et un fichier privkey.pem pour la clé privée), ils peuvent être appliqués à divers services internes.
Par exemple, pour configurer un serveur web Nginx :

server {
    listen 443 ssl;
    server_name mon-service.interne.example.com;

    ssl_certificate /etc/letsencrypt/live/mon-service.interne.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mon-service.interne.example.com/privkey.pem;

    # Autres configurations SSL/TLS et du serveur...
}

Pour un serveur web Apache :

<VirtualHost *:443>
    ServerName mon-service.interne.example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/mon-service.interne.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/mon-service.interne.example.com/privkey.pem

    # Autres configurations SSL/TLS et du VirtualHost...
</VirtualHost>

De nombreux clients ACME offrent des “hooks” ou des scripts de déploiement qui peuvent automatiser le rechargement des services après un renouvellement de certificat réussi.
Par exemple, Certbot peut être configuré pour recharger Nginx après chaque renouvellement.

Ces services internes sécurisés (une API interne, un serveur de prévisualisation pour un blog Hugo, un serveur Git auto-hébergé, etc.) peuvent maintenant être accédés de manière fiable via HTTPS. Pour un blogueur Hugo, cela pourrait signifier sécuriser l’accès à des outils de développement ou de prévisualisation, ou même à des microservices qui soutiennent l’infrastructure du blog. L’automatisation du TLS pour tous les services internes constitue une étape vers un modèle de sécurité “zero trust”, où la confiance n’est pas implicitement accordée en fonction de l’emplacement réseau.

8. Conclusion et étapes suivantes

En suivant ce guide, vous avez intégré avec succès une PKI OpenSSL existante avec une AC Intermédiaire émettrice ACME, step-ca, permettant la gestion automatisée des certificats pour vos services internes. Cette approche renforce la sécurité grâce au maintien hors ligne de l’AC Racine, aux renouvellements automatisés et à un déploiement TLS cohérent.

Pour la suite, plusieurs aspects méritent attention pour la maintenance et l’évolution de ce système :

• Mises à jour logicielles : Maintenez step-ca et vos clients ACME à jour pour bénéficier des correctifs de sécurité et des nouvelles fonctionnalités.
• Surveillance : Surveillez les processus de renouvellement ACME pour détecter et résoudre rapidement tout échec.
• Renouvellement de l’AC Intermédiaire : Établissez une politique pour le renouvellement du certificat de l’AC Intermédiaire step-ca elle-même auprès de votre AC Racine OpenSSL (par exemple, tous les 2 à 5 ans, bien avant son expiration).
• Révocation active : Si la vérification active de la révocation est critique pour vos services internes, explorez la mise en place de Listes de Révocation de Certificats (CRL) ou d’un répondeur OCSP (Online Certificate Status Protocol) pour l’AC Intermédiaire step-ca.
• Fonctionnalités avancées de step-ca : Explorez les fonctionnalités plus avancées de step-ca, telles que les modèles de certificats pour un contrôle plus fin des extensions, d’autres types de provisioners pour différents scénarios d’authentification, et les capacités d’audit.

La mise en place de ce système est une étape significative, mais sa maintenance continue est tout aussi importante. Une mentalité “configurer et oublier” est risquée pour une PKI. Ce système fournit une base solide qui peut s’adapter à l’évolution de vos architectures de services internes, comme l’adoption de microservices ou de maillages de services, en continuant de fournir une sécurité essentielle.