Ce blog est la suite d'une série de blogs concernant les dangers liés à l'ajout d'informations sur le nom alternatif du sujet (SAN) dans une demande de signature de certificat (CSR).
Dans les blogs précédents, j'ai décrit comment les configurations requises pour ajouter des informations SAN aux demandes de signature de certificat existantes peuvent rendre l'autorité de certification vulnérable aux attaques par usurpation d'identité. En d'autres termes, si votre processus d'émission de certificats dépend de l'ajout des informations SAN du certificat après la création d'une CSR, il est probable que votre autorité de certification puisse être utilisée à des fins malveillantes.
Comment cela se fait-il ?
Pour ajouter des informations SAN à un certificat en toute sécurité, ces informations doivent être incluses dans la partie signée de la demande de certificat. Les informations SAN peuvent être soumises dans une CSR ou à côté de celle-ci. Le site Microsoft CA peut être configuré (en définissant l'indicateur de politique "EDITF_ATTRIBUTESUBJECTALTNAME2") pour faire confiance et utiliser les deux emplacements lors de l'ajout d'informations SAN à un certificat. Toutefois, le CSS ne recommande généralement pas l'utilisation de cet indicateur.
L'ajout des informations SAN après la signature d'une CSR signifie qu'il n'est pas possible d'inclure les informations SAN du certificat dans la partie signée. Les informations SAN doivent donc être ajoutées à la fin de la CSR. Cette méthode ajoute les informations SAN à la CSR sous la forme d'un attribut de demande de certificat. Dans ce cas, un attribut de demande de certificat ne peut se trouver qu'en dehors de la partie signée de la demande originale et n'est donc pas considéré comme sûr. L'ajout d'informations SAN de cette manière signifie que les informations SAN peuvent être modifiées à tout moment et par n'importe qui. En règle générale, cela n'est pas considéré comme sûr et c'est la raison pour laquelle Microsoft et CSS mettent fortement en garde contre cette méthode.
Malheureusement, c'est exactement la façon dont de nombreux administrateurs ont structuré leur flux de travail CSR. Une RSC est générée par une équipe d'application, puis envoyée au responsable des certificats pour signature. Ce dernier ajoute alors toutes les informations SAN appropriées à la demande, signe la RSC et renvoie le certificat signé. Cela vous semble familier ?
Malheureusement, je vois trop souvent ce genre de configuration. Et dans une certaine mesure, c'est compréhensible.
Mais quelle est l'alternative ?
Par le passé, j'ai suggéré que la meilleure approche consiste à s'assurer que l'équipe chargée de l'application sait quelles sont les informations SAN appropriées et que toutes les informations SAN sont incluses dans le processus de génération des CSR. Rejeter toutes les RSC qui ne contiennent pas les informations SAN appropriées et ne signer que celles qui sont correctes.
C'est toujours un bon conseil.
Mais pour les environnements où cette approche ne fonctionne tout simplement pas, il peut y avoir une alternative.
Démission des CSR
Une option plus sûre pour ajouter des informations SAN à une RSC déjà signée consiste à utiliser un certificat d'agent d'inscription (EA) pour re-signer la demande initiale. Vous pouvez alors spécifier les informations SAN correctes et re-signer la demande originale avec le certificat EA.
Cela permet d'inclure les informations SAN après la création initiale du certificat, mais toujours dans une partie signée d'une CSR.
Voici comment :
- Acquérir un certificat d'agent d'inscription
- Modifier un modèle de certificat SSL pour exiger un certificat d'EE pour la délivrance.
- Acquérir un RSE qui a besoin d'informations sur le SAN
- Utilisez le certificat EA pour resigner la CSR tout en ajoutant les informations SAN.
Voici un aperçu rapide de ces quatre étapes. Il ne s'agit pas d'une orientation normative, mais d'une vue d'ensemble du processus.
1.) Acquérir un certificat d'agent d'inscription
Il s'agit d'un certificat basé sur le modèle par défaut de l'agent d'inscription. Le certificat EA qui en résulte doit contenir l'extension de politique d'application "Certificate Request Agent". (1.3.6.1.4.1.311.20.2.1.)
Ce certificat (et la clé privée associée) doit se trouver sur un poste de travail auquel l'administrateur a accès. C'est ce certificat qu'un agent de certification sélectionnera lorsqu'il sera interrogé au cours de la procédure de re-signature.
2.) Modifier un modèle de certificat SSL pour exiger un certificat d'EE pour la délivrance.
Modifiez votre modèle SSL existant pour exiger une signature de l'EA. Ce modèle doit également être configuré pour accepter le sujet dans la demande elle-même.
Cela signifie que seules les personnes possédant un certificat d'EA pourront utiliser ce modèle. Bien que les agents d'inscription restreints ne soient pas l'objet de cet article de blog, vous pouvez envisager de spécifier un agent d'inscription spécifique pour le modèle SSL testé dans le cadre de cet exercice.
3.) Acquérir un RSE qui a besoin d'informations sur le SAN
La création d'un RSE peut se faire de multiples façons. Cet article de blog part du principe qu'un RSE existe déjà. Voici un aperçu d'un RSE existant :
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
Comme vous pouvez le voir, ce CSR a un sujet et un nom alternatif de sujet.
À des fins de démonstration, nous allons modifier les informations relatives au SAN.
4.) Utiliser le certificat EA pour re-signer la CSR en ajoutant les informations SAN.
En utilisant un simple certreq.exe commandVous pouvez utiliser le certificat EA pour re-signer la demande ci-dessus en utilisant la ligne suivante command :
certreq -policy -config "CA1.csstest.com\CSS Test CA 1" "ORIGINAL-SERVER-REQUEST.REQ" "Server-policy.inf" "Corrected-Server-Request.req"
Comme on peut le voir, ce site command précise le dossier de demande original pour construire un nouveau dossier de demande "corrigé".
Cette ligne command spécifie un fichier de politique appelé "Server-policy.inf" pour spécifier les nouvelles informations SAN correctes. Voici ce que mon "Server-policy.inf" ressemble à :
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "[email protected]&"
_continue_ = "DNS=Orange.css-vstc.com"
Comme vous pouvez le voir, il s'agit d'un simple fichier texte qui ajoute les informations SAN corrigées en tant qu'extension.
Le certreq ci-dessus command utilise le fichier "Server-policy.inf" et mon certificat EA pour ajouter les nouvelles informations SAN, puis re-signer le CSR original, créant ainsi un nouveau fichier.
Interne au nouveau CSR résultant, le processus enveloppe de nouvelles informations autour du CSR d'origine. Le contenu du CSR d'origine est toujours présent, il est simplement superposé au nouveau contenu. Voici un aperçu de ce à quoi ressemble le nouveau CSR (maintenant enveloppé) :
PKCS7/CMS Message:
CMSG_SIGNED(2)
CMSG_SIGNED_DATA_CMS_VERSION(3)
Content Type: 1.3.6.1.5.5.7.12.2 CMC Data
PKCS7 Message Content:
================ Begin Nesting Level 1 ================
CMS Certificate Request:
Tagged Attributes: 1
Extensions: 1
2.5.29.17: Flags = 0, Length = 2f
Subject Alternative Name
RFC822 [email protected]
DNS Name=Orange.css-vstc.com
================ Begin Nesting Level 2 ================
Element 0:
PKCS10 Certificate Request:
Version: 1
Subject:
CN=Demonstration Web Server v1
Name Hash(sha1): ded0833a1bb48a7a747a06598988c9e12ef97342
Name Hash(md5): bd27f43381a77a239a935f86206424e5
2.5.29.17: Flags = 0, Length = 1f
Subject Alternative Name
DNS Name=Banana.css-vstc.com
DNS Name=Banana
2.5.29.14: Flags = 0, Length = 16
Subject Key Identifier
bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Signature matches Public Key
Key Id Hash(rfc-sha1): bc bd 57 27 3a cc 63 79 01 dc 57 9c 2e 38 05 37 09 55 7b 2c
Key Id Hash(sha1): 53 bb 85 45 53 3f 9a ef aa 59 08 91 37 da b1 c7 c4 29 9d 2d
---------------- End Nesting Level 2 ----------------
Tagged Content Info: 0
Tagged Other Messages: 0
---------------- End Nesting Level 1 ----------------
Comme vous pouvez le voir, la CSR d'origine est toujours là, mais elle est désormais entourée de nouvelles informations SAN et signée avec le certificat EA.
Ce nouveau CSR serait alors simplement soumis à l'AC :
Certreq -submit -config "CA1.csstest.com\CSS Test CA 1" "Corrected-Server-Request.req" "Server.cer"
La soumission de ce certificat à l'autorité de certification aboutira à un certificat dont les informations relatives au SAN seront mises à jour par un agent de certification. Plus important encore, cela se fait sans que l'indicateur de politique EDITF_ATTRIBUTESUBJECTALTNAME2" ne soit activé.
Dans ce cas, à partir de Banana.css-vstc.com to Orange.css-vstc.com.
Le module de politique de l'autorité de certification ne rejettera pas cette demande, car ces nouvelles informations SAN se trouvent toujours dans une partie signée de la demande de signature de certificat, et sont effectivement signées. Cette solution permet à l'autorité de certification de maintenir sa sécurité tout en offrant la possibilité d'ajouter des informations SAN aux CSR existantes, de manière sûre et contrôlée.
Résumé
Si vous êtes responsable d'une entreprise PKI et que vous envisagez de définir l'indicateur de politique "EDITF_ATTRIBUTESUBJECTALTNAME2" sur votre autorité de certification afin de répondre aux exigences du flux de travail du SAN, je vous suggère d'envisager une alternative à ce paramètre de politique.
Au lieu de cela, envisagez d'utiliser un certificat EA pour re-signer les CSR tout en spécifiant des informations SAN correctes.
Renouvellement de la signature de vos RSC à l'aide de Certreq.exe avec un certificat d'agent d'enrôlement permet d'ajouter en toute sécurité des informations SAN à une CSR *après* sa création, mais d'une manière qui ne rend pas votre site PKI vulnérable aux attaques d'usurpation d'identité.
