web-dev-qa-db-fra.com

Autorité de certification racine avec champs d'utilisation de clé étendue

J'ai récemment commencé à utiliser AWS Certificate Manager pour obtenir des certificats TLS gratuits pour mon équilibreur de charge. Lorsque j'inspectais la chaîne de certificats, j'ai remarqué que l'autorité de certification racine, Starfield Class 2 Certification Authority , a les valeurs d'utilisation de clé étendues suivantes:

  • Client SSL
  • Serveur SSL
  • Serveur SSL Netscape
  • Signature S/MIME
  • Cryptage S/MIME
  • Signature CRL
  • Tout but
  • Aide OCSP
  • Signature d'horodatage

J'ai ensuite ouvert le magasin des autorités de certification racines de confiance sur un ordinateur portable Windows que j'ai et j'ai commencé à regarder plusieurs des autorités de certification racine. Il s'avère que beaucoup d'entre eux ont des valeurs EKU identiques ou très similaires. Je comprends pourquoi CRL et OCSP sont présents (même si j'imagine que la racine serait maintenue hors ligne, ce qui rendrait OCSP un peu plus difficile), mais pourquoi les autres? Est-ce à dire que l'autorité de certification, en plus d'émettre des certificats, peut également signer du code, exécuter la fonctionnalité S/MIME, etc.? Ou la présence de ces valeurs signifie-t-elle que les certificats qui descendent de cette autorité de certification racine ne peuvent être utilisés que pour, au plus, ces valeurs EKU?

J'ai brièvement survolé la section Utilisation étendue des clés de la RFC 528 et la seule chose que j'ai vue sur le sujet était la suivante:

En général, cette extension n'apparaîtra que dans les certificats d'entité finale.

Pour résumer mes questions:

  1. Le fait de placer ces valeurs EKU dans le certificat de l'autorité de certification racine indique que les certificats d'entité finale descendant de cette racine peuvent avoir, au plus, ces valeurs EKU?
  2. Si non à 1, pourquoi ces valeurs sont-elles présentes dans plusieurs autorités de certification racine? Est-ce que ces autorités de certification peuvent également être utilisées à ces fins? Si oui, pourquoi voudrait-on faire cela au lieu de délivrer un certificat d'entité finale avec ces EKU?
certificatespublic-key-infrastructurecertificate-authority
3
Hmmmmm

La raison pour laquelle vous voyez que la liste ExtendedKeyUsage est simplement due à l'application utilisée par le site Web lié dans votre question pour vider la représentation textuelle du certificat.

Si vous regardez à nouveau la page, vous verrez une représentation codée en Base-64 du certificat. Copiez et collez-le dans un fichier et enregistrez-le. Videz la représentation textuelle du certificat avec OpenSSL et vous verrez simplement ce qui suit.

Remarque: Si vous exécutez Windows, enregistrez-le avec un .cer ou .crt extension et double-cliquez dessus. Windows affichera le certificat dans une interface graphique, affichant des informations similaires.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier: 
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

C'est ce à quoi il faut s'attendre - pas de KeyUsage ou ExtendedKeyUsage

Un certificat d'autorité de certification racine ne doit pas vraiment contenir d'extensions (autres que facultativement SubjectKeyUsage et AuthorityKeyUsage utilisées pour aider à la chaîne de construction) car cela limite l'utilisation du certificat pendant toute sa durée durée de vie. Ces limitations devraient être ajoutées au niveau de l'autorité de certification subordonnée.

Comme vous l'avez indiqué dans votre question, le ExtendedKeyUsage est pour le certificat particulier, pas pour la chaîne (contrairement aux contraintes de stratégie et de nom).

3
garethTheRed

Le fait de placer ces valeurs EKU dans le certificat de l'autorité de certification racine indique que les certificats d'entité finale descendant de cette racine peuvent avoir, au plus, ces valeurs EKU?

c'est correct. L'EKU valide pour un certificat particulier est (à peu près) l'intersection des restrictions d'extension EKU dans la chaîne de certificats complète. Ainsi, si un certificat CA a une extension EKU contenant OID1 et OID2, il ne peut pas émettre de certificats valides pour tout autre OID EKU.

Cependant, ce n'est pas une règle stricte, cela dépend d'une application cliente qui effectue la validation du certificat. Par exemple, pour valider le certificat de signature OCSP, il suffit d'avoir OCSP Signing (1.3.6.1.5.5.7.3.9) uniquement dans le certificat feuille (signature). Il n'est pas nécessaire que la chaîne entière soit valide pour OCSP Signing usage.

Si le certificat délivré contient un autre EKU OID et l'application client demande si le certificat est valide pour une utilisation spécifiée, le chaînage de certificats le moteur ne considérera pas le certificat valide pour cet OID.

Mise à jour 26.09.2018:

la déclaration ci-dessus ne fait pas partie du RFC. En fait, RFC ne restreint pas l'autorité de certification lors de l'émission d'EKU.

Il s'agit simplement de l'implémentation d'un fournisseur majeur. Les systèmes et les navigateurs implémentent généralement le stockage de certificats interne (magasin de certificats, KeyChain, TrustStore, etc.) et le stockage de certificats implémente des propriétés attachées au magasin, où vous ou le fournisseur pouvez attribuer des attributs supplémentaires au certificat sans modifier le certificat de signature. C'est ainsi que les contraintes EKU sont gérées dans votre exemple de certificat. Si vous ouvrez le certificat, vous ne trouverez aucune extension EKU:

enter image description here

Cependant, cela inclut en quelque sorte des contraintes:

enter image description here

Et voici comment les contraintes sont définies via le magasin de certificats Windows:

enter image description here

Comme je l'ai dit, la validation EKU à travers la chaîne est spécifique à l'application. Si l'application demande la validation EKU via la chaîne et que EKU n'est pas autorisé dans chaque certificat CA du chemin, la validation échouera. Si l'application nécessite une EKU spécifique uniquement dans le certificat feuille et que la EKU spécifiée est présentée, la validation réussira.

p.s. Sous Windows, vous n'avez pas besoin d'utiliser OpenSSL pour vider le certificat, mais vous pouvez utiliser l'outil intégré certutil.exe:

certutil -dump path\certfile.cer
2
Crypt32