Problema con OpenSSL che rifiuta CA probabilmente a causa di un numero di serie di 12 cifre

1

Lavoro come tester presso una società di software VoIP. Ci siamo imbattuti in un problema con l'utilizzo di TLS per comunicare con determinati telefoni. I telefoni provengono da produttori diversi ma entrambi presentano lo stesso problema. Per riassumere il più sinteticamente possibile, il telefono rifiuta il certificato fornito durante l'handshake SSL con "CA sconosciuta".

I telefoni usano versioni di OpenSSL nel loro firmware, ma non so quale versione.

Ho verificato in tutti i modi possibili che il certificato della CA attendibile fornito al telefono durante il provisioning e il certificato fornito al telefono durante l'handshake siano gli stessi e corrispondano. Tutto DOVREBBE essere d'oro, tuttavia non lo è.

Quello che ho trovato è che su un sistema in cui tutto funziona correttamente, il certificato CA fornito ha un numero di serie di 10 cifre e nel sistema in cui non è tutto, il certificato CA ha un numero di serie di 12 cifre.

Sembra che una cosa così arbitraria stia causando il rifiuto del certificato, ma questa è letteralmente l'UNICA differenza che ho potuto riscontrare confrontando i sistemi operativi e quelli non funzionanti con i loro certificati.

Questo suona come qualcosa che qualcuno ha sentito prima? Sto impazzendo? Qualsiasi aiuto è apprezzato.

- Edit--  Il nostro PBX utilizza un certificato CA autofirmato per impostazione predefinita. Quindi utilizza Cert per firmare un Cert di linea (Cert server) e firma anche i certificati utilizzati dai telefoni (certificato cliente). Ciò che sembra accadere è che quando vengono generati nuovi certificati server, lo fanno con una serie di 10 cifre.

Ho la possibilità di utilizzare certificati generati in precedenza (generati usando la stessa metodologia) che hanno serie seriali a 12 cifre. Quando si utilizza Server Cert a 12 cifre per completare l'handshake TLS, i telefoni accettano il certificato CA a 12 cifre. Quando si utilizza il Cert 10-Digit Server, i telefoni rifiutano la CA a 12 cifre come "CA sconosciuta". Questo sembra ... completamente arbitrario e sbagliato ma è quello che ho.

I nuovi certificati a 10 cifre vengono generati utilizzando OpenSSL 1.0.1i. I certs a 12 cifre venivano generati utilizzando una versione precedente (penso che sia 0.9.7e). Dubito che importi molto. Un produttore di telefoni utilizza OpenSSL 0.9.7e e l'altro utilizza OpenSSL 1.0.1c-fips

    
posta Dan Gentry 29.08.2014 - 21:40
fonte

2 risposte

1

Aggiunto come risposta almeno parziale, così posso formattare:

Quei file (nel commento a @Steffen) hanno una differenza di codifica.

ServerGroupCertificate.cer ha Oggetto contenente Org e OrgUnit come PrintableString e CommonName come T61String aka TeletexString e 12-Digit-Working.cer ha l'Emittente lo stesso, ma 10-Digit-Broken.cer (che è anche client_cert.pem ) ha Emittente tutto UTF8String. Se la tua CA (PBX) sta semplicemente copiando i valori dei caratteri da genitore a figlio, affidandosi a openssl per (ri) calcolare il tipo, che ha modificato in 1.0.1h ( non notato nei CAMBIAMENTI, che richiede qualche discussione sul maillista). La commandline di openssl copia l'intero stack-of-AVA, che conserva i tipi. Inoltre noto che i certificati figlio sono versione 3 anche se non contengono estensioni; questo è legale ma non è quello che normalmente fa la linea di comando openssl, suggerendo ancora un codice personalizzato.

Probabilmente è anche rilevante un telefono con 0.9.7e. Non ho versioni vecchie da testare, ma il file CHANGES è cumulativo e contiene una voce per 0.9.7f datata 22 marzo 2005:

*) Perform some character comparisons of different types in X509_NAME_cmp: this is needed for some certificates that reencode DNs into UTF8Strings (in violation of RFC3280) and can't or wont issue name rollover certificates. [Steve Henson]

Ciò suggerisce strongmente che 10 anni fa esistevano casi noti di CA che si comportavano in modo anomalo e un relier che utilizzava 0.9.7 o precedente non poteva gestirli. Sebbene 3280 consentito un relier per usare le regole di adattamento più semplici di X.500, che a quanto pare consentono modifiche di codifica, semplicemente non ha permesso a una CA di dipendere da allevatori che lo fanno.

Inoltre, un relier che utilizza il metodo "CAdir" di openssl potrebbe aver avuto problemi anche di più, perché le modifiche per 1.0.0 del 29 marzo 2010 includono:

*) Enhance the hash format used for certificate directory links. The new form uses the canonical encoding (meaning equivalent names will work even if they aren't identical) and uses SHA1 instead of MD5. This form is incompatible with the older format and as a result c_rehash should be used to rebuild symbolic links. [Steve Henson]

Quindi suggerisco che è necessario che la CA (s) smetta di cambiare le codifiche delle stringhe nei certificati figlio; o sostituire i certificati CA con uno (i) i cui campi nome sono già UTF8 per iniziare, nel qual caso presumibilmente la CA lo manterrà; oppure ottenere i rilevatori (telefoni) fino a 0.9.7f per "CAfile" o qualsiasi cosa che pre-riempie allo stesso modo i certificati nell'archivio di memoria e probabilmente 1.0.0 per "CAdir" o qualsiasi cosa che recuperi in modo analogo i certificati padre in modo dinamico.

HTH.

    
risposta data 06.09.2014 - 15:27
fonte
0

Ci sono molte cose strane che le persone sbagliano quando usano SSL. E mentre non ho visto questo potrebbe essere, che stanno cercando di utilizzare il numero di serie come 32 bit, il che significa un valore massimo di 4294967296 (o 2147483648 è che utilizzano int firmato). Questo si adatterebbe alla tua descrizione dove 10 cifre sono ok (almeno se sotto 4294967296), ma 12 cifre no.

Tuttavia, senza disporre di ulteriori dettagli sui certificati coinvolti, si tratta solo di un'ipotesi approssimativa su ciò che potrebbe essere sbagliato.

    
risposta data 30.08.2014 - 07:04
fonte

Leggi altre domande sui tag