Comment un signataire de certificat X509 est-il vérifié?
Supposons que je crée un certificat X509 A auto-signé et que je l'utilise pour émettre le certificat B. Je mets le certificat A dans mes autorités racine de confiance afin que tous les certificats qu'il signe soient acceptés. Ma question est:
Lorsque j'utilise ensuite un service protégé par le certificat B, comment mon ordinateur sait-il qu'il a effectivement été signé par le certificat A? Le certificat parent est-il en quelque sorte intégré à son enfant?
Dans un certificat X.509 , le nom de l'émetteur (dans votre exemple, le nom de A) est également inclus (sous la forme issuerDN). En outre, un certificat peut contenir une extension qui pointe vers un endroit où le certificat de l'émetteur peut être téléchargé (le "accès aux informations de l'autorité", section 4.2.2.1 de la RFC 5280); Notez que tous les certificats étant des entités signées qui sont acceptées et utilisées uniquement après avoir vérifié ces signatures, ils peuvent être téléchargés et transportés avec peu de soin. Enfin, il est habituel, dans les protocoles où une partie peut afficher un certificat, d'afficher réellement la liste des certificats contenant les certificats CA intermédiaires nécessaires. C'est ce qui se passe, par exemple, dans un message SSL Certificate.
Tout cela donne de nombreuses façons à un ordinateur de faire construction d'un chemin de certification , c'est-à-dire reconstruire des chaînes de certificats sur lesquelles la validation (y compris la vérification des signatures cryptographiques) semble pertinente.
Lorsque l'autorité de certification émet le certificat, elle le signe à l'aide de sa clé privée. Seule la clé publique de l'autorité de certification peut vérifier que la signature est authentique et que le certificat n'a pas été falsifié.
Ce qui est étrange, c'est que la propriété de signature semble manquer dans de nombreuses instances (classe X509Certificate de .NET et lors de l'affichage d'un certificat dans Windows). J'ai trouvé que même s'il n'est pas toujours affiché, il se trouve toujours à l'intérieur du certificat. Étant donné un certificat au format binaire DER, vous pouvez le décoder en texte brut qui affiche la signature du signataire.
openssl x509 -text -noout -inform DER -in certFile.der
Signature Algorithm: sha1WithRSAEncryption
30:d9:40:ac:d8:0d:46:81:68:14:8a:c6:a7:29:96:4e:b4:58:
7b:e6:12:3f:45:4f:c6:9b:18:aa:f2:99:23:ee:48:df:5f:c0:
a3:c7:e4:ba:3a:bc:6f:58:57:fe:a8:a7:23:d0:d1:9a:47:a6:
42:1a:d8:20:e8:f1:ec:76:43:47:0b:75:d6:a1:d2:71:2b:f7:
19:96:e3:48:57:e2:36:0f:0c:25:5d:7f:f8:26:50:c2:5e:80:
8e:17:ac:37:ad:f1:e3:3c:6f:a3:20:a6:16:93:df:2b:04:9c:
22:d3:01:33:f9:4c:3b:f8:a8:39:f1:6c:41:74:de:ba:96:6a:
0b:f1:e6:f0:7b:d8:1f:42:ec:b5:73:d1:94:1b:01:4a:4c:13:
ca:5e:2b:af:fd:2c:eb:43:d3:fc:2f:ea:5a:8d:db:a9:6a:f6:
b6:9b:58:e1:b7:94:7f:14:6d:11:8b:2c:b7:4e:f3:82:ad:c4:
92:04:c4:97:a3:7a:52:e5:a0:b1:1b:8f:47:bb:43:a3:2c:1a:
fb:31:d9:51:7c:23:7b:57:8e:73:46:81:c4:25:f3:48:c5:a1:
8f:0d:3d:f2:e1:4b:fd:7f:49:b9:f9:b1:2a:c2:22:9e:8a:85:
61:bd:b7:18:8e:56:33:a4:6e:d2:7d:db:2e:37:d0:fb:9a:35:
87:c8:2a:69
De http://en.wikipedia.org/wiki/X.509
Pour valider ce certificat, il faut un deuxième certificat qui correspond à l'émetteur (Thawte Server CA) du premier certificat. Tout d'abord, on vérifie que le deuxième certificat est de type CA; c'est-à-dire qu'il peut être utilisé pour émettre d'autres certificats. Cela se fait en inspectant une valeur de l'attribut CA dans la section d'extension X509v3. Ensuite, la clé publique RSA du certificat CA est utilisée pour décoder la signature sur le premier certificat pour obtenir un hachage MD5, qui doit correspondre à un hachage MD5 réel calculé sur le reste du certificat.