Errore cert del browser - mancata corrispondenza del cert, ma solo in determinate condizioni

3

Ok sopportami, questo è un po 'là fuori, e spero che questo sia il posto giusto per pubblicare: ho un cliente che lavora per una grande azienda, e per loro abbiamo creato un'applicazione di heroku. Può raggiungere l'app di heroku da casa, ma quando si collega alla sua rete aziendale dallo stesso laptop, riceve questo messaggio di errore nell'ultima versione di Chrome quando visita il sito: "Questo server non è stato in grado di dimostrare che è foo.bar il certificato di sicurezza è da * .herokuapp.com "Abbiamo chiesto a heroku e ritengono che il certificato sia in ordine. L'utente ha la stessa identica versione di Chrome che sto utilizzando. Non riesco a duplicare l'errore perché non sono autorizzato a connettere la stessa rete WiFi aziendale a cui si connette. Posso comunque collegarmi alla rete WiFi ospite di quell'edificio, ma immagino che non sia un test valido, dal momento che quella rete è spalancata e probabilmente partizionata dalla rete dei dipendenti.

Qualcuno ha qualche teoria su come una rete aziendale potrebbe interferire con la capacità di un browser di interpretare un certificato? Qualsiasi altra idea, ad es. forse c'è uno strumento che possiamo installare per diagnosticare? Stiamo cercando di trovare personale IT interno qualificato che possa essere d'aiuto, ma è difficile farlo in una grande azienda.

Ho aggiunto queste informazioni diagnostiche che potrebbero aiutarti a confermare cosa sta succedendo qui.

Quando eseguo openssl su entrambe le reti "buone" e "cattive", ottengo un certificato diverso per il certificato "0" (primo) nella catena, è come se ci fossero due certificati o in qualche modo hanno configurato erroneamente i certificati, ma non siamo sicuri di come siano stati mal configurati e perché funzionerebbe del tutto se questo fosse il caso. Perché il client dovrebbe vedere una catena di certificati diversa solo perché si trova su una rete diversa?

Alcune persone hanno affermato che ciò è causato da un proxy di riscrittura dei certificati sulla rete aziendale, ma il client mi ha detto che non eseguono la riscrittura dei cert.

L'output del mio comando di diagnostica:

openssl s_client -showcerts -servername foo.bar.com -connect foo.bar.com:443

Ecco l'output sulla rete "cattiva" (ho corretto i dati specifici):

> CONNECTED(00000003) depth=1 /C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> verify error:num=20:unable to get local issuer certificate verify
> return:0
> --- Certificate chain  0 s:/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com    i:/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----  1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA 
>   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High
> Assurance EV Root CA
> -----BEGIN CERTIFICATE----- xxxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com issuer=/C=US/O=DigiCert
> Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
> --- No client certificate CA names sent
> --- SSL handshake has read 2745 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES128-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES128-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624709
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE

Ecco l'output sulla rete "buona":

> CONNECTED(00000003) depth=1 /C=US/O=Symantec Corporation/OU=Symantec
> Trust Network/CN=Symantec Class 3 Secure Server CA - G4 verify
> error:num=20:unable to get local issuer certificate verify return:0
> --- Certificate chain  0 s:/C=US/ST=Maryland/L=xxx/O=xxx/OU=Headquarters/CN=foo.bar.com 
>   i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec
> Class 3 Secure Server CA - G4
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----  1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure
> Server CA - G4    i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust
> Network/OU=(c) 2006 VeriSign, Inc. - For authorized use
> only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
> -----BEGIN CERTIFICATE----- xxx
> -----END CERTIFICATE-----
> --- Server certificate subject=/C=US/ST=xxx/L=xxx/O=xxx./OU=Headquarters/CN=foo.bar.com
> issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec Class 3 Secure Server CA - G4
> --- No client certificate CA names sent
> --- SSL handshake has read 3069 bytes and written 458 bytes
> --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion:
> NONE SSL-Session:
>     Protocol  : TLSv1
>     Cipher    : AES256-SHA
>     Session-ID: xxx
>     Session-ID-ctx: 
>     Master-Key: xxx
>     Key-Arg   : None
>     Start Time: 1490624583
>     Timeout   : 300 (sec)
>     Verify return code: 0 (ok)
> --- DONE
    
posta bethesdaboys 09.03.2017 - 18:50
fonte

1 risposta

1

La società sta eseguendo un proxy di intercettazione SSL e il proxy sta emettendo il proprio certificato al posto del certificato ufficiale herokuapp.com.

Molte grandi aziende hanno connessioni SSL che terminano con un proxy in modo che possano ispezionare i contenuti per assicurarsi che siano in grado di entrare o uscire dalla rete. Quindi il proxy sostituisce il certificato con il proprio certificato. Affinché ciò funzioni, qualsiasi browser o client SSL utilizzato nell'azienda deve considerare attendibile il certificato che il proxy firma. Sembrerebbe che il client che stai utilizzando non abbia la CA della società elencata come autorità di certificazione attendibile.

La correzione consiste nell'aggiungere la CA della società come un'autorità attendibile al tuo cliente e dovresti essere bravo. Si suppone che Chrome su Windows si fidi dei certificati nel certificato Root Trusted della macchina, quindi se il computer è impostato correttamente per fidarsi del proxy, Chrome dovrebbe funzionare. Firefox mantiene il proprio elenco di CA affidabili e il certificato CA della società deve essere aggiunto in qualche modo. Altre applicazioni e strumenti, come Java, Gradle, Git, ecc. può anche dipendere da un archivio di certificati interno privato e deve essere configurato per considerare attendibile il proxy come firmatario.

Questa immagine mostra come è configurato un proxy tipico.

    
risposta data 09.03.2017 - 18:53
fonte

Leggi altre domande sui tag