Più certificati server SSL

4

Sono una specie di nuovo su SSL. Durante una connessione SSL, vedo che il server sta inviando più certificati.

Qualcuno può aiutarmi a capire perché il server sta inviando più certificati? E come posso fare lo stesso con il server openssl, apache o gnutls?

Grazie in anticipo.

** Aggiornamento ** Grazie per tutte le risposte. Ho anche capito come farlo in apache2

Ho aggiunto la configurazione SSL nel ports.conf /etc/apache2/ports.conf

<IfModule mod_ssl.c>
    Listen 443
    <VirtualHost *:443>
      ServerName www.example.com
      SSLEngine on
      SSLCertificateFile /root/25apr-rootcert
      SSLCertificateKeyFile /root/25apr-rootkey
      SSLCertificateChainFile /root/25apr-chain.pem
    </VirtualHost>
</IfModule>

È necessario aggiungere il crt concatenato come SSLCertificateChainFile /root/25apr-chain.pem

A scopo di test, ho semplicemente concatenato / root / 25apr-rootcert in /root/25apr-chain.pem poche volte.

Spero che questo aiuti!

    
posta ahamed101 24.06.2014 - 19:34
fonte

3 risposte

4

Per tutto SSL, leggere lo standard non è una cattiva idea; è molto leggibile (per uno standard). Per prima cosa, puoi sfogliare questa risposta , come una sorta di guida alla lettura.

Per la tua domanda specifica, ciò che il server invia come "certificato" è descritto in sezione 7.4.2 :

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.

Il punto è che un certificato , per poter essere utilizzato da chiunque lo riceve (qui, il client), deve prima essere validato , un processo mediante il quale il il cliente mette il certificato alla fine di una catena. La catena inizia con un "trust anchor" (una "root CA" la cui chiave pubblica è nota a priori ), e ogni elemento chain è un certificato CA intermedio, emesso (firmato) dal precedente certificato in la catena. La catena termina con il certificato che deve essere convalidato. La convalida comporta la verifica di un sacco di cose (descritte in un altro standard che è sostanzialmente meno leggibile per gli esseri umani sani di mente ), in particolare tutte le firme crittografiche (ogni certificato è firmato dalla sua CA di emissione, la firma è verificata per quanto riguarda la chiave pubblica contenuta nel certificato che precede immediatamente nella catena).

Poiché una catena deve essere costruita, il server deve inviare al client una catena completa, in modo che il client possa lavorarci direttamente. In caso contrario, il client dovrebbe individuare e ottenere i certificati CA pertinenti intermedi, un processo che può essere piuttosto complesso e soggetto a errori.

Punti degni di nota:

  • La catena inviata dal server è nell'ordine inverso: essa inizia con il certificato dell'entità finale (cioè il certificato del server correttamente detto), seguito dal certificato per la CA che ha emesso il certificato del server, quindi la CA che ha emesso il certificato della CA e così via.

  • La catena può contenere o meno il certificato CA radice stesso. L'invio non è necessario poiché il client lo ha già (la convalida è in realtà una delega di fiducia, deve iniziare da qualche parte). L'invio della CA radice è comunque consentito dallo standard e alcuni server lo fanno (soprattutto per tradizione).

  • Il client è libero di utilizzare la catena inviata dal server o di costruirne un'altra. Per un determinato certificato, possono essere possibili diverse catene (dipende dalla struttura PKI). La maggior parte dei browser Web tenterà prima la catena come ricevuta dal server e, in caso di errore, riproverà con la creazione di una catena personalizzata. Alcuni client più limitati, in particolare i sistemi embedded, useranno solo la catena del server. Quindi il server dovrebbe inviare una catena corretta senza collegamento mancante (altrimenti, solo i client "intelligenti" saranno in grado di convalidare il certificato del server e quindi collegarsi con successo).

risposta data 24.06.2014 - 21:52
fonte
1

In SSL (e TLS) quando un server Web abilitato HTTPS viene contattato per la prima volta da un client (in genere un browser) risponde al client con un messaggio "Server Hello", seguito rapidamente da un messaggio "Certificato". Entrambi questi messaggi vengono visualizzati, piuttosto facilmente, nella traccia di rete che hai incluso.

Il messaggio "Server Hello" non è particolarmente rilevante per la tua domanda qui, in quanto implementa il meccanismo con cui il server comunica al client quale versione del protocollo SSL o TLS ha deciso di utilizzare, e anche quale cifra suite che ha deciso di usare.

Il messaggio "Certificato" del server è piuttosto interessante. Questo messaggio è costituito da una sequenza di uno o più certificati. La traccia di rete mostra che il tuo server particolare ha incluso tre certificati nel suo messaggio "Certificati".

Il primo certificato nella sequenza è sempre il certificato del server. Se apri quel primo certificato nel tuo record di traccia di rete (cioè il certificato che è lungo 1406 byte) mostrerà quasi sicuramente il nome DNS del server, come valore dell'attributo CN (o Common Name). C'è anche una pila di altre cose nel primo certificato (ad esempio le date e le ore di inizio e scadenza del certificato del server e la sua chiave pubblica). Un altro elemento pertinente alla tua domanda qui è il campo Emittente del certificato del server, che contiene l'identità del certificato CA (Certificate Authority) che ha emesso il certificato del server.

È qui che entrano in gioco le catene di certificati (come descritto nel link fornito in precedenza da Steffen Ulrich). Il certificato di un server Web viene quasi invariabilmente emesso da un certificato di livello superiore (un certificato CA) e tale certificato CA di livello superiore viene spesso emesso da un certificato CA di livello ancora superiore. E così via, ma non all'infinito! Deve esserci una fine alla catena di certificati CA di livello superiore da qualche parte, e finisce sempre, in un cosiddetto certificato CA "root". Un certificato CA root è non emesso da qualsiasi certificato CA di livello superiore, quindi il buck si ferma definitivamente lì.

Il lungo e breve è che la traccia di rete mostra che il server ha inviato al client una catena di tre certificati. Il primo certificato sarà il certificato del server, come già menzionato. Il secondo certificato sarà il certificato CA che ha emesso il certificato del server. E il terzo certificato sarà il certificato CA root, che ha emesso il secondo certificato.

Quindi il messaggio "Certificato" del tuo server contiene la catena completa, dal certificato del tuo server, fino al certificato CA intermedio e infine di nuovo al certificato CA root.

Quando questo piccolo lotto arriva al cliente, il cliente ha ora tutto ciò che serve per controllare e dimostrare l'identità del tuo server. Tra l'altro, è molto importante che il client sia in grado di scoprire se il certificato della CA root è uno che si fida di esso. Se il certificato CA radice che (in ultima analisi) ha emesso il certificato del server non è effettivamente attendibile dal client, allora si lamenterà (in genere dicendo all'utente che il certificato del server non è attendibile e quindi chiedendo all'utente se desidera andare avanti e continuare a comunicare con il server comunque.

È essenziale che il server debba sempre inviare al client il proprio certificato (in modo che il client possa verificare che l'identità del server sia come previsto). Quindi ci sarà sempre almeno un certificato nel messaggio "Certificato" del server. Tuttavia, non è assolutamente essenziale che il server invii anche gli altri certificati CA (di livello superiore) (poiché in linea di principio il client potrebbe ricorrere ad altri mezzi per scoprire il resto della catena di certificati). Ma sicuramente aiuta il cliente se il server li invia tutti. Che (finalmente) spiega perché stai vedendo il tuo server inviare più certificati.

Nella parte finale della tua domanda (i server OpenSSL, Apache e GnuTLS) penso che probabilmente dipende esattamente da come li configuri. Sfortunatamente non sono abbastanza familiare con loro per sapere come lo faresti, in ogni caso. Ma raccomanderei che, ove possibile, dovresti mirare a quei server a restituire sempre la catena di certificati completa al client, più o meno allo stesso modo mostrato nella traccia della tua rete.

C'è molto di più che si può dire su SSL e TLS - ma questo non è certo il posto giusto! Se vuoi saperne di più da un vero esperto, posso consigliare il libro di Eric Rescorla (sebbene ora piuttosto datato) "SSL e TLS - Progettare e costruire sistemi sicuri", ISBN 0-201-61598-3, pubblicato nel 2000. Speriamo, comunque, avrai comunque un po 'più di trazione sulla tua domanda.

    
risposta data 24.06.2014 - 21:51
fonte
0

È probabile che il server invii una serie di certificati che comprendono la "catena di certificati". Generalmente, le CA non rilasciano certificati firmati dalla propria chiave radice, ma da una chiave intermedia e pertanto è necessario includere tale certificato nella catena per ottenere il collegamento tra la chiave e la radice.

Quindi, i segni di chiave radice intermedi, i segni intermedi la tua chiave, ecc. Poiché il browser / OS ha solo le chiavi di root, devi inviare loro tutto per effettuare la connessione, e in alcuni casi, ci possono essere più CA intermedie certificati.

    
risposta data 24.06.2014 - 21:03
fonte

Leggi altre domande sui tag