Certificati SSL radice e supporto browser

6

Ho dato tre certificati per l'installazione su nginx

AddTrustExternalCARoot.crt
PositiveSSLCA2.crt
www_example_com.crt

Quindi li concateno in un certificato incatenato

cat  www_example_com.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt > example.com.cert

Le mie domande:

  1. L'aggiunta di AddTrustExternalCARoot.crt è davvero necessaria per i browser moderni?
  2. Se ignoro AddTrustExternalCARoot.crt , ci sarà la possibilità che alcuni browser mostrino un avviso? Qualunque posto che vedo controlla la matrice di compatibilità del browser dei certificati radice?
  3. Perché la società SSL invia ancora AddTrustExternalCARoot.crt se non è necessaria.
posta Howard 26.07.2013 - 06:23
fonte

2 risposte

5

Nominalmente, nella pura filosofia "X.509", il client SSL dovrebbe ottenere il certificato del server e tutti i certificati CA intermedi necessari in qualsiasi modo lo ritenga opportuno, ma in particolare parlando con Directory , che è il gigantesco server LDAP mondiale che contiene tutto.

Sfortunatamente, la Directory non è mai esistita (troppo centralizzata, troppo complessa), quindi i protocolli pratici devono includere alcune disposizioni per l'invio dei certificati stessi. Succede in SSL / TLS : il server invia il proprio certificato e un mucchio di altri certificati che "possono aiutare" il cliente. In effetti, lo standard TLS specifica anche che il server DEVE inviare una catena pronta per la convalida:

certificate_list
  This is a sequence (chain) of certificates.  The sender's
  certificate MUST come first in the list.  Each following
  certificate MUST directly certify the one preceding it.  Because
  certificate validation requires that root keys be distributed
  independently, the self-signed certificate that specifies the root
  certificate authority MAY be omitted from the chain, under the
  assumption that the remote end must already possess it in order to
  validate it in any case.

In particolare, si noti che la stessa radice autofirmata può essere inclusa o meno. Questa radice non è mai necessaria dal lato client (e non lo è mai stata), ma l'invio è "tradizionale" (una delle miriadi di tradizioni nell'IT, non utile, ma soprattutto innocua).

Il client dovrebbe essere in grado di convalidare la catena di certificati "così com'è" ed è permesso (come in "moralmente giustificato"), secondo lo standard TLS, per rifiutare l'handshake se la catena esatta inviata dal server non può essere convalidato. Tuttavia, il client è anche autorizzato (e incoraggiato) a provare a ricostruire qualche altra catena e a convalidarlo, se ciò che il server inviato non era direttamente utilizzabile. I browser moderni lo fanno; cercheranno di utilizzare certificati CA intermedi localmente noti (ottenuti all'installazione o memorizzati nella cache) e potranno anche scaricare certificati CA aggiuntivi, seguendo l'URL trovato nei certificati stessi ( Authority Information Access estensione). Almeno IE su Windows (recente) lo farà, ma, per evitare una brutta situazione di pollo e uova, seguirà solo http:// URL, non https:// . Questi download extra possono richiedere del tempo e rendere l'handshake meno robusto, in caso di rete instabile o timeout.

Riepilogo: l'invio della radice non è obbligatorio, ma tradizionale (è improbabile che l'overhead della rete di +1 kB per full handshake abbia un impatto significativo o persino rilevabile sulle prestazioni). L'invio della CA intermedia è nominalmente richiesto e, in pratica, consigliato, sebbene i browser / sistemi operativi moderni possano essere ripristinati utilizzando strategie alternative per la creazione di catene di certificati.

    
risposta data 26.07.2013 - 15:50
fonte
1

Solo dai nomi dei file è impossibile stabilire quale sia effettivamente ciascun certificato. Quindi non posso aiutare con quei file specifici. Ma ecco il succo di come funzionano i certificati:

  • Il browser ha un set di certificati attendibili "root" che è configurato per fidarsi. Affinché qualsiasi altro certificato sia considerato affidabile, deve esserci un percorso di firma che porta a uno di questi certificati di origine.

  • Hai un certificato firmato dall'autorità di certificazione. Ha il tuo nome di dominio su di esso.

  • Se il tuo certificato non è stato firmato da uno dei certificati radice attendibili sul tuo browser, anche l'autorità di certificazione ti invierà almeno un certificato intermedio; uno dei quali avrà firmato il tuo certificato, uno che lo ha firmato e così via fino a una radice attendibile.

Quando si invia il proprio certificato al browser come parte della negoziazione SSL, se al browser manca uno dei certificati intermedi nella catena che porta al certificato radice, il certificato non può essere convalidato. Ma se il tuo server web invia anche i certificati intermedi come parte dell'avvio di SSL, il browser può quindi creare il link.

Quindi per rispondere a una parte della tua domanda, i certificati intermedi non devono essere installati sul server se sono già presenti sul computer del cliente. Ma dal momento che non riesci mai a vedere il computer del cliente, è meglio essere dalla parte della sicurezza.

Per quanto riguarda i certificati che ti hanno inviato? Nessuna idea. Uno è ovviamente il tuo certificato. Almeno uno è probabilmente un certificato intermedio. Uno potrebbe in realtà essere la "root" di fiducia che dovrebbe essere già presente sul computer del client per far funzionare l'intero accordo di fiducia.

Per quanto riguarda il motivo per cui ti ho inviato questi certificati; chiediglielo

    
risposta data 26.07.2013 - 07:42
fonte