Errore di attendibilità IKEv2 su Android: invia la CA intermedia, non una radice
Il telefono rifiuta il gateway perché la catena ricevuta finisce presto. Decidi: invia l’intermedia, correggi l’identità o cambia il tipo di chiave.
Il telefono rifiuta di connettersi e stampa No trusted RSA public key found for vpn.example.net, mentre lo stesso certificato del gateway funziona da un portatile sulla stessa rete. La tentazione è riemettere il certificato. Prima, stabilisci quale dei tre guasti hai, perché solo uno riguarda il contenuto del certificato.
Tre guasti dietro un solo messaggio
Android costruisce una catena dal certificato del gateway alla CA scelta nel profilo VPN, poi confronta il nome del server con il profilo. La notifica riporta il risultato, non la fase. Un guasto di attendibilità significa che la catena non è stata completata con i certificati consegnati nello scambio; un guasto di identità, che la catena è valida ma il nome non corrisponde; un guasto di algoritmo, che il dispositivo o il profilo non accetta il tipo di chiave o la firma.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
Decidi sulle prove invece di provare riparazioni in ordine. Un tentativo a livello di log 2 sul demone ti dice in quale riga sei, e costa meno di riemettere un certificato che non è mai stato sbagliato.
Decidi prima: è arrivata l’intera catena?
strongSwan invia il certificato configurato per quella connessione, e i certificati intermedi sono credenziali separate. Devono essere caricati come certificati CA prima che il demone possa metterli in un carico, quindi una disposizione in cui il certificato del server è firmato da un’intermedia, la radice è l’ancora di fiducia e l’intermedia vive solo nella directory di build della CA produce esattamente questo guasto: solo la foglia sul filo e la catena che finisce presto sul telefono.
Controlla cosa tiene il demone con swanctl --list-certs in un deployment swanctl, o ipsec listcerts con lo starter più vecchio. L’intermedia deve apparire come certificato CA con la radice sopra. Se manca, nessuna opzione del client aiuta; se c’è, passa alla domanda successiva.
Poi controlla se verrebbe inviata. Il riferimento di swanctl.conf documenta send_cert, il cui valore predefinito ifasked invia certificati solo quando il peer lo ha chiesto, mentre always invia sempre. L’equivalente storico è leftsendcert=always in ipsec.conf. L’impostazione governa l’invio, non la disponibilità, quindi non compensa un’intermedia che il demone non ha mai caricato.
Se la catena è corta, carica l’intermedia dove il demone cerca
Metti l’intermedia nella directory CA, non accanto alla foglia: /etc/ipsec.d/cacerts per una disposizione con ipsec.conf, /etc/swanctl/x509ca per swanctl, o il percorso che il tuo pacchetto sostituisce. Ricarica la configurazione e rielenca i certificati. Alcune versioni inviano anche un bundle con la catena dentro il file della foglia, ma la directory CA è la disposizione portabile tra versioni e pacchetti.
Verifica anche dal lato client. Il telefono vede solo ciò che lo scambio ha portato, quindi il log del demone a livello 2 deve mostrare l’intermedia tra i certificati inviati. Se il log lo mostra e il telefono continua a fallire, sei in un’altra riga della tabella, e ritoccare i file CA non cambierà l’esito.
Se la catena è completa, smetti di modificare i certificati
Un guasto di identità è un disaccordo tra il nome nel profilo VPN e il nome nel certificato. Android confronta l’identità del server che hai configurato con il certificato che ha validato, quindi un profilo che punta a un indirizzo mentre il certificato nomina un host, o un profilo che nomina un host che il certificato non copre, fallisce dopo una corretta validazione della catena. Correggi il lato sbagliato e mantieni profilo e certificato allineati.
Un guasto di algoritmo appare con catena valida e nome corrispondente. Le versioni di Android differiscono nei tipi di chiave e negli schemi di firma accettati, e il tipo di profilo stesso limita le opzioni. Se il gateway usa una combinazione vecchia o inusuale, confrontala con ciò che il dispositivo supporta prima di supporre che il certificato sia danneggiato. Il log mostrerà che la stretta di mano procede più avanti rispetto al caso di attendibilità, il segnale che la catena non è più il problema.
Non installare l’intermedia come radice utente sul telefono
Installare l’intermedia mancante come certificato utente sul telefono fa sparire l’avviso e cambia il modello di fiducia del telefono per ogni app che accetta radici installate dall’utente. Nasconde anche un difetto di consegna che colpirà il cliente successivo e lascia il gateway a inviare una catena incompleta a ogni dispositivo futuro. La riparazione duratura è sul server, una volta, per tutti i client.
Tieni le tre decisioni separate nel registro delle modifiche: quali certificati sono stati trasmessi, quale identità è stata confrontata e quale algoritmo è stato negoziato. Un gateway che invia sempre la catena completa, un profilo che nomina correttamente il certificato e un tipo di chiave supportato dalla flotta sono tre piccoli fatti, e sono tutto questo guasto.