SAN del certificato IKEv2: perché il controllo dell’identità fallisce

Il certificato si concatena a una CA affidabile, le date sono corrette e il peer rifiuta comunque di completare la fase 1 con un errore di identità. Raggiungibilità e firma valida sono solo metà di ciò che controlla un client IKEv2. L’altra metà è se l’identità attesa compare nel certificato nel campo giusto, e quell’aspettativa è impostata dal profilo, non dal nome file del certificato.

Il sintomo ha sempre la stessa forma

Un profilo di connessione viene cambiato da un nome host a un indirizzo IP, o rinnovato da un certificato che portava un nome DNS a uno che porta solo indirizzi, eil tunnel smette di negoziare. Nulla è cambiato nel percorso di rete. Il client raggiunge il peer, riceve un certificato e rifiuta l’identità del peer perché l’identificatore che gli è stato detto di attendersi non è rappresentato in un campo che accetta. I rinnovi sono il trigger abituale, poiché il certificato sostitutivo proviene spesso da un modello diverso da quello che sostituisce.

Entrambe le parti registrano poi qualcosa di inutile, ed è per questo che il guasto viene di solito segnalato come problema di certificato. Il log del client può nominare l’identità desiderata, e quel nome è l’indizio che cercate, non la data di scadenza.

Abbinate il tipo di identificatore, non solo il valore

Un SAN dNSName e un SAN iPAddress sono campi diversi con regole di corrispondenza diverse, quindi un certificato che porta 203.0.113.10 come stringa DNS non soddisfa un client che attende un’identità IP. I validatori moderni ignorano in gran parte il nome comune, quindi l’etichetta amichevole nei dettagli del certificato non prova nulla su cosa corrisponderà. Se durante la risoluzione dei problemi un nome host è stato sostituito da un indirizzo, presupponete che l’identità attesa si sia spostata con esso finché non avete verificato. Confrontate la stringa nel profilo con la stringa nel SAN carattere per carattere, perché un punto finale o uno spazio vagante bastano.

I caratteri jolly sono solo una comodità DNS e seguono le proprie regole di corrispondenza, che è un altro motivo per cui un profilo basato su IP non dovrebbe mai affidarsi ad essi.

Trovate dove ogni client memorizza l’aspettativa

In strongSwan, il valore confrontato con il certificato proviene dall’impostazione dell’identità del peer: rightid nella configurazione classica, o il id di una sezione di connessione remota in swanctl. La sua documentazione sull’interoperabilità Apple IKEv2 è utile qui perché esplicita le convenzioni di identità usate da un client guidato dal profilo, e quelle convenzioni spiegano una classe di disallineamenti che sembra casuale sul filo.

I profili di configurazione Apple portano un campo identificatore remoto, e il valore lì è ciò che il client controlla anziché l’indirizzo del server nelle impostazioni di connessione. I client Windows e degli appliance hanno ciascuno il proprio campo con il proprio valore predefinito, e il valore predefinito segue spesso l’indirizzo digitato. Dove due campi non concordano, vince quello che il client legge davvero, ed è raramente quello che avete modificato.

Riparate il profilo o il certificato, deliberatamente

Ispezionate il certificato del peer con strumenti approvati ed elencate le voci SAN con i loro tipi prima di cambiare qualsiasi cosa. Quell’ispezione non richiede chiavi private né caricamenti, e risolve la questione in pochi secondi. Se la distribuzione intende una sola identità DNS, il certificato deve portarla come voce dNSName, e se la distribuzione intende un indirizzo, il certificato ha bisogno di una voce iPAddress per esattamente quell’indirizzo.

Quando il certificato è sbagliato, chiedete all’operatore uno corretto con l’identificatore atteso specifico. Quando il profilo è sbagliato, correggete il profilo e lasciate stare il certificato. Disattivare la validazione dell’identità fa sparire l’errore e rimuove il controllo che il tunnel stia parlando con il peer previsto.

Documentate l’identità attesa per ogni piattaforma client, perché un valore che un client ricava automaticamente può dover essere esplicito su un altro.

Date alla richiesta di rinnovo quattro fatti

Annotate l’identificatore atteso e il suo tipo, le voci SAN che il certificato attuale ha davvero, il client e la versione che eseguono il controllo, e il testo esatto dell’errore. Una richiesta di rinnovo costruita da queste quattro righe ottiene il certificato giusto al primo colpo, invece di un altro con lo stesso familiare nome file.