Ancora imparando le differenze tra i certificati. Qualcuno può spiegare? Internet finora è stato sorprendente non lucido nel descrivere i certificati.
* MODIFICA per chiarire EE
"End Entity" è definito in X.509 (beh, RFC 5280) come:
end entity: user of PKI certificates and/or end user system that is
the subject of a certificate;
ma l'espressione ha davvero senso nel contesto di convalida del percorso : un certificato "EE" viene chiamato così perché quando appare in un percorso certificato, è necessariamente alla fine del percorso . In questo senso, un "certificato EE" è un certificato che non contiene una estensione dei vincoli di base , o che contiene tale estensione con il cA flag uguale a FALSE .
Ora puoi convalidare un certificato CA mettendolo alla fine di un percorso, nel qual caso quel certificato, sebbene appartenga ad un'autorità di certificazione, può temporaneamente essere un "certificato di entità finale", a seconda di come interpreti quell'espressione. La relazione va nella direzione opposta: secondo l' algoritmo di convalida del percorso (in particolare la sezione 6.1.4 , passaggio (k)), affinché un certificato possa apparire in un percorso valido in qualsiasi luogo a parte la fine, DEVE essere un "certificato CA" (che significa qui "un certificato con un'estensione dei vincoli di base con il flag cA impostato su TRUE ).
Questo risponde alla tua domanda: se un certificato non è un "certificato CA" (come in "certificato taggato come" CA "", al contrario di "certificato di proprietà da un'organizzazione che è anche un'autorità di certificazione "), quindi può essere utilizzata solo come" entità finale "all'interno di un percorso di convalida.
(Oppure, detto diversamente: non cercare di leggere troppo in una terminologia mal definita. In pratica, ciò che importa è quali implementazioni fanno , ovvero l'algoritmo di convalida del percorso.)
Do all non-CA certs have to be End Entity certs?
Sì. È una o / o-cosa secondo RFC 5280, sezione 3.2 :
X.509 v3 also includes an extension that identifies the subject of a
certificate as being either a CA or an end entity, reducing the
reliance on out-of-band information demanded in PEM.
This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates.
Inoltre: domanda simile qui: Le organizzazioni che ricevono certificati sono considerate "entità finali" in una PKI?
I certificati X.509 sono documenti progettati per contenere informazioni certificate come una copia esatta e invariata delle informazioni di sicurezza critiche. Il certificatore è solitamente una terza parte fidata. Queste informazioni sono costituite da diversi valori importanti, ma al momento è necessario comprenderne solo alcuni: il nome dell'organizzazione a cui appartiene il certificato, la chiave pubblica di quell'organizzazione, un campo che indica quali azioni è possibile utilizzare per la chiave pubblica, l'identità / identità del firmatario / firmatario e la firma stessa.
La certificazione viene eseguita da qualcuno dell'autorità che firma le informazioni che provengono onestamente dall'organizzazione indicata sul certificato, quindi che lo attesta eseguendo l'hashing dei bit del certificato (utilizzando SHA, MD5 o altro algoritmo hash), quindi crittografando quel valore di hash digest con la chiave privata super-secret dell'autorità di firma. Questo produce la firma. Chiunque abbia la chiave pubblica dell'autorità di firma può utilizzarlo per convalidare il resto del documento non è stato modificato.
Le autorità di firma sono considerate affidabili dai produttori di sistemi operativi e browser per fornire certificati "autofirmati", certificati firmati dall'autorità stessa. Questi certificati hanno il nome dell'autorità di firma, la loro chiave pubblica e un campo che dice che può essere utilizzato solo per convalidare le firme. Questi sono chiamati certificati Root di fiducia e le organizzazioni che li rilasciano sono chiamati Autorità di certificazione (CA).
Quando un'organizzazione desidera consentire agli utenti di crittografare il proprio traffico, crea una richiesta di firma del certificato (CSR). Il CSR ha il loro nome, la sua chiave pubblica e una bandiera che dice che questa chiave pubblica deve essere utilizzata solo per crittografare le chiavi di crittografia. Invia la CSR alla CA, che (a pagamento) convalida proviene da una fonte legittima, quindi firma la richiesta, producendo un certificato.
A volte una CA non usa la sua chiave di root per firmare direttamente ogni certificato. Questo è comune nelle installazioni di livello aziendale. Invece, il certificato radice firma un certificato diverso con il flag impostato su "convalida firme". Questo certificato secondario è un certificato "funzionante" e viene utilizzato per creare migliaia di altri certificati utilizzati nelle operazioni giornaliere (certificati utente di posta elettronica, certificati di server Web server, certificati client, ecc.) Questi sono chiamati certificati subordinati Autorità (CSA). Non è raro che un'organizzazione di grandi dimensioni abbia un CSA dedicato alla firma di certificati di posta elettronica, un diverso certificato di server Web interno di firma CSA e certificati di un computer client con firma diversa. Questa architettura generale è definita Public Key Infrastructure (PKI).
La risposta è No. Abbiamo un'autorità di certificazione intermedia che non è né CA ROOT né End Entity.
Lo scopo di utilizzare una CA intermedia è principalmente per la sicurezza. Generalmente la CA principale viene mantenuta nella stessa posizione per motivi di sicurezza. La CA radice firma la CA intermedia, la CA intermedia firma la End Entity.
Possono esserci più di una CA Intermedia.
CA ROOT | | CA intermedio | | Certificato di entità finale.
Leggi altre domande sui tag certificates certificate-authority