Motivo del nome del soggetto in un certificato X.509

La tua domanda non sembra essere il motivo per il Nome soggetto, che è quello di identificare l'argomento, ma piuttosto se funziona.

Gutmann scrive in modo colorato e approfondito su cose che in realtà non contano il più delle volte, anche se quando lo fanno è molto utile conoscerle. Sì, lo schema di denominazione X.500 specificato per essere utilizzato nei certificati X.509 in generale è un mostro. (I disegni del comitato sono tradizionalmente raffigurati come cammelli, anche se in questo caso il polpo sembra appropriato.)

Tuttavia, i certificati SSL / TLS e in particolare i certificati web server - che è l'unico tipo che la maggior parte delle persone incontra e l'unico caso specifico nella tua domanda - evitano il problema usando veramente solo l'attributo CommonName in Subject (name) per contenere un nome di dominio (DNS) "fully-qualified" noto anche come FQDN, o possibilmente (ma raramente) un indirizzo IP; o al giorno d'oggi solitamente l'estensione SubjectAlternativeName per contenere FQDN (s) ed eventualmente indirizzo / i IP. Anche se nel funzionamento reale (soprattutto nella sua attuale scala mondiale) il DNS non è perfetto, la maggior parte delle persone può capirlo abbastanza facilmente, e certamente il domainname in http:// o https:// URL è abbastanza facile da vedere.

Una CA legittima dovrebbe rilasciare un certificato per un determinato nome di dominio solo al "proprietario" di quel dominio, anche se esattamente ciò che conta come proprietà varia leggermente. È possibile visitare ciascun sito della CA e esaminare le regole e i processi di applicazione / convalida o consultare CA / Forum del browser in Requisiti di base che imposta il ( minimo) per le CA da includere nei truststor della maggior parte dei browser e dei sistemi operativi (almeno sui dispositivi consumer), e quindi su quelli che la maggior parte degli utenti si fida.

Quindi, se le CA fanno il loro lavoro e l'attaccante M non può ingannare o costringere una CA di fiducia a emettere erroneamente una cert per il dominio D - cosa che è accaduta in un piccolo numero di casi, ma non così tanti da essere un grosso problema - M non può impersonare il sito web del dominio D. Anche se ti dà il DNS falso (o il routing IP, un'altra possibilità) non può presentare e dimostrare il possesso del chiave per un certificato valido per D e l'handshake SSL / TLS non riesce.

A meno che tu, o il fornitore del tuo browser o sistema operativo o dispositivo per tuo conto, non ti fidi di una CA che emette certificati falsi, per una serie di motivi. Ad esempio, è possibile trovare probabilmente una dozzina di Q & A e altri siti stack sul fiasco Lenovo Superfish dello scorso anno: hanno aggiunto il software a un numero elevato di PC Windows che utilizzavano la propria CA per MitM le connessioni HTTPS per lo scopo dichiarato di fornire pubblicità più pertinente - ma hanno esposto la chiave privata (fissa) di CA e poi chiunque altro potrebbe MitM voi. Hanno dovuto pubblicare strumenti per rimuovere il software incriminato e CA cert, e per catturare quelli che sono sfuggiti al browser e ai produttori di sistemi operativi hanno anche inserito nella lista nera il loro certificato.

Una delle ragioni che mi interessa è che due entità (Alice e Bob) possono avere certs da una CA di cui mi fido, ma ciò non significa che mi fido di Alice nello stesso modo in cui faccio Bob. Ciò è rilevante quando si pensa ai server, ma è più chiaro quando lo si guarda nel contesto dei certificati client. Il certificato viene utilizzato per autenticare il client e possiamo farlo perché ci fidiamo della CA. Ma per sapere quali diritti (se ci sono) che il cliente ha in un dato contesto, ho bisogno di sapere chi sono, non solo dove hanno firmato il loro certificato. Semplicemente conoscere la CA non è abbastanza per questo. È vero che se non hai il controllo sul modo in cui i DN sono assegnati, non puoi davvero contare su di essi, quindi è importante capire quale livello di identificazione hai realmente bisogno e se il certificato ti dà quello attendibile.

"Digital certificates map public keys to entities"

Questo vale solo per i certificati di convalida dell'organizzazione (OV) e di convalida estesa (EV). Il certificato di Domain Validation (DV) mappa solo le chiavi pubbliche sul "controller" del nome di dominio, ma non fornisce alcuna indicazione sull'identità del "controller". I processi di convalida dei certificati OV ed EV, d'altro canto, sono progettati per collegare una chiave pubblica con un nome di dominio e un'identità aziendale / organizzativa registrata.

Le autorità di certificazione pubbliche sono autorizzate a inserire informazioni convalidate nell'oggetto / DN del certificato. In tutti i principali browser Web, gli utenti esperti possono visualizzare tutti questi dettagli del certificato facendo clic sul pulsante del lucchetto nella barra degli indirizzi .

Questo è il motivo per cui il certificato DV contiene solo il nome del dominio, poiché questa è l'unica informazione che la CA ha convalidato. Un certificato OV ed EV contiene il nome legale dell'azienda, la giurisdizione legale dell'azienda e di solito il numero di registrazione unico dell'azienda in un database aziendale governativo (o altri database aziendali qualificati). Questo numero di registrazione può essere utilizzato dagli utenti esperti per cercare l'attività nei database pertinenti.

A volte il nome legale di un'azienda non è necessariamente uguale al nome che il pubblico conosce come business, e questo è il motivo per cui alcuni siti hanno nomi strani nel loro certificato. In questo caso, l'azienda potrebbe essere in grado di avere un nome DBA (fare business as) anche allegato al certificato. La CA deve anche essere in grado di convalidare questo nome alternativo prima di metterlo nel certificato.

Il grosso problema con DN è che c'è poca standardizzazione su cosa mettere lì. Ciò significa che diverse CA mettono cose leggermente diverse nel DN. Mentre questo è OK quando il DN viene letto e verificato da umani, la mancanza di standard rende difficile per il programma automatico utilizzare il DN per capire a quale organizzazione si riferisce.