Certificato con caratteri jolly SSL per emettere certificati anther

3

Diciamo che acquisto un certificato SSL * .example.com. Voglio ora generare i certificati secondari e includere il certificato * .example.com in un percorso sicuro:

  1. host1.esempio.com, con un nome alternativo r.example.com
  2. host2.example.com, con un nome alternativo r.example.com
  3. host3.esempio.com, con un nome alternativo r.example.com

Le domande sono:

  1. I certificati sostitutivi verranno riconosciuti dai browser Web e da altri client se viene riconosciuto il certificato * .esempio.com?
  2. Dovrei rigenerare tutti i certificati secondari quando scadrà il certificato principale, o sarei in grado di prolungare * .example.com lasciando intatto il resto, oppure emettere un nuovo * .example.com e firmare i miei certificati secondari con questo?

In realtà sto cercando un modo economico per migrare la mia rete da certificati autofirmati a quelli firmati, ecco perché ogni server dovrebbe avere un certificato diverso e non condiviso. Inoltre, dovrebbe essere anche più semplice in manutenzione se una di quelle chiavi perde.

    
posta czaks 28.04.2014 - 10:53
fonte

2 risposte

2

Sfortunatamente il modello PKI implementato nei browser non impone una restrizione dei domini che è possibile firmare con una CA, quindi qualsiasi CA secondaria può firmare qualsiasi dominio desiderato. Ecco perché nessuna CA fidata nei browser rilascerà più una CA secondaria (almeno ufficialmente, potrebbero ancora rilasciarle per consentire ad alcune agenzie di montare attacchi man-in-the-middle). Quindi non sarai in grado di acquistare una sub-CA che è solo in grado di firmare domini sotto example.com.

Anche se si fosse in grado di acquistare un certificato di questo tipo, l'argomento non ha importanza, ad es. può essere *.example.com o qualsiasi altra cosa. L'oggetto viene utilizzato solo per trovare la CA di emissione facendo corrispondere il nome dell'emittente nel certificato foglia con il nome soggetto delle CA conosciute durante la convalida della catena di fiducia.

Oltre a ciò, un certificato non è firmato con il certificato della CA, ma con la sua chiave privata. Pertanto, se il certificato della CA scade, è possibile emettere un nuovo certificato con la stessa coppia di chiavi pubblica / privata e l'oggetto e non è necessario riemettere tutti i certificati firmati dalla CA. Ma solitamente la validità di una CA è molto più lunga di quella dei certificati emessi dalla CA. Di solito, non rilasci un nuovo certificato CA perché non è più valido, ma perché la chiave privata è stata compromessa o è diventata troppo debole (ad esempio, sostituisce le chiavi a 1024 bit con 2048 bit). In questo caso la chiave pubblica cambia, quindi è necessario firmare di nuovo i certificati emessi dalla CA.

    
risposta data 28.04.2014 - 13:30
fonte
1

Penso che avrai bisogno del tuo modello di CA per i tuoi server, in quanto l'acquisto di un certificato valido per firmare altri certificati non è un'opzione in base a questo .

Supponendo che tu disponga di una rete interna di server che servono dati / servizi su HTTPS. puoi usare openssl per creare una gerarchia di certificati. Al livello più alto sarà un certificato autofirmato che verrà utilizzato per firmare altri certificati per l'utilizzo dei server. fai riferimento a questo per i dettagli. La parte migliore dell'utilizzo di openssl è che richiede zero investimenti per creare un modello CA.

I certificati generati da questo approccio saranno riconosciuti dai browser se il certificato di origine è installato nel trust store. Come hai il pieno controllo del tuo certificato di root puoi dargli la validità desiderata semplificando la manutenzione.

In caso di perdita di una chiave privata. È necessario creare un nuovo certificato di origine e generare nuovi certificati server. Ma con questo approccio non dovrebbe essere un grosso problema.

    
risposta data 28.04.2014 - 11:58
fonte

Leggi altre domande sui tag