Quando si creano certificati autofirmati, si suppone che CA.crt sia installato nella macchina client?

Sto cercando di lavorare con OpenSSL C API, sono ancora relativamente nuovo a tutto questo e trovo molte informazioni contrastanti là fuori, quindi penso sia saggio chiedere idee / opinioni / chiarimenti.

Ad ogni modo, il programma client richiede che venga caricato un certificato o una directory che contenga un “TrustStore”. Questo è solo un altro significato per il il certificato CA del server stesso nel caso in cui sto creando i miei certificati SSL per detto server?

E se è così, la CA intermedia funzionerà per questo scopo in sostituzione della CA radice?

Penso di essere sulla strada giusta. Tuttavia, volevo solo qualche chiarimento in modo da evitare di commettere qualche errore stupido, in quanto ho sentito alcune informazioni contrastanti in merito. Alcuni dicono che il client ha bisogno della CA root stessa; altre fonti dicono che installano solo CA intermedie per motivi di sicurezza, il che sembra logico.

In genere sono un po confuso su come funziona la catena di fiducia riguardo a una connessione client. In realtà ho sempre e solo bisogno di generare un CSR e installare un certificato sul server web, quindi il lato client è un po nuovo per me.

Questa domanda è stata inizialmente posta qui su Stack Overflow, mi è stato suggerito di chiedere alla community di info-sec.

Commenti

  • Penso che tu stia usando la frase sbagliata: un certificato autofirmato è un certificato in cui il certificato dellemittente è il certificato stesso. Probabilmente indica invece un certificato firmato dalla tua CA. In questo caso: la CA radice viene solitamente inserita nel truststore e il certificato intermedio firmato dalla CA radice e il certificato foglia firmato dal certificato intermedio vengono inviati durante lhandshake TLS .
  • Possibile duplicato di Come funziona SSL / TLS PKI?

Risposta

tl; dr Se il certificato contiene qualche variazione di CA:TRUE, ha senso distribuirlo, se non lo fa, non cè alcun vantaggio nel distribuirlo.

La catena di fiducia stessa può essere spiegata in termini di struttura del certificato.

Se partiamo dal tuo server “s cert (cioè il certificato che useresti tipicamente per apache):

  • il tuo certificato del server è generato da unautorità di certificazione, in base a un CSR fornito. Tale CSR contiene la tua chiave pubblica e alcune altre informazioni che la CA potrebbe o non potrebbe essere interessata a utilizzare.
  • la CA riceve la tua CSR e (generalmente) creerà un certificato firmato utilizzando una CA intermedia. Il tuo certificato avrà due chiavi pubbliche: una per loggetto (che è la chiave pubblica estratta dalla tua CSR) e una per la parte emittente, che è il certificato intermedio della CA.
  • la CA ” Il certificato intermedio è esso stesso un certificato firmato (con alcune opzioni speciali), dove la chiave del soggetto sarà la chiave pubblica della CA intermedia (che è la stessa chiave pubblica che si trova nella chiave pubblica dellemittente del certificato del server). la chiave di firma (o emissione) sarà il certificato radice della CA (in alternativa, sarà un altro intermedio).
  • Il certificato radice della CA è (generalmente) un certificato autofirmato. In pratica, ciò significa che le chiavi dellemittente e delloggetto sono la stessa chiave pubblica.

Puoi vederlo controllando i certificati in natura, ad esempio:

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

La catena di fiducia che questo crea può essere riassunta come (sto iniziando dal ” bottom “- il certificato Equifax):

  • la CA radice (Equifax) delega le attività quotidiane a una CA intermedia (GeoTrust) e firma un certificato che rappresenta questo fatto (ovvero limpostazione della CA: TRUE, KeyUsage: keyCertSign). In altre parole, la CA radice “si fida” dellintermedio per emettere certificati per suo conto (si spera dopo aver completato una serie di passaggi di convalida obbligatori).
  • in questa catena, lintermedio (Geotrust) ha ulteriormente delegato a una CA di Google (CN = Google Internet Authority G2).
  • il delegato (noto anche come CA intermedio di Google) firma quindi una CSR, che effettivamente è un documento in cui si afferma che per un dato insieme di nomi (t a CN, e possibilmente Subject Alternative Names), una coppia di chiavi pubblica / privata è valida / attendibile (la fiducia qui deriva dal fatto che hanno convalidato la richiesta di parlare per un determinato nome – in questo caso, la CA di Google ha emesso un certificato per * .google.com).

Nota che le CA (root) sono generalmente autofirmate: una CA è generalmente considerata attendibile perché si attiene a una serie di processi e procedure che si sentono per garantire che non rilasci certificati alle persone chi non dovrebbe averli. È per questo che non posso uscire e procurarmi un certificato che dice che sono google.Questa è quindi una sorta di convenzione (sebbene supportata da meccanismi formali), e se avvii la tua CA, distribuendo i suoi certificati radice (e intermedi) si ottiene esattamente la stessa cosa della distribuzione dei certificati di altre CA: emette certificati da quella CA essere accettata come valida (cioè affidabile) dal sistema.

In termini più pratici, il truststore (per openSSL) è praticamente un mucchio di file con una specifica convenzione di denominazione. Vedi https://www.openssl.org/docs/faq.html#USER5 :

Quando un certificato è verificato la sua CA radice deve essere “considerata attendibile” da OpenSSL questo in genere significa che il certificato CA deve essere posizionato in una directory o in un file e il programma pertinente deve essere configurato per leggerlo

Quella directory è / etc / ssl / certs (ce ne sono altre, come / etc / pki su RH-likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 fornisce unulteriore panoramica di come si aggiunge un certificato al negozio, poiché https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

La versione breve è quella update-ca-certificates automatizza il processo ed è lo strumento comunemente usato.

La versione leggermente più lunga è che i certificati devono essere archiviati tramite hash (ad esempio in file denominati basati sulloutput di openssl x509 -hash -in cert.pem), in modo che openSSL possa validare in modo efficiente le catene.

Vedi https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html per uno sfondo aggiuntivo.

ha aggiornato per rispondere alle domande nei commenti:

Il certificato del server , in questa discussione, viene definito attendibile o meno in base alla sua catena di fiducia. Se pensi a come funziona (ad es.) curl https://google.com, è un po più facile da capire:

  • curl apre una connessione TLS a google, che restituisce un certificato.
  • curl esamina quel certificato “utente finale”, ovvero il certificato del server, e cerca specificamente lemittente.
  • se lemittente è “noto” in il trust store, il resto della catena di trust viene convalidato (cioè il certificato dellemittente del certificato del server viene controllato, e se esso ha un emittente diverso da se stesso, lemittente viene controllato, ecc.). Solo se lintera catena di attendibilità può essere convalidata, il certificato è considerato valido.

Tuttavia, sarebbe assolutamente impraticabile distribuire catene di attendibilità se fosse necessario includere i certificati dellutente finale. Non ho numeri su quanti siti web ci sono, ma basandomi sul fatto che Alexa fornisce un milione superiore, presumeresti che sia più di 1 milione.

Che è un po il punto di una catena di fiducia: generalmente hai bisogno di avere i certificati dellemittente in giro, ma non hai bisogno dei certificati finali per essere distribuiti, perché ti dicono chi è lemittente.

E puoi verificare che non lo sono ” mentire, perché puoi controllare la chiave pubblica dellemittente (e la catena di fiducia che la stabilisce è la chiave corretta) e convalidare se il certificato dellutente finale (cioè il server) è stato realmente firmato dalla controparte privata dellemittente “s chiave pubblica.

Quindi no, non dovresti distribuire i certificati dellutente finale, ma solo la catena di fiducia o, in termini più semplici: distribuire tutti i certificati che generi dove i BasicConstraints (legittimamente) dicono almeno qualcosa CA: TRUE. Non distribuire nulla che non soddisfi tale condizione, perché è uno spreco di tempo e spazio su disco – tutto ciò che non dice CA: TRUE può essere convalidato rispetto a qualcosa che lo fa.

Commenti

  • Ciò significa in ogni caso che il client ha bisogno di accedere al certificato CA root, o solo al certificato CA di cui il server certificato è stato firmato da? O mi manca ancora completamente un punto?
  • Per verificare il certificato del server, i client dovrebbero avere accesso alla catena di fiducia completa per quel certificato. In caso contrario, il client considererà il certificato non valido o chiederà allutente di accettarlo. Nel tuo caso, sembra piuttosto probabile che tu non stia impostando un punto di distribuzione per i tuoi CA / CRL, quindi il modo più semplice è assicurarsi che i tuoi certificati siano in / etc / ssl / certs sulle macchine client. tl; dr: un certificato è un uso limitato per stabilire la fiducia se puoi ' t stabilire la sua catena di fiducia. Ed è necessario convalidare lintera catena per stabilirlo. Quindi rendi disponibile lintera catena di fiducia
  • Ciò significa che se cè una CA radice, una CA intermedia e il certificato firmato sul server, tutti e tre questi certificati devono essere disponibili per il client allinterno del /etc/ssl/certs directory? Dato che contengono tutte le chiavi pubbliche?

Risposta

Un certificato autofirmato è esattamente questo: è firmato il mio stesso (è la sua ancora di fiducia).

Pertanto, per essere considerato attendibile, deve essere inserito manualmente ed esplicitamente nellelenco degli ancoraggi attendibili dellapplicazione. Il modo in cui ciò viene fatto dipende dal sistema operativo e dallapplicazione.

Ad esempio, se si utilizza larchiviazione interna dei certificati di Windows, è necessario posizionare il certificato autofirmato nellarchivio “autorità di certificazione radice attendibile” o il certificato non verrà accettato. OpenSSL utilizza un diverso sistema di archiviazione specifico dellapplicazione: dovrai installare il certificato anche come CA attendibile, ma il modo in cui farlo dipende in larga misura dallapplicazione e dal sistema operativo che stai utilizzando (vedi questo articolo per alcune istruzioni generiche).

Commenti

  • Quindi questo significa che " Trust Store " è uguale a quello installato in apache, ad esempio? Quello ' è la parte che crea più confusione, io ' ma GNU/Linux utente, la directory a cui dovevo collegarmi nellapplicazione client, era /etc/ssl/certs. Tuttavia non sono riuscito a trovare una spiegazione chiara di quale sia esattamente il processo da quel punto di vista. Almeno tu capisci la mia domanda qui, il punto principale è scrivere client e fare in modo che consideri attendibile il server a cui si connette.
  • Cosa i ' sto cercando di fare esattamente è creare una CA, e immagino che il certificato sia firmato dalla CA (intermedio), quindi in tal caso, significa che la CA è lancora di fiducia, quindi il Ca intermedio dovrebbe essere installato nella directory dei certificati attendibili? Grazie per aver risposto.
  • La tua domanda è quindi più generale. ' ho proposto di chiuderlo con un link alla risposta che cerchi.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *