Convalida una catena di certificati SSL in base a RFC 5280: Sto capendo correttamente?

11

stiamo sostituendo i certificati con l'hash SHA1 a causa della mossa di Google per consentire loro di apparire meno sicuri in Chrome. I certificati sostitutivi utilizzano una CA intermedia diversa rispetto a quelli attualmente in uso, ma la stessa CA radice. Durante i test abbiamo notato che i nostri client SSL non riuscivano a convalidare la catena usando i nuovi certificati che non capiamo perché.

Ecco le specifiche:

Attualmente la catena che il server invia assomiglia a questa:

  • CA principale, firmata da CA CA server dalla stessa autorità (fornita con certificato server)
  • CA intermedio 1 (fornito con certificato server)
  • Certificato server

nei nostri client SSL di cui ci fidiamo:

  • CA root, autofirmato, ma stesso CN e stessa chiave (stesso skid)! (Scaricato dall'autorità, come Mozilla incorpora nei suoi prodotti)
  • CA intermedio 1 (identico a quello inviato dal server)

Funziona con la catena di certificati corrente ma solo perché ci fidiamo di CA intermedio 1. Se rimuoviamo questo, fallisce perché il server CA X non è considerato affidabile. Ovviamente, i nuovi certificati non funzionano, perché sono firmati da un'altra CA intermedia.

Ora, dalla lettura della RFC 5280, sezione 6.1, la mia impressione è che il nostro client SSL non aderisce agli standard, perché da quello che ho letto la mia comprensione di una convalida del percorso del certificato è questa (semplificata):

  1. inizia con l'ancora di fiducia; convalidare se è ancora valido (tempo) ecc.
  2. per i seguenti certificati: controlla se il CN e la chiave del certificato precedente corrispondono agli emittenti CN e alla chiave del certificato corrente (e controlla i vincoli pathlen ecc ...)
  3. l'ultimo certificato non deve essere un certificato CA

Il punto è: il nostro client SSL non riesce a convalidare la catena perché il certificato di root che è configurato per utilizzare come un'ancora di trust ha un emittente diverso dal certificato di root presentato dal server. Tuttavia, CN e la chiave sono identici per entrambi. Dalla mia comprensione di ciò che ho letto in RFC 5280 il client SSL non dovrebbe preoccuparsi per l'emittente della sua ancora di fiducia. Non ci sono anche politiche definite nei certificati all'interno della catena che imporrebbero qualcosa di simile. Tuttavia, non so se il nostro client SSL potrebbe imporre politiche aggiuntive che porterebbero a questo (non al mio sistema).

Quindi la mia domanda è: il nostro client SSL si comporta correttamente in questo scenario o no? E, naturalmente: perché?

Grazie in anticipo

Modifica: so che il server dovrebbe solo inviare il certificato CA intermedio e non il certificato radice, tuttavia, stiamo usando ciò che l'autorità ha fornito come un cabundle insieme al certificato, che includeva il certificato di origine. Inoltre, da quello che so, il client dovrebbe ignorare il certificato di root inviato dal server in quel caso.

Inoltre, ciò che è strano è che il client si comporta come se convalisse la catena dal certificato del server a qualcosa che può fidarsi e poi si ferma, mentre le specifiche dicono che dovrebbe convalidare la catena dall'ancoraggio di sicurezza fino al certificato del server.

Modifica2: le diverse "versioni" del certificato CA radice hanno tutte lo stesso SKID - differiscono solo per l'emittente e il numero di serie (ovviamente).

Inoltre, mi è venuto in mente, dalle informazioni della prima modifica sembra che il client SSL abbia bisogno del certificato di root in trust e chain per essere identico nel suo emittente e possibilmente in numero seriale per accettarlo.

    
posta luxifer 31.10.2014 - 16:28
fonte

2 risposte

16

C'è X.509 , e c'è SSL / TLS . TLS si aspetta che il server invii una catena di certificati X.509, da cui il client estrarrà la chiave pubblica del server. Poi le cose divergono:

  • In puro X.509, il server deve inviare il suo certificato per il client da convalidare; possibilmente, il server potrebbe aggiungere una serie non regolamentata di certificati extra che potrebbero rivelarsi utili per il cliente, in pratica alcune CA intermedie potenzialmente rilevanti. Il cliente sarebbe comunque libero di convalidare il certificato in qualsiasi modo lo ritenga opportuno, in particolare attraverso la costruzione di catene arbitrarie. Questo metodo è dimostrato, ad esempio, in CMS (precedentemente noto come "PKCS # 7"), in cui un documento ( SignedData ) fa riferimento al certificato del firmatario e facoltativamente include un set non ordinato (ASN.1 " SET ") di certificati aggiuntivi.

  • In SSL / TLS, le cose non vanno in questo modo. Invece, il server dovrebbe inviare la catena esatta che deve essere utilizzata; il server è esplicitamente autorizzato ad omettere la CA radice, ma questo è tutto. Qualsiasi cliente ha il diritto (almeno storicamente, se non de jure ) di rifiutare il certificato del server se la catena non corrisponde a questo modello. Ovviamente, qualsiasi client è consentito a fare uno sforzo e provare a convalidare il certificato del server in modo X.509, con la propria costruzione del percorso; ma ci sono client SSL là fuori che non fanno un tale sforzo.

Un estratto pertinente di RFC 5246 si trova in appendice F.1.1 :

If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority.

Questo è il passaggio che dà ai client SSL il "diritto" di rifiutare senza troppe cerimonie catene di server che non possono essere convalidati "così come sono".

Nel tuo caso, la catena inviata dal server è:

Root-X - > CA1 - > Server

dove "Root-X" è "la radice firmata da CA CA Server". Il client pigro prova a convalidare quella catena due volte:

  1. Il primo tentativo si basa sul presupposto che la catena include la CA radice. Il client non trova "Root-X" nell'elenco della propria CA radice, quindi fallisce.

  2. Il secondo tentativo si basa sul presupposto che la catena non includa la CA radice. Il client esegue la scansione della CA radice per un emittente per Root-X (e questo è il punto critico). Non ne trova, quindi fallisce.

Per convalidare la catena inviata dal server, il client deve essere leggermente meno pigro e provare a trovare un emittente per CA1 all'interno della propria serie di CA attendibile. Ciò richiederebbe una terza ipotesi, vale a dire che la catena inviata dal server includa una CA radice, ma non "quella giusta".

Suppongo che il tuo client SSL in errore sia un "client pigro" come sopra enunciato. Per assicurarti, prova a connetterti con Internet Explorer come client; IE, nonostante tutte le sue carenze, non è pigro quando si tratta di convalida dei certificati. IE proverà a ricostruire una catena dai certificati inviati dal server, i certificati che ha nei propri negozi e i certificati che può scaricare. In particolare, qualsiasi certificato può contenere un URL che punta al certificato per il suo emittente (che fa parte del Accesso alle informazioni dell'autorità estensione); IE (e, di fatto, Windows in generale) seguirà con gioia tale URL e raccoglierà la CA intermedia (solo HTTP, non HTTPS, per evitare un brutto loop).

Se in tal modo si può confermare che il problema è effettivamente un client pigro, le soluzioni alternative possibili sono le seguenti:

  • Modifica la catena inviata dal server in modo che includa la radice autofirmata o semplicemente termina su CA1.
  • Installa il certificato "CA CA del server" come CA attendibile nei client.
  • Modifica / configura il client in modo da non essere pigro.

Naturalmente è possibile che la catena non sia corretta in qualche altro modo, il che è difficile da valutare senza vedere effettivamente i certificati. L' algoritmo di convalida del percorso è complesso, quindi potrebbe esserci un'altra estensione che non soddisfa il cliente (ad es. il certificato potrebbe utilizzare un'estensione Name Constraints su cui l'implementazione del client SSL soffoca appena). Probabilmente, il client non è pigro, ma insiste sull'accertamento dello stato di revoca di tutti i certificati nel percorso e alcuni risponditori CRL o OCSP non aggiornati o irraggiungibili. Esistono centinaia di modi in cui la convalida dei certificati può fallire.

    
risposta data 31.10.2014 - 18:16
fonte
2

La catena fornita non dovrebbe includere la radice, se lo fa il client deve ignorarlo. Una caratteristica chiave del trust X.509 è che richiede root pre-conosciuti (o trust ancore ). Questa non è la causa del tuo problema però. L'ordine è invertito, il certificato del server dovrebbe essere il primo, seguito dal suo firmatario (e dal suo firmatario ecc. Se necessario), questo potrebbe causare problemi su alcune piattaforme, ma continua a leggere.

I clienti contemporanei non si affidano più alla ricerca della catena tramite DN (cioè il nome del certificato dell'emittente). A partire dal AKID di un certificato (identificatore della chiave di autorizzazione), il genitore è il certificato con corrispondente SKID . Lo SKID (identificatore chiave soggetto) deve essere un identificatore univoco (statisticamente), in genere deriva da un hash della chiave pubblica, ma non è necessario. Ai fini della verifica è semplicemente un identificatore opaco (cioè la verifica non lo ricalcola, confronta solo i valori). Sembra molto probabile che gli identificatori siano cambiati, anche se i nomi leggibili dall'uomo non lo sono stati.

Il controllo della catena deve iniziare dal server cert e lavorare verso la radice nella parte superiore, questo è convenzionalmente "attivo". Questo è lo stesso ordine in cui viene presentata la catena. Ogni certificato "conosce" solo il suo firmatario (CN e SKID), nient'altro sulla gerarchia.

Questo espande un po 'il processo di verifica: Controllo della catena di certificati , e questo dà un esempio che utilizza OpenSSL per riprodurre il processo di verifica tipico: link

Un altro possibile problema è ciò che costituisce la "cima", o "ancora di fiducia". Alcune CA hanno un certificato di radice autofirmato (AKID == SKID), alcune usano le firme incrociate (il certificato di firma appartiene ad un'altra CA). Dove esattamente smettere di seguire la catena è una proprietà del keystore del client, in genere in virtù di un certificato CA in una classificazione specifica.

    
risposta data 31.10.2014 - 17:08
fonte

Leggi altre domande sui tag