Nomi alternativi del soggetto: come viene identificato un server VPN
Un certificato considerato affidabile può comunque essere sbagliato per il nome host della tua VPN. Il SAN deve contenere la forma di identità che il client verifica, come nome DNS o indirizzo IP.
Il tuo client rifiuta un certificato la cui catena si valida correttamente, e l’errore dice che il nome non corrisponde. Quel messaggio non riguarda chi ha firmato il certificato. Riguarda l’estensione dei nomi alternativi del soggetto, che contiene le identità che il certificato può rappresentare, e se l’identità che hai configurato compare lì nella forma giusta. La fiducia risponde a chi l’ha firmato, mentre il controllo del nome risponde a quale host appartiene.
Che cosa confronta davvero il client
Il client trasforma la tua configurazione in un’identità di riferimento: un nome host, un indirizzo o un identificatore specifico del protocollo. Poi cerca quell’identità nel certificato, applicando le regole di corrispondenza del protocollo in uso. Contano solo le voci dello stesso tipo, quindi una voce DNS non può soddisfare un indirizzo, e il confronto avviene sia che qualcuno guardi il certificato sia che non lo faccia.
Quando l’identità di riferimento manca da quell’estensione, il controllo fallisce anche se il vecchio nome comune corrisponde. Un certificato può essere emesso legittimamente per un’azienda e restare quello sbagliato per vpn.example.com se il nome non è mai stato incluso. Il fallimento è una mancata corrispondenza del nome, anche se il certificato è autentico.
I nomi DNS e gli indirizzi IP sono voci separate
Un profilo che punta a 203.0.113.10 mentre il certificato elenca solo vpn.example.com viene rifiutato, perché i pacchetti arrivano ma l’identità non corrisponde. I nomi DNS e gli indirizzi letterali sono memorizzati come tipi di voce diversi, e uno non sostituisce mai l’altro. Per questo un servizio può essere raggiungibile per indirizzo e restare inutilizzabile tramite un profilo che usa quell’indirizzo.
Anche i caratteri jolly seguono le proprie regole: un jolly copre una sola etichetta, non ogni nome sotto un dominio. Il confronto DNS non distingue maiuscole e minuscole, mentre altri tipi di identificatore sì, quindi un valore che sembra identico sullo schermo può fallire un confronto rigoroso. Controlla le regole di corrispondenza del tipo di identità in uso invece di confrontare le stringhe a occhio. Aggiungere un nome all’estensione è una decisione di emissione, non qualcosa che un’impostazione del client possa fornire.
Ispeziona il certificato che la connessione ha davvero usato
Leggi il materiale presentato dall’endpoint attivo, non un file copiato da una pagina di amministrazione. Un bilanciatore di carico o un’istanza sostitutiva può presentare qualcosa di diverso dal certificato caricato mesi fa, e quella differenza è invisibile in una console.
openssl s_client -connect vpn.example.com:443 -showcerts </dev/null | openssl x509 -noout -text
Il blocco dei nomi alternativi del soggetto, la catena dell’emittente e il periodo di validità appartengono alla stessa lettura, perché una mancata corrispondenza del nome e una scadenza producono errori diversi. Confronta ogni nome di quel blocco con l’identità configurata nel profilo, carattere per carattere, e annota di che tipo è. Ripetere il comando sulla forma a indirizzo dell’endpoint mostra se il certificato copre entrambe le identità o solo una. Una visualizzazione amichevole del soggetto in una console di gestione non è un risultato di validazione e non dice nulla su quali nomi contenga l’estensione.
Il nome comune non è la fonte moderna della verità
I browser e la maggior parte delle librerie TLS ora ignorano il nome comune per la corrispondenza dei nomi host e consultano l’estensione. Alcuni client VPN confrontano ancora prima il nome comune o vi ricorrono quando l’estensione è assente, e così un certificato può passare in un browser e fallire in un client. Lo stesso controllo del nome può passare su una piattaforma e fallire su un’altra senza che il certificato cambi affatto.
Scopri quale campo legge il tuo client prima di decidere che il certificato è sbagliato. Due client sullo stesso endpoint possono essere in disaccordo, e il disaccordo è informazione sul client, non sul certificato.
Ripara l’emissione o il profilo, non il controllo
Quando un profilo è stato costruito attorno a un alias, o ripuntalo al nome host documentato oppure riemetti il certificato per l’alias e distribuiscilo in una finestra pianificata. Mettere a tacere l’avviso non è una terza opzione, perché il controllo è l’unico passaggio che lega un certificato firmato a questo host specifico. Rimuoverlo significa che qualsiasi certificato della stessa autorità può sostituire il server che volevi raggiungere.
Il rinnovo dovrebbe preservare i nomi e lo scopo previsti invece di limitarsi a spostare avanti la data di scadenza. Un rinnovo che perde un nome è una nuova interruzione programmata per il prossimo riavvio, e di solito arriva senza avviso perché il vecchio certificato era ancora valido quando è stata fatta la modifica.
Registra l’identità attesa, i nomi presentati e la catena che li ha firmati. Quel registro trasforma il rinnovo successivo in un confronto invece che in un’indagine. La definizione dell’estensione è nella RFC 5280 se devi verificare un’emissione specifica.