L’adoption des certificats numériques et des infrastructures à clés publiques (PKI, Public Key Infrastructure) a beaucoup évolué ces dernières années. Fini le temps où les certificats étaient exclusivement associés aux SSL/TLS ; les vecteurs de conformité comme le renforcement des exigences d’authentification et le cadre réglementaire sur la signature numérique (par ex. eIDAS) ont considérablement élargi le rôle des PKI dans l’entreprise.
Le développement des usages des PKI fait également évoluer le débat. Au-delà du nombre et du type de certificats nécessaires, les enjeux se sont déplacés vers la personnalisation des déploiements PKI. On retrouve principalement au cœur des discussions les autorités de certification subordonnées, parfois appelées AC émettrices ou intermédiaires, et les raisons susceptibles de pousser une entreprise à vouloir ses propres AC subordonnées. Voyons cela de plus près.
Que sont les hiérarchies d’AC et pourquoi en avons-nous besoin ?
Avant d’aborder les AC intermédiaires/subordonnées, rappelons ce que sont les hiérarchies d’AC. On sait que les AC sont des entités qui émettent des certificats numériques. Ce que l’on sait sans doute moins, c’est qu’une autorité de certification est en fait constituée d’une série d’autorités de certification. Si certains considèrent que GlobalSign est une AC publique (au singulier), en réalité, chez GlobalSign, nous exploitons plusieurs AC. Cette hiérarchie d’AC crée une chaîne de confiance sur laquelle tous les certificats d’entité finale se fondent.
Exemples de hiérarchies d’AC
Le nombre de niveaux entre le certificat racine et le certificat d’entité finale, et le niveau global de complexité de la hiérarchie peuvent fortement varier en fonction de l’environnement. Ainsi, dans le domaine de l’Internet des Objets (IoT) et de l’Internet industriel, une partie de nos clients qui intègrent des certificats d’identité matérielle à leurs processus de fabrication ont mis en place des hiérarchies personnalisées. Une telle démarche implique la mise en œuvre d’AC subordonnées distinctes « avec certificats de confiance croisés » pour chaque composante de la chaîne d’approvisionnement, des AC propres à un site, etc. Mais, quelle que soit la complexité de la hiérarchie globale, ces hiérarchies comprennent toujours trois éléments clés :
- L’AC racine – L’AC racine est le niveau le plus élevé de la hiérarchie et sert d’ancre de confiance. Pour qu’un certificat d’entité finale soit fiable, l’autorité de certification racine à laquelle il est enchaîné doit être intégrée au système d’exploitation, au navigateur, à l’équipement ou à tout autre élément chargé de valider le certificat. Les AC racine sont ultra sécurisées et conservées hors ligne (plus d’infos ci-dessous).
- Les AC subordonnées– Elles résident entre les AC racine et les certificats d’entité finale. Leur mission : définir les types de certificats que l’AC racine est autorisée à demander. Ainsi dans les hiérarchies publiques, les AC subordonnées SSL doivent être séparées des AC subordonnées S/MIME. Dans un autre scénario courant, on sépare les AC subordonnées en fonction des différents emplacements ou on a une AC subordonnée pour les certificats avec clés ECC et une autre pour les clés RSA.
Note: on peut avoir une ou plusieurs AC subordonnées entre une AC racine et des certificats d’entité finale. Les AC subordonnées qui résident entre l’AC racine et une autre AC subordonnée sont parfois appelées AC intermédiaires (cf. sur le schéma ci-dessus, la branche la plus à droite).
- Certificats d’entité finale – Il s’agit des certificats installés sur les serveurs, les machines, le matériel cryptographique et les équipements (comme les certificats SSL/TLS émis pour les serveurs, les signatures de code, les certificats clients émis pour des particuliers qui souhaitent chiffrer leurs e-mails, signer numériquement des documents, s’authentifier…).
Chaque entité est signée par celle qui la précède dans la hiérarchie afin de créer la chaîne de confiance évoquée précédemment. L’AC racine est auto-signée et signe toutes les AC subordonnées immédiatement sous elle. Ces dernières signent à leur tour les entités qui se trouvent sous elles, à savoir qu’il peut s’agir d’AC subordonnées supplémentaires ou de certificats d’entité finale.
Cette hiérarchie est très concrètement visible. Il suffit pour cela d’afficher les détails du certificat. Sur un site Web qui utilise des certificats SSL/TLS (identifiables au préfixe HTTPS dans la barre d’adresse), si vous affichez le détail du certificat, vous pouvez voir le chemin du certificat. Ainsi, dans l’exemple ci-après, vous voyez :
- L’AC racine – « GlobalSign Root CA — R3 ».
- L’AC subordonnée – « GlobalSign Extended Validation CA — SHA256 - G3 ».
- Le certificat d’entité finale – www.globalsign.com
Exemple de chemin de certificat pour un certificat SSL/TLS de confiance publique affiché dans Chrome.
Pourquoi a-t-on besoin de hiérarchies d’AC ?
Mais alors, vous demandez — vous, pourquoi a-t-on besoin de cette chaîne de confiance ? Après tout, n’importe quelle autorité de certification de la hiérarchie peut émettre des certificats. Alors, pourquoi ne pas le faire directement à partir de la racine ? Pourquoi s’embêter à maintenir toutes ces entités distinctes ?
Tout est conditionné par la question suivante : « que se passe-t-il si une AC est compromise ? » Théoriquement, avec la mise en place des contrôles appropriés, cela ne devrait pas être possible. Cependant, si cela devait quand même se produire, il faudrait révoquer l’AC elle-même et tout ce qui se trouve « sous cette AC » ? les éventuelles AC subordonnées et tous les certificats émis. Le problème prend une tout autre dimension lorsque les AC racine sont compromises. En effet, en tant qu’ancres de confiance, ce sont elles qui doivent être distribuées et intégrées partout. En clair : pour qu’un nouveau certificat d’entité finale soit de nouveau fiable, vous devrez vous réinscrire à des programmes de racines individuels exécutés par Microsoft, Mozilla, Google, Apple (et le reste), ce qui n’est pas une mince affaire. Et si cette racine doit être une racine de confiance publique, elle doit être distribuée à chaque navigateur, système d’exploitation, équipement, console, client de messagerie, suite d’applications… et la liste est longue ! Par ailleurs, la mise à jour des racines codées en dur au niveau d’équipements matériels ou de terminaux non accessibles à distance peut être problématique (comme les terminaux points de vente, les guichets automatiques, téléphones en réseau, etc.).
D’où l’intérêt d’émettre les certificats d’entité finale à partir des AC subordonnées (d’ailleurs, pour les racines de confiance publique, le CA/Browser Forum interdit formellement l’émission à partir des racines). En procédant ainsi, on limite les dégâts, et ce qu’il faut révoquer et remplacer en cas de compromission. Si l’une de vos AC subordonnées est compromise, il « suffit » de révoquer cette AC subordonnée et les certificats qui lui sont rattachés. Dans la mesure où les certificats émis par d’autres AC subordonnées ne seraient pas impactés, vous n’auriez pas besoin de redistribuer vos ancres de confiance (c.-à-d. les AC racine). En plus de l’instauration de mesures de sécurité particulièrement strictes autour des AC racine, leur maintien hors ligne est également recommandé, sans quoi vous risquez de passer un mauvais quart d’heure si un problème survenait au niveau de votre AC racine. Idéalement, ces AC racine ne doivent être activées qu’en cas de besoin pour signer une nouvelle subordonnée ou une nouvelle liste de révocation de certificats (LRC).
Pourquoi vouloir sa propre AC subordonnée ?
Maintenant que vous savez à quoi correspondent les AC subordonnées ou intermédiaires, et où elles s’intègrent dans une architecture d’AC plus globale, on peut se demander quel intérêt peut avoir une entreprise à vouloir sa propre AC — c’est-à-dire une AC subordonnée dédiée à son nom. Voici les principales raisons généralement avancées :
Authentification client
L’authentification client basée sur des certificats valide souvent les certificats en fonction des AC subordonnées. En optant pour une AC subordonnée exclusive, vous pouvez limiter le nombre de personnes détentrices des certificats permettant d’accéder à un système. Suivant les besoins de l’organisation, ces AC subordonnées peuvent être privées ou publiques.
Inspection/Déchiffrement SSL
Pour que les dispositifs d’inspection SSL puissent déchiffrer et rechiffrer du contenu, ils doivent pouvoir émettre des certificats en fonction de leurs besoins. Il leur faut donc leurs propres AC subordonnées qui ne peuvent être des AC de confiance publique.
Consultez notre article de blog sur le sujet pour plus d’informations sur les points à prendre en considération avec les AC subordonnées et les AC racine pour l’inspection SSL.
Certificats pour cas d’utilisation spécifiques
Certains types de certificats, comme les certificats SSL/TLS et de signature de code à validation étendue (EV Code Signing), obéissent aux exigences de base du CA/Browser Forum qui précisent notamment la période de validité et la taille des clés. Si tous les certificats de confiance publique doivent respecter ces consignes, les certificats émis sous forme de hiérarchies privées n’y sont pas tenus. Ils peuvent en effet prendre en charge des applications héritées et des configurations uniques, comme des périodes de validité plus longues et des tailles de clé plus petites.
Remarque: si vous n’avez besoin que de certificats SSL/TLS privés, sans autorité de certification subordonnée dédiée, sachez que GlobalSign propose également des certificats de confiance privés partagés (non dédiés) par le biais de son service IntranetSSL.
Profils personnalisés
Vous pouvez configurer une AC subordonnée pour répondre à vos besoins spécifiques — utilisation de clés étendues, politique de certification, distribution de listes de révocation des certificats, certificats éphémères, etc.
Stratégie de marque (branding)
Pour les entreprises qui proposent des certificats à leurs clients finaux ou les regroupent avec leurs services, le fait d’avoir une AC subordonnée dédiée à leur nom leur offre des possibilités de branding supplémentaires. C’est ce que nous constatons le plus souvent dans les entreprises qui proposent des certificats SSL/TLS à leurs clients finaux (hébergeurs, créateurs de sites Web, plateformes d’e-commerce…). Le fait d’avoir leur propre AC subordonnée de confiance publique leur permet en effet de proposer des pages de commande et des certificats à leur marque.
Comment obtenir votre AC subordonnée : infrastructure à clés publiques interne ou hébergée ?
Vous pensez résoudre vos problèmes en ayant votre propre AC subordonnée ? Mais alors, vous vous demandez sans doute comment en obtenir une. Comme bien souvent aujourd’hui dans le domaine des technologies, ydeux choix s’offrent à vous : bâtir votre propre solution ou utiliser une solution en mode SaaS (Software-as-a-Service).
Pour être honnête, si vous avez besoin d’une confiance publique, la question ne se pose pas vraiment : vous allez devoir travailler avec une AC publique. Mais pour les cas d’utilisation privés, comme ceux évoqués plus haut, et d’autres scénarios spécifiques à l’entreprise, vous avez toujours la possibilité de gérer votre AC en interne.
Quel intérêt auriez-vous à exploiter votre propre AC ?
Autrefois, il n’était pas si rare de voir de grandes entreprises gérer elles-mêmes leurs PKI, généralement par le biais d’une autorité de certification et de services de certificats Microsoft. Dans le débat qui opposait solutions « maison » et solutions « en mode SaaS », on constatait qu’en plus des principaux arguments avancés — comme un meilleur contrôle et un renforcement de la sécurité — d’autres critères spécifiques aux PKI entraient en ligne de compte :
- Connexion à Active Directory : possibilité permettant d’enregistrer et d’installer automatiquement et en mode silencieux des certificats pour l’ensemble des utilisateurs et des points finaux liés à un domaine — avec à la clé, une réduction considérable du temps consacré à la gestion du cycle de vie des certificats.
- Gratuité : les services d’AC Microsoft étant inclus avec Windows Enterprise Server, vous n’avez aucun supplément à payer pour bénéficier de certificats individuels ou de tout autre service de support.
- Pas besoin de confiance publique : pour faire suite au point précédent, pourquoi une entreprise paierait-elle pour des certificats de confiance publique si elle peut obtenir gratuitement des certificats non publics ?
- AC subordonnées dédiées : en gérant votre propre PKI, vous pouvez créer vos propres AC subordonnées et vous assurer que seule votre entreprise y a accès.
L’émergence de nouveaux services permet d’envisager une externalisation des services d’AC
Dans le paragraphe précédent, j’ai bien précisé « autrefois ». En effet, bien que beaucoup d’entreprises continuent à gérer leurs propres AC internes pour des raisons tout à fait valables, plusieurs des points exposés ci-dessus ne sont plus tout à fait pertinents. La raison ? Les AC publiques ont beaucoup innové : intégration avec Active Directory, mécanismes d’automatisation, possibilité d’avoir sa propre AC subordonnée (de confiance publique ou non)… ces services sont aujourd’hui proposés par de nombreuses AC publiques.
Les coûts cachés d’une PKI interne
N’allez pas croire que je fais volontairement abstraction du facteur coût et que je sous-entends une large méconnaissance de la gratuité des AC Microsoft. Je précise en effet que le terme de « gratuité » est ici inexact. Même si vous n’avez rien à débourser pour les services d’AC de Microsoft ou les certificats MS, l’exploitation de votre propre AC a un coût qui peut réellement faire grimper le coût total de possession.
Vous aurez par exemple besoin de personnel pour gérer votre AC et le matériel de stockage de vos clés racine et clés de signature. Sachant qu’un seul module de sécurité matérielle (HSM) peut coûter 20 000 $ et qu’il vous en faudra plusieurs pour assurer la redondance, ces coûts cachés sont manifestement loin d’être négligeables.
Sécurité et PKI : les points à prendre en considération pour exploiter votre propre AC
Dans le débat qui oppose PKI internes et PKI hébergées, je pense, du moins c’est mon avis, que la sécurité de l’infrastructure, la disponibilité et le respect des exigences de base doivent être pris en considération. Si vous choisissez d’externaliser votre PKI, c’est l’AC publique qui assume la responsabilité de ces points pour vous permettre de vous concentrer sur votre cœur de métier. En revanche, en internalisant votre PKI, vous devez réfléchir aux points suivants :
- Comment protéger et stocker votre racine hors ligne ?
- Créer et maintenir une infrastructure de révocation des LRC et des OCSP
- Mettre en place un plan de reprise après sinistre pour la restauration des opérations
- Instaurer une politique et des procédures de gestion du cycle de vie des certificats pour vous assurer que seuls les utilisateurs autorisés y ont accès, que les certificats n’expirent pas et que votre hiérarchie est correctement maintenue à jour.
- Mettre en place les moyens permettant de garantir et de maintenir la conformité aux divers audits des besoins réseau et aux programmes de certificats racine (si vous avez besoin d’une confiance publique).
Pour voir comment fonctionne l’infrastructure de sécurité de GlobalSign, jetez un œil ici.
Tout cela pour dire que si vous souhaitez gérer votre propre AC interne, allez-y ! Mais, soyez conscient des implications et sachez qu’il existe des AC tierces qui peuvent vous aider à atteindre vos objectifs (automatisation, intégration avec Active Directory, hiérarchies privées, profils de certification personnalisés, services de révocation hébergés, AC subordonnées dédiées, etc.) sans que vous n’ayez à assumer vous-même la gestion de votre PKI.
Plus précisément, sachez que si vous cherchez des AC subordonnées dédiées (publiques ou privées, pour l’une ou l’autre des raisons évoquées plus haut), il existe plusieurs possibilités en mode hébergé ! Et pas besoin d’être un expert pour utiliser les PKI : il suffit de s’adresser aux bonnes personnes.
Votre AC interne vous coûte des millions d’euros. Voici la solution...
Si vous envisagez d’utiliser une AC subordonnée et/ou une PKI interne pour l’un ou l’autre des cas d’utilisation mentionnés plus haut, l’externalisation vers une AC tierce est une voie possible. La gestion des AC et des ancres de confiance, tant publiques que privées, est notre métier. Nous serons ravis de le faire pour vous. N’hésitez pas à nous contacter pour toutes vos questions.
