Qu'est-ce que l'EST (Enrollment Over Secure Transport) et pourquoi est-il important ?

L'EST est reconnu pour sa facilité d'utilisation et ses fonctionnalités de sécurité, notamment l'utilisation du protocole HTTPS pour le transport sécurisé et du protocole TLS (Transport Layer Security) pour la sécurité des clients et des serveurs. Il prend également en charge des algorithmes cryptographiques supplémentaires tels que la cryptographie à courbe elliptique (ECC) et l'algorithme de signature numérique à courbe elliptique (ECDSA), contrairement à d'autres protocoles de gestion de certificats largement utilisés comme le protocole Simple Certificate Enrollment Protocol (SCEP), qui a été parrainé par Cisco et développé dans les années 1990. En conséquence, l'EST a été proposé comme remplacement du SCEP par le groupe de travail de l'Internet Engineering Task Force (IETF).

Pourquoi utiliser l'Enrollment Over Secure Transport ?

Bien qu'il n'existe pas de solution d'authentification et de chiffrement plus puissante et plus facile à utiliser que l'identité numérique fournie par l'ICP, la gestion manuelle des certificats ICP présente de nombreux risques potentiels. Les entreprises ont besoin d'une norme d'automatisation de la gestion des certificats telle que l'EST pour s'assurer que les certificats sont correctement configurés et déployés à grande échelle sans intervention humaine.

Les équipes informatiques surchargées ne peuvent pas se permettre de déployer et de gérer manuellement les certificats, car cela est risqué, prend du temps et est très sujet aux erreurs. Qu'une entreprise déploie un seul certificat SSL pour un serveur web ou gère des millions de certificats sur tous les points d'extrémité en réseau, les appareils mobiles et les identités des utilisateurs d'une organisation, le processus d'approvisionnement, de l'émission à la configuration puis au déploiement, peut prendre plusieurs heures par certificat.

De plus, la gestion manuelle des certificats expose les entreprises à un risque important de les oublier jusqu'à leur expiration, ce qui peut entraîner une panne soudaine des systèmes critiques de l'entreprise et l'exposition à des attaques malveillantes.

Le niveau d'automatisation permis par EST permet non seulement de réduire les risques, mais aussi de faire gagner un temps précieux aux administrateurs informatiques dans leurs journées chargées.

EST vs SCEP pour l'inscription des certificats

Semblable à EST, SCEP est également un protocole de gestion des certificats qui aide les administrateurs informatiques à les émettre automatiquement. SCEP a gagné en popularité auprès des entreprises en tant qu'élément important de la sécurité d'entreprise. EST et SCEP sont tous deux des protocoles satisfaisants pour l'enregistrement automatisé des certificats et offrent des processus d'enregistrement similaires.

Pourtant, le groupe de travail IETF a établi EST comme remplaçant de SCEP. En tant que protocole plus récent, EST offre une solution de gestion des certificats facile à utiliser et des fonctionnalités mises à jour qui offrent plusieurs avantages clés pour les environnements PKI d'entreprise actuels, notamment :

• Transport sécurisé : il est intrinsèquement sécurisé car toutes les demandes et réponses des clients et des serveurs sont communiquées via TLS sans qu'il soit nécessaire d'authentifier les messages en les encodant avec un identifiant secret partagé comme le fait SCEP ou par un mot de passe challenge comme le fait le protocole Automated Certificate Management Environment (ACME).
• Demandeurs de certificats désignés : Avec EST, la demande de signature de certificat (CSR) peut être associée à un demandeur de confiance spécifique qui est authentifié avec TLS. Avec SCEP, la CSR est authentifiée à l'aide d'un secret partagé entre le client et l'autorité de certification, ce qui introduit des risques de sécurité si le secret partagé est perdu ou exposé.
• Crypto-agilité et prise en charge des algorithmes : il prend en charge les algorithmes ECC et ECDSA, ce que SCEP ne fait pas car les méthodes PKCS 7 qu'il utilise pour la protection des données dépendent uniquement de l'algorithme de chiffrement RSA. De plus, cette indépendance vis-à-vis des algorithmes permet à EST d'atteindre un niveau de crypto-agilité qui établit une prise en charge inhérente des futurs algorithmes cryptographiques.
• Renouvellement automatisé des certificats : EST a été développé pour prendre en charge la réinscription automatique. Bien qu'un projet récemment soumis pour mettre à jour SCEP introduise des messages de renouvellement, il ne prenait pas en charge la réinscription auparavant. Par conséquent, les nombreuses implémentations existantes de SCEP exigent des équipes informatiques qu'elles apportent des mises à jour importantes à leurs systèmes d'administration pour prendre en charge le renouvellement automatisé des certificats.
• Génération de clés côté serveur : La génération de clés côté serveur est nécessaire pour les environnements PKI de ressources (RPKI) ou les appareils limités qui n'ont pas la capacité de générer une clé privée aléatoire. SCEP ne prend en charge que la génération de clés privées sur le client, tandis que EST permet au serveur de générer la clé privée.
• Périodes de transition pour le basculement incrémental de la racine de confiance : En cas de basculement de l'autorité de certification ou de nécessité de modifier la racine de confiance, EST adopte le modèle CMP (Certificate Management Protocol) pour le basculement des certificats de l'autorité de certification, bien qu'il n'utilise pas la syntaxe ou le protocole de message CMP. EST propose le modèle pour actualiser la racine de confiance en utilisant trois certificats pendant une période de transition. La période de transition permet un basculement progressif vers la nouvelle autorité de certification racine pour tous les certificats, tout en maintenant les communications entre les clients et le serveur EST. En revanche, le protocole SCEP exige que le basculement de l'autorité de certification pour tous les certificats se fasse en une seule fois à une date définie, ce qui expose les systèmes d'entreprise critiques à un risque de panne en cas de problème lors du basculement.
• Révocation de certificat : il n'existe aucun mécanisme permettant de récupérer le statut de révocation d'un certificat. Cela n'a pas vraiment d'importance car l'absence de fonctions de récupération de la liste de révocation des certificats (CRL) n'est pas un obstacle. Au lieu de cela, le protocole OCSP (Online Certificate Status Protocol) et l'agrafage OCSP offrent des fonctionnalités de révocation complètes et doivent être utilisés pour cette fonction. Le SCEP offre un message de récupération de la CRL afin que les points d'extrémité puissent recevoir le statut de révocation d'un certificat spécifique, mais cela a une valeur limitée car les CRL ont récemment été dépréciées par Firefox au profit de l'OCSP.

Comment fonctionne le protocole EST ?

Le service d'inscription EST normalise l'interopérabilité et l'échange sécurisé d'informations entre un client et une autorité de certification (CA) qui est nécessaire pour délivrer un certificat. Il est couramment appliqué à l'inscription de nombreux cas d'utilisation de certificats, notamment les serveurs web, les DevOps, les terminaux, les dispositifs IoT, les identités d'utilisateurs, les services de messagerie électronique et tout autre endroit où des certificats PKI sont utilisés.

Dans une architecture PKI, le service EST est situé entre un client et l'autorité de certification et remplit plusieurs fonctions traditionnellement attribuées au rôle d'autorité d'enregistrement (RA). Son travail consiste à déterminer si les clients EST doivent recevoir ou non le certificat qu'ils ont demandé. Si c'est le cas, il transmet la demande à l'autorité de certification et renvoie le certificat obtenu au client. Le client communique avec un serveur EST, qui écoute les demandes sur un chemin d'URL standard. Les clients ont juste besoin de connaître l'adresse IP du serveur pour faire des demandes.

Le processus d'inscription EST est développé pour être facile pour l'établissement de l'émission automatique de certificats à partir d'une autorité de certification de confiance. L'interaction générale client/serveur se déroule comme suit :

1. Le client lance une session HTTP sécurisée par TLS avec un serveur EST et valide le certificat proposé par le serveur.
2. Le client demande et vérifie la chaîne de confiance du serveur, y compris tous les certificats intermédiaires entre la racine et l'EST CA, et stocke le certificat racine.
3. Le client génère une clé et une CSR, puis une demande de certificat PKCS#10 et l'envoie au serveur.
4. Le serveur EST demande et reçoit le certificat émis par l'AC, puis renvoie le certificat signé au client au format PKCS#7 pour qu'il le stocke sur son appareil.

En outre, un client EST peut renouveler ou modifier son certificat client existant en soumettant une demande de réinscription à un serveur EST. D'autres demandes facultatives peuvent être acheminées via l'EST pour prendre en charge d'autres opérations de certificat, telles que la transmission d'attributs CSR qui peuvent être souhaités par l'autorité de certification et la génération de paires de clés côté serveur.

Les fonctions de demande standardisées qu'un client peut effectuer et le chemin URI correspondant comprennent :

• Distribution des certificats CA (/cacerts)
• Inscription des clients (/simpleenroll)
• Réinscription des clients (/simplereenroll)
• Gestion complète des certificats via CMS (CMC) (/fullcmc)
• Génération de clés côté serveur (/serverkeygen)
• Attributs CSR (/csrattrs)

Prise en charge de Sectigo

Sectigo reconnaît la complexité et l'ampleur des besoins des entreprises en matière de certificats. Les entreprises s'appuient sur les certificats PKI pour tout authentifier et chiffrer, des serveurs web dans le cloud et sur site aux appareils en réseau, en passant par les appareils mobiles, les identités des utilisateurs, les systèmes de messagerie, les appareils réseau, les appareils IoT, les environnements DevOps, les signatures numériques, etc. Sectigo propose des certificats SSL, Code Signing, S/MIME et autres certificats X.509 qui prennent en charge EST, ainsi qu'un système automatisé de gestion du cycle de vie des certificats de bout en bout qui permet aux entreprises de gérer les certificats à grande échelle via une interface unique.

La configuration d'un service EST de Sectigo est une tâche simple, qui s'effectue en suivant les étapes suivantes :

1. En préalable, Sectigo vous fournit une instance EST ainsi que l'URL et les identifiants d'authentification pour l'application de configuration EST.
2. Vous vous connectez à l'application de configuration dans un navigateur pour lancer le processus de configuration.
3. Vous créez un ou plusieurs adaptateurs pour connecter le service EST au système d'émission de certificats Sectigo.
4. Vous créez ensuite un ou plusieurs modèles qui mappent une demande entrante à un adaptateur, ce qui vous permet de contrôler quel client peut demander ce type de certificat particulier.

Une fois ces étapes terminées, vous êtes prêt à tester et à effectuer votre inscription ou réinscription de certificat via votre service Sectigo EST.

Pour obtenir un guide complet de la configuration EST à l'aide de Sectigo Certificate Manager, y compris la manière de créer des adaptateurs et des modèles, consultez la base de connaissances Sectigo et reportez-vous aux guides d'administration de Sectigo Certificate Manager.

Pour plus de détails sur les valeurs des paramètres à spécifier dans le profil de configuration, contactez votre responsable de compte Sectigo.