L'autenticazione reciproca SSL non riesce

Question

L'autenticazione reciproca SSL non riesce

#1 da (5 voti)

4

Quando provo a stabilire un'autenticazione reciproca tra server e client, visualizzo gli errori di seguito.

I tempi tra server e client sono esattamente gli stessi e anche i certificati sono corretti in server e client. Qual è la causa di questo errore e quali sono i modi possibili per verificare questo errore?

  Thread-10, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01                                  ......
*** Finished
verify_data:  { 130, 243, 38, 76, 253, 223, 88, 181, 223, 28, 110, 123 }
***
[write] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 82 F3 26 4C   FD DF 58 B5 DF 1C 6E 7B  ......&L..X...n.
Padded plaintext before ENCRYPTION:  len = 48
0000: 14 00 00 0C 82 F3 26 4C   FD DF 58 B5 DF 1C 6E 7B  ......&L..X...n.
0010: F5 44 95 0D 5A D0 8E 6F   40 89 10 2D 00 5F BB CF  [email protected]._..
0020: 30 D1 C6 06 0B 0B 0B 0B   0B 0B 0B 0B 0B 0B 0B 0B  0...............
Thread-8, WRITE: TLSv1 Handshake, length = 48
Thread-8, waiting for close_notify or alert: state 1
[Raw read]: length = 5
0000: 15 03 01 00 02                                     .....
[Raw read]: length = 2
0000: 02 2E                                              ..
Thread-8, READ: TLSv1 Alert, length = 2
Thread-8, RECV TLSv1 ALERT:  fatal, certificate_unknown
%% Invalidated:  [Session-4, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
Thread-8, called closeSocket()
Thread-8, Exception while waiting for close javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
Thread-8, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
Thread-8, called close()
Thread-8, called closeInternal(true)

Il tuo aiuto è molto apprezzato.

authentication openssl tls

posta user45475 21.06.2014 - 19:03

fonte

1 risposta

Leggi altre domande sui tag authentication openssl tls

Come posso proteggere la chiave segreta? Quando presentare la domanda per un CVE?

score 5 · Answer 1

Bene, tu dici:

the certs are proper in server and client

Ma almeno uno dei sistemi non è d'accordo:

Received fatal alert: certificate_unknown

Questo messaggio indica che una parte (non si indica se si stanno mostrando registri lato client o lato server) ha ricevuto un messaggio di avviso esplicito dal server, di classe "fatale" e valore 46 (0x2E, ovvero " certificato_messaggio "). Come specificato in lo standard TLS 1.0 :

certificate_unknown
    Some other (unspecified) issue arose in processing the
    certificate, rendering it unacceptable.

L '"altro" significa che non è un problema che il certificato sia scaduto o revocato o che usi un algoritmo crittografico non supportato. Ci possono essere molte cause per cui un certificato ricevuto è "inaccettabile", in primo luogo l'impossibilità di costruire una catena valida da una CA radice affidabile riconosciuta a priori fino al certificato stesso (normalmente, i sistemi dovrebbero invia un avviso "unknown_ca" in quel caso, ma molti non hanno una precisione tale da riportare errori con i certificati).

Per approfondire il problema, dovresti:

Attiva la registrazione completa su client e server. Si mostrano i registri dal sistema che ha ricevuto il messaggio di avviso; dovresti dare un'occhiata ai log dell'altro sistema, chi ha inviato il messaggio di avviso;
Verifica la configurazione di entrambi i sistemi, in particolare, per colui che ha inviato il messaggio di avviso (cioè non quello che ha lanciato l'eccezione "avviso fatale ricevuto", ma l'altro) su quale trust si sta utilizzando per convalidare il certificato del peer;
Controlla quali catene di certificati stanno effettivamente inviando i sistemi. Poiché ciò si verifica prima che la crittografia venga attivata, i certificati dovrebbero essere visibili per alcuni strumenti di monitoraggio della rete alla Wireshark . In particolare, controlla order : in SSL / TLS, viene prima il certificato dell'entità finale, quindi la CA che lo ha emesso, quindi la CA che ha emesso tale CA e così via.

Ricorda anche che i certificati client hanno senso solo come autenticazione , non come autorizzazione . Anche se il client invia un certificato che il server può validare in relazione a una radice attendibile, questo indica solo al server chi si trova all'altra estremità della linea. Sta ancora al server decidere se quel client specifico debba essere autorizzato a procedere o meno. Ciò comporta di norma la mappatura del certificato client su un'identità o un ruolo, ad es. estraendo alcuni campi specifici dal certificato. Questo processo è completamente al di fuori dello scopo di TLS stesso, ma deve ancora verificarsi, quindi c'è un po 'di software e, soprattutto, alcune configurazioni sul lato server che probabilmente si desidera controllare.

Nella direzione opposta (convalida del certificato del server da parte del client), le regole sono specificate in RFC 2818 , almeno nel contesto di HTTPS: il nome del server previsto (estratto dall'URL di destinazione) dovrebbe apparire nel certificato del server. Al di fuori di HTTPS, spetta a ciascuna applicazione client decidere se il certificato che hanno ricevuto dal server è quello giusto, ovvero che il certificato è valido (emesso correttamente da una CA attendibile e così via) , ma anche che il server identificato è effettivamente quello con cui il cliente dovrebbe parlare. Di nuovo, configurazione.