Perché non ti fidi di un certificato direttamente?

0

Se si desidera configurare un servizio firmato utilizzando un sistema di autorità di certificazione (SSL / TLS, alcune configurazioni di IKE, ecc.), se si desidera utilizzare un certificato autofirmato (ad es. per il test), in genere è necessario creare un certificato, un certificato CA, firmare il primo utilizzando il secondo e quindi installare la chiave pubblica del certificato CA come affidabile nelle configurazioni client.

Penserei che sarebbe altrettanto sicuro affidarsi direttamente al certificato non CA. Perché la configurazione più complicata? Questa è una conseguenza del fatto che questi sistemi sono progettati per funzionare con una gerarchia di CA, o c'è qualche motivo più specifico?

    
posta joshlf 09.12.2015 - 18:26
fonte

2 risposte

0

Penso che tu abbia risposto alla tua stessa domanda:

Is this a consequence of the fact that these systems are designed to work with a CA hierarchy?

Yup. Nel modello di certificato X509, i certificati di root (o "certificati di firma CA") hanno il vincolo di base CA:True che consente di firmare altri certificati. Inserendo il CERT di root nel proprio archivio di fiducia, si ha automaticamente fiducia in ogni certificato che firmano (e certificati firmati da subCAs firmati da tale certificato CA radice) quindi con un solo certificato nel proprio archivio di fiducia, si confida automaticamente con un'intera gerarchia di CA e certificati - anche quelli che non hai mai visto prima. Altrimenti dovresti aggiungere manualmente ogni singolo certificato non-CA al tuo trust store e diventerebbe molto rapidamente un hog di memoria e spazio su disco, e il problema di come fidarti di un nuovo certificato che non hai mai visto prima diventa < em> molto più complicato.

Come sottolineato da @JonathanGray nei commenti, un certificato autofirmato potrebbe essere quello che stai cercando poiché è contemporaneamente una CA e di un utente finale. Anche se non risolve il tuo problema originale di dover eseguire più passaggi di configurazione.

Non sono a conoscenza di alcun motivo tecnico per cui verrebbe impedito di inserire un cert non root nel tuo trust store, tranne per il fatto che dovrebbe essere programmato per cercarlo. Dal momento che il caso d'uso ha senso solo negli ambienti di sviluppo, suppongo che la maggior parte dei produttori di software non si preoccuperebbe di dedicare del tempo a scrivere quel codice.

Più in dettaglio, il passaggio del certificato di affidabilità della convalida del certificato funziona come segue: supponiamo che tu stia convalidando un certificato del server SSL, guarda la CA che ha firmato questo certificato e vedi se sono nel tuo trust store, altrimenti, guarda alla CA che ha firmato e vedere se loro si trovano nel tuo negozio di fiducia, e così via finché non ne trovi uno, o in cima alla catena. La maggior parte del software probabilmente non si preoccuperebbe di cercare il cert dell'utente finale nel trust store solo perché stai sprecando il runtime di una ricerca costosa su qualcosa che non dovrebbe mai accadere in un sistema di produzione.

    
risposta data 09.12.2015 - 18:45
fonte
1

Dipende ciò che stai testando. Secondo wikipedia :

a CA is a trusted third party—trusted both by the subject (owner) of the certificate and by the party relying upon the certificate.

Quindi, se vuoi testare lo scenario del mondo reale in cui ci sarà una CA, allora sarebbe meglio creare una "CA di prova" e firmare il tuo "certificato di prova" autofirmato. Ciò testerebbe l'infrastruttura di fiducia della CA.

Anche la fiducia nel certificato autofirmato funzionerà, ma non sta simulando lo scenario del mondo reale. Se il tuo ambito di test non richiede di testare la catena di affidabilità della CA, puoi fidarti solo del certificato autofirmato.

    
risposta data 09.12.2015 - 18:48
fonte

Leggi altre domande sui tag