Diciamo che creo un certificato X509 autofirmato A e lo utilizzo per emettere il certificato B. Inserisco il certificato A nelle mie autorizzazioni root attendibili in modo che tutti i certificati firmati da esso siano accettati. La mia domanda è:
Quando poi utilizzo un servizio protetto da cert B, come fa il mio computer a sapere che è stato effettivamente firmato dal certificato A? Il certificato genitore è in qualche modo incorporato nel suo figlio?
In un certificato X.509 , è incluso anche il nome dell'emittente (nell'esempio, il nome di A) (come issuerDN ). Inoltre, un certificato può contenere un'estensione che punta a un luogo in cui è possibile scaricare il certificato dell'emittente ("Accesso alle informazioni sull'autorità", sezione 4.2.2.1 della RFC 5280); si noti che poiché tutti i certificati sono firmati entità che sono accettate e utilizzate solo dopo aver verificato queste firme, possono essere scaricate e trasportate con poca cura. Infine, è consuetudine, nei protocolli in cui una parte può mostrare un certificato, mostrare effettivamente un elenco di certificati contenente i necessari certificati CA intermedi. Questo è ciò che accade, ad esempio, in un messaggio Certificate SSL.
Tutto ciò fornisce molti modi per un computer di fare creazione di percorsi di certificazione , ovvero ricostruire catene di certificati su cui la convalida (compresa la verifica delle firme crittografiche) sembra pertinente.
Quando la CA rilascia il certificato, lo firma utilizzando la sua chiave privata. Solo la chiave pubblica della CA può verificare che la firma sia autentica e che il certificato non sia stato manomesso.
Ciò che è strano è che la proprietà della firma sembra mancare in molte istanze (la classe X509Certificate di .NET e quando si visualizza un certificato in Windows). Ho scoperto che anche se non è sempre visualizzato, è ancora all'interno del certificato. Dato un certificato in formato binario DER, puoi decodificarlo in testo semplice, che indica la firma del firmatario.
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
Da link
To validate this certificate, one needs a second certificate that matches the Issuer (Thawte Server CA) of the first certificate. First, one verifies that the second certificate is of a CA kind; that is, that it can be used to issue other certificates. This is done by inspecting a value of the CA attribute in the X509v3 extension section. Then the RSA public key from the CA certificate is used to decode the signature on the first certificate to obtain a MD5 hash, which must match an actual MD5 hash computed over the rest of the certificate.
Leggi altre domande sui tag public-key-infrastructure tls certificates certificate-authority x.509