Certificato SSTP non corrispondente: il nome che il tuo server deve presentare

SSTP client SSTP accetta il server solo dopo che la validazione TLS è riuscita, e quel controllo confronta un nome, una catena e uno scopo. Il nome viene dal profilo di connessione, non dall’indirizzo che per caso riesci a pingare. Quando uno dei tre non corrisponde, il client segnala un problema di certificato e non arriva mai alla richiesta di accesso.

Il nome nel profilo decide cosa viene controllato

SSTP esegue TLS su TCP 443, quindi il client si comporta come qualsiasi altro client TLS: prende il nome host dal profilo, richiede quel nome e confronta il certificato con esso. Se digiti un indirizzo IP nel profilo, il confronto diventa un confronto di indirizzi IP, che la maggior parte dei certificati server non soddisfa.

Per questo un test nel browser può riuscire mentre la VPN fallisce, perché il browser ha usato un nome diverso da quello del profilo. La stessa divisione appare quando il DNS split-horizon risolve il nome host della VPN in un indirizzo interno mentre il browser ne ha raggiunto uno pubblico. Allinea prima il profilo al nome host documentato, poi confronta i certificati. Qualunque altra cosa tu cambi prima è un’ipotesi.

Cosa deve portare il certificato del server

I client moderni confrontano con l’estensione dei nomi alternativi del soggetto, quindi il nome host deve comparire lì come voce DNS. Un nome comune da solo non basta per le pile di validazione attuali, e un carattere jolly copre un’etichetta e non qualsiasi sottodominio tu inventi. Tre certificati illustrano il limite: il nome giusto con lo scopo sbagliato convalida l’identità e poi fallisce il controllo dello scopo, il nome e lo scopo giusti con un intermedio mancante falliscono la catena, e un nome che compare solo nel nome comune fallisce prima che uno degli altri due conti.

Il certificato ha bisogno anche dello scopo autenticazione del server, il valore di utilizzo esteso della chiave nominato in la specifica SSTP di Microsoft, cioè serverAuth con identificatore di oggetto 1.3.6.1.5.5.7.3.1. L’utilizzo della chiave e una catena valida completano l’insieme. Un certificato presente sul server, rilasciato per il nome giusto ma solo per l’autenticazione del client, fallisce comunque.

Controlla catena e orologio prima delle credenziali

I guasti di tempo e di fiducia producono lo stesso risultato visibile di una mancata corrispondenza del nome, ed entrambi costano meno da diagnosticare di un problema di password. Controlla l’orologio del server e quello del client, poi leggi la catena come la vede il client:

# from the client, or any host that runs openssl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -dates -ext subjectAltName
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_return_error </dev/null
# on the Windows server that holds the SSTP listener
w32tm /query /status

Il primo comando stampa il nome, la finestra di validità e i nomi alternativi con cui il client confronterà. Il secondo segnala gli errori di verifica con la catena così come presentata, ed è lì che compare un intermedio mancante. Su Windows l’interrogazione del servizio di ora ti dice se l’orologio viene corretto o è semplicemente andato alla deriva.

Una CA interna aggiunge una condizione: il client deve fidarsi di quella CA. Installa la radice dell’organizzazione tramite il suo canale di distribuzione approvato, non da una pagina che offre un certificato sostitutivo, perché quella decisione è tutto il modello di fiducia in miniatura.

La validazione del server e l’autenticazione dell’utente sono fasi sequenziali con guasti diversi. Un errore di certificato significa che il client non si è mai fidato del server, mentre una password rifiutata significa che se n’è fidato e che le credenziali erano errate. Disattivare la validazione del certificato per raggiungere la richiesta della password elimina la garanzia invece di ripararla. Per dimostrare che il resto del percorso funziona, prova lo stesso nome host e la stessa porta da un client che si fida già della catena, e lascia in pace il profilo distribuito.

Correggi il nome o il certificato, poi riprova

Tre condizioni decidono la riparazione. Se il nome del profilo è sbagliato, correggi il profilo o aggiungi il nome mancante al certificato. Se la catena è incompleta, installa l’intermedio sul server. Se lo scopo è sbagliato, riemetti invece di rabberciare intorno.

Dopo la modifica, riconnettiti con il client supportato e conferma che appare la richiesta di accesso e poi che il tunnel sale. Annota nel ticket il nome host usato, l’emittente e la data di scadenza. È quel registro che rende il prossimo rinnovo un’attività pianificata invece di un’altra interruzione, e mostra anche alla persona successiva quale delle tre condizioni era davvero rotta.