Il browser rifiuta il certificato, ma openssl s_client funziona

Question

Il browser rifiuta il certificato, ma openssl s_client funziona

#1 da (2 voti)
#2 da (1 voti)

2

Sto migrando un sito Web sicuro. Ho installato lo stesso certificato sul nuovo host e ho indirizzato il nome del dominio sul nuovo indirizzo IP (tramite il mio file hosts). Tuttavia, quando provo a colpire quel server con un browser web, ottengo un errore di verifica del certificato.

Per complicare le cose, il nuovo host è un servizio che utilizza SNI. Pertanto, il messaggio di errore che mi viene mostrato, che il nome di dominio non corrisponde al certificato, si riferisce al cert prima SNI. Sono dubbioso SNI è impostato in modo errato dal momento che ogni altra connessione funziona.

Per provare a diagnosticare il problema, ho usato openssl s_client . Con mio sgomento, openssl non ha problemi di connessione, e non vedo errori durante l'emissione di una richiesta HTTP:

openssl s_client -connect <ipaddress>:443 -servername <domainname> -showcerts -debug

Ci sono altri strumenti là fuori per diagnosticare perché i browser web (che ho provato con Chrome, Firefox e IE) stanno rifiutando un certificato nonostante il fatto che openssl s_client non non ?

Ecco l'output abbreviato da openssl nel caso in cui tu possa individuare il problema:

CONNECTED(00000003)
Certificate chain
 0 s:<subject details>
   i:<issuer details>
 <certificate>
 1 s:<subject details>
   i:<issuer details>
 <certificate>
 2 s:<subject>
   i:<issuer, same as subject>
 <certificate>
---
Server certificate
[certificate information]
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 4392 bytes and written 408 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: <session id>
    Session-ID-ctx:
    Master-Key: <master key>
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    <hex output>
    Start Time: 1434382473
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
read:errno=0

Aggiorna :

Rapporti di Chrome "Il certificato del server non corrisponde all'URL", ma come ho detto, questo è dovuto all'utilizzo di SNI; si lamenta che il certificato utilizzato inizialmente per la connessione non corrisponde all'URL. openssl fa la cosa SNI bene, quindi sto pensando che il browser stia rifiutando il certificato che openssl accetta.

Errore di Firefox:

uses an invalid security certificate. The certificate is only valid for the following names: (Error code: ssl_error_bad_cert_domain)

Errore IE:

The security certificate presented by this website was issued for a different website's address.

Risoluzione:

Grazie a tutti per il vostro aiuto. I dettagli sono difficili da fornire nel mio caso per una varietà di problemi. Ho trovato il problema però. Il certificato è stato correttamente installato e accettato. Quello che non ho notato è che il sito ha eseguito un reindirizzamento a un dominio per il quale il certificato non è stato installato correttamente (www.thedomainname.com). Vorrei aver notato prima.

openssl tls

posta Jacob 15.06.2015 - 17:41

fonte

2 risposte

Leggi altre domande sui tag openssl tls

Modalità promiscua e sniffing dei pacchetti Lamport OTP system

score 2 · Answer 1

...despite the fact that openssl s_client does not?

OpenSSL non verifica mai il nome host contro il certificato, ma i browser lo fanno.

...openssl s_client -connect :443 ...

Vedo che stai utilizzando s_client con l'indirizzo IP e non con il nome host. Dal momento che pretendi di avere il corretto mapping tra il nome di un indirizzo IP nel tuo file hosts usando il nome host dovrebbe funzionare anche. In caso contrario, potresti aver già trovato la causa del problema, ovvero la mappatura errata. Ovviamente è necessario utilizzare anche il nome host all'interno del browser, perché (presumo che) il certificato sia per il nome host e non per l'indirizzo IP.

Assicurati di non aver configurato un proxy con i browser perché il proxy viene risolto dal nome host, cioè non si utilizza il file hosts sul computer locale.

Se funziona con s_client e il nome host ma non con il browser e il nome host, si prega di controllare esattamente il nome comune e la sezione dei nomi alternativi del certificato. Deve corrispondere esattamente al nome host indicato nell'URL o in base alle regole per la corrispondenza dei caratteri jolly se si dispone di un certificato con caratteri jolly. Un jolly corrisponde solo a una singola etichetta, ovvero *.example.com non corrisponde a foo.bar.example.com . E example.com è diverso da www.example.com . Nota anche che se hai soggetto a nomi alternativi il nome comune potrebbe essere ignorato (a seconda del browser).

Se hai ancora problemi, aggiungi in particolare più dettagli - L'esatto URL che usi. Tieni presente che esiste una differenza se utilizzi www.example.com rispetto a example.com . - Il certificato che vedi nel browser, in particolare il nome comune e la parte del nome alternativo soggetto. E confronta questo con il certificato che ottieni da s_client e che consideri corretto.

score 1 · Answer 2

Hai fornito dettagli insufficienti per rispondere alla domanda.

Il testo di errore del browser esatto potrebbe aiutare a indicare ciò che il browser pensa sia il problema
I dettagli del certificato che sono correntemente redatti potrebbero far luce
L'output s_client redatto ci dice nothing tranne che TLS è stato negoziato, cosa che sapevamo dal fatto che il tuo browser ti ha dato un errore di verifica del certificato

Credi che l'SNI sia il problema. Il prossimo passaggio dovrebbe essere per eseguire acquisizioni di pacchetti della connessione tramite openssl e un browser, quindi confrontarli. Dovrai prestare particolare attenzione al valore dell'estensione server_name a client_hello e al certificato che il server restituisce . Questi sono i due particolari che ti diranno come funziona SNI in entrambi i casi. Se server_name e il certificato del server sono gli stessi per entrambi i client, ignorare quanto felice openssl sembra e capire perché il tuo browser è infelice. Se differiscono, capire perché.

(Nota, non è necessario decrittografare l'acquisizione dei pacchetti, i dettagli a cui tieni sono non criptati e visibili durante la negoziazione. Wireshark rende molto semplice navigare nella struttura dei pacchetti di handshake e vedere cosa c'è.)

Comprendo che non vuoi trascinare i tuoi domini qui, ma limita l'aiuto che puoi ottenere.