Root CA con campi di utilizzo chiavi estese

2

Recentemente ho iniziato a utilizzare il gestore certificati di AWS per ottenere certificati TLS gratuiti per il mio servizio di bilanciamento del carico. Durante l'ispezione della catena di certificati ho notato che la CA radice, Autorità di certificazione Starfield Classe 2 , ha la seguente estensione valori di utilizzo chiave:

  • client SSL
  • server SSL
  • Server SSL Netscape
  • firma S / MIME
  • crittografia S / MIME
  • firma CRL
  • Qualsiasi scopo
  • helper OCSP
  • Firma del timestamp

Ho quindi aperto l'archivio Autorità di certificazione fonti attendibili su un computer portatile Windows in uso e ho iniziato a esaminare diverse CA radice. Si scopre che molti di loro hanno valori EKU uguali o molto simili. Capisco perché CRL e OCSP siano presenti (anche se immagino che la root sia mantenuta offline che renderebbe OCSP un po 'più difficile), ma perché gli altri? Ciò significa che la CA, oltre all'emissione di certificati, può anche firmare il codice, eseguire la funzionalità S / MIME, ecc.? Oppure la presenza di questi valori significa che i certificati che discendono da questa CA radice possono essere utilizzati solo, al massimo, per quei valori EKU?

Ho brevemente sfogliato la sezione Uso chiave esteso di RFC 5280 e l'unica cosa che ho visto sull'argomento era questo:

In general, this extension will appear only in end entity certificates.

Per riassumere le mie domande:

  1. Il posizionamento di questi valori EKU nel certificato CA radice indica che i certificati dell'entità finale discendenti da quella radice possono avere, al massimo, quei valori EKU?
  2. Se no a 1, perché questi valori sono presenti in più CA radice? È così che queste CA possono essere utilizzate anche per questi scopi? In tal caso, perché si vorrebbe farlo invece di emettere un certificato di entità finale con tali EKU?
posta Hmmmmm 23.09.2018 - 02:12
fonte

2 risposte

2

La ragione per cui vedi che l'elenco ExtendedKeyUsage è semplicemente fino all'applicazione utilizzata dal sito web collegato nella tua domanda per scaricare la rappresentazione testuale del certificato.

Se guardi nuovamente la pagina, vedrai una rappresentazione codificata Base-64 del certificato. Copia e incolla in un file e salvalo. Scarica la rappresentazione testuale del certificato con OpenSSL e vedrai semplicemente quanto segue.

Nota: se utilizzi Windows, salvalo con un'estensione .cer o .crt e fai doppio clic su di esso. Windows mostrerà il certificato in una GUI, mostrando informazioni simili.

$ 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

Questo è quello che ci si dovrebbe aspettare - no KeyUsage o ExtendedKeyUsage

Un certificato CA root non dovrebbe contenere alcuna estensione (a parte facoltativamente SubjectKeyUsage e AuthorityKeyUsage usata per aiutare la creazione di catene) in quanto limita il modo in cui il certificato può essere utilizzato per tutta la sua lunga durata. Tali limitazioni dovrebbero essere aggiunte a livello di CA subordinato.

Come hai detto nella tua domanda, ExtendedKeyUsage è per il particolare certificato, non per la catena (a differenza di criteri e vincoli di nome).

    
risposta data 23.09.2018 - 10:21
fonte
1

Does placing these EKU values in the root CA cert indicate that the end-entity certificates descending from that root can have, at most, those EKU values?

questo è corretto. L'EKU valido per un determinato certificato è (approssimativamente) l'intersezione delle restrizioni di estensione EKU nella catena completa di certificati. Pertanto, se un certificato CA ha un'estensione EKU contenente OID1 e OID2, non può emettere certificati validi per qualsiasi altro OID EKU.

Tuttavia, questa non è una regola rigorosa, dipende da un'applicazione client che esegue la convalida del certificato. Ad esempio, per convalidare il certificato di firma OCSP, è sufficiente avere OCSP Signing (1.3.6.1.5.5.7.3.9) solo nel certificato di foglia (firma). Non è necessario che l'intera catena sia valida per OCSP Signing usage .

Se il certificato rilasciato contiene un altro OID EKU e l'applicazione client chiede se il certificato è valido per l'utilizzo specificato, il motore di concatenazione dei certificati non considera il certificato valido per quell'OID.

Aggiornamento 26.09.2018:

La precedente dichiarazione

non fa parte di RFC. In effetti, RFC non limita la CA all'emissione di EKU.

È solo un'implementazione importante del fornitore. I sistemi e i browser di solito implementano lo storage cert interno (Certificate Store, KeyChain, TrustStore, ecc.) E Cert Storage implementa le proprietà associate agli store, dove voi o il venditore potete assegnare attributi aggiuntivi al certificato senza modificare il certificato di firma. Ecco come vengono gestiti i vincoli EKU nel certificato di esempio. Se apri il certificato, non troverai alcuna estensione EKU al suo interno:

Tuttavia,includeinqualchemodovincoli:

EdeccocomevengonoimpostatiivincolitramiteWindowsCertificateStore:

Come ho detto, la convalida EKU attraverso la catena è specifica dell'applicazione. Se l'applicazione richiede la convalida EKU attraverso la catena e EKU non è consentito in ogni certificato CA nel percorso, la convalida fallirà. Se l'applicazione richiede un EKU specifico solo nel certificato foglia e viene presentato EKU specificato, la convalida avrà esito positivo.

P.S. Su Windows non è necessario utilizzare OpenSSL per eseguire il dump del certificato, ma è possibile utilizzare lo strumento certutil.exe incorporato:

certutil -dump path\certfile.cer
    
risposta data 23.09.2018 - 08:00
fonte