strongSwan send_cert: quando viene inviato il certificato IKE

I gateway registrano errori di autenticazione legati ai certificati, e il primo impulso è aggiungere un’altra CA al ricevente. Ciò presuppone che il certificato sia arrivato e sia stato rifiutato. L’altra possibilità è che non sia mai stato inviato, e questo lo decide la politica di connessione del mittente. Stabilite quale dei due casi si è verificato prima di toccare la fiducia.

Cosa controlla davvero send_cert

L’autenticazione con certificato richiede che il certificato di entità finale del peer raggiunga l’altro lato tramite lo scambio IKE o un approvvigionamento precedente. In swanctl l’impostazione di connessione send_cert stabilisce se questo endpoint include il proprio carico di certificato: mai, sempre oppure ifasked. Il valore predefinito ifasked lo invia in risposta a una richiesta di certificato del peer. Chiedere un certificato è un’impostazione separata, perché chiedere all’altra parte il suo certificato non è lo stesso che offrire il proprio.

Le distribuzioni più vecchie di ipsec.conf usavano leftsendcert e rightsendcert, e quei nomi corrispondono ai ruoli locale e remoto, non direttamente a swanctl.

Leggete un tentativo prima di modificare la connessione

Diagnosticate da un singolo tentativo controllato, non dall’impressione generale che siano coinvolti dei certificati. Sia la politica sia l’associazione attiva sono ispezionabili.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

L’elenco delle connessioni mostra il valore configurato di send_cert, e l’elenco delle SA mostra quali connessioni sono realmente salite. Il log aggiunge dettagli sulla negoziazione: se è arrivata una richiesta di certificato e se è uscito un carico di certificato. Un errore di autenticazione generico non identifica un problema di consegna, quindi cercate lo scambio specifico prima di concludere qualcosa. Annotate il timestamp del tentativo perché la finestra del log copra l’intero handshake.

La fiducia del ricevente è una decisione separata

Consegna e fiducia sono proprietà diverse, e sistemarne una non sistema l’altra. Un ricevente deve possedere l’anchor di fiducia previsto, ricevere una catena utilizzabile e corrispondere all’identità attesa del peer. Un certificato di entità finale che arriva senza il suo intermedio fallisce comunque un controllo rigoroso della catena. Al contrario, installare una CA non obbliga affatto un peer a inviare il proprio certificato.

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

L’ispezione mostra quale emittente ha firmato il certificato e quando scade, e a questo deve corrispondere l’anchor del ricevente. Fidatevi della CA emittente posseduta dalla distribuzione, non di ogni intermedio della catena, perché promuovere ogni intermedio a radice allarga la fiducia ben oltre un singolo peer. Mantenete attiva la verifica dell’identità, poiché una connessione che riesce solo con la validazione disattivata non è una correzione. Dove la catena è incompleta, riparate l’approvvigionamento invece della politica del mittente.

Cambiate il mittente solo con prove

Quando il log mostra che il certificato non è mai stato inviato e che il ricevente lo ha effettivamente richiesto, impostare send_cert su always è un cambiamento giustificato per quella connessione. Applicatelo nella configurazione di swanctl, ricaricate le connessioni e stabilite una nuova sessione invece di riutilizzare la SA esistente. Confermate che il carico del certificato ora compare e che il ricevente lo accetta rispetto all’anchor previsto. Se nulla cambia, il guasto era comunque sul lato della fiducia e l’impostazione del mittente non era la causa.

Scrivete lo scambio osservato, l’anchor e la verifica risultante nel registro delle modifiche. Una correzione del certificato che non si possa descrivere in questi termini è una coincidenza.