Error de confiança d’IKEv2 a Android: envieu el CA intermedi, no una arrel
El telèfon rebutja la passarel·la perquè la cadena rebuda s’atura massa aviat. Decidiu: envieu l’intermedi, corregiu la identitat o canvieu el tipus de clau.
El telèfon es nega a connectar-se i imprimeix No trusted RSA public key found for vpn.example.net, mentre que el mateix certificat de la passarel·la funciona des d’un portàtil a la mateixa xarxa. La temptació és reemetre el certificat. Abans, determineu quina de les tres fallades teniu, perquè només una tracta del contingut del certificat.
Tres fallades darrere d’un missatge
Android construeix una cadena des del certificat de la passarel·la fins al CA seleccionat al perfil VPN, i després compara el nom del servidor amb el perfil. La notificació informa del resultat, no de l’etapa. Una fallada de confiança vol dir que la cadena no s’ha pogut completar amb els certificats lliurats a l’intercanvi; una fallada d’identitat vol dir que la cadena és vàlida però el nom no coincideix; una fallada d’algorisme vol dir que el dispositiu o el perfil no accepta el tipus de clau o la signatura.
| 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 |
Decidiu amb proves en lloc de provar reparacions en ordre. Un intent al nivell 2 del registre del dimoni us diu en quina fila sou i costa menys que reemetre un certificat que mai no era incorrecte.
Decidiu primer: ha arribat la cadena sencera?
strongSwan envia el certificat preparat per a aquesta connexió, i els certificats intermedis són credencials separades. Cal carregar-los com a certificats CA abans que el dimoni els pugui posar a la càrrega, així que un disseny on el certificat del servidor està signat per un intermedi, l’arrel és l’àncora de confiança i l’intermedi només viu al directori de compilació del CA produeix exactament aquesta fallada: només el full al fil i la cadena que acaba aviat al telèfon.
Comproveu què té el dimoni amb swanctl --list-certs en un desplegament swanctl, o ipsec listcerts amb l’antic starter. L’intermedi ha d’aparèixer com a certificat CA amb l’arrel a sobre. Si falta, cap opció del client no ajudarà; si hi és, passeu a la pregunta següent.
Després comproveu si s’enviaria. La referència de swanctl.conf documenta send_cert, el valor per defecte del qual ifasked envia certificats només quan el parell ho ha demanat, mentre que always envia sempre. L’equivalent antic és leftsendcert=always a ipsec.conf. Aquest paràmetre controla l’enviament, no la disponibilitat, així que no pot compensar un intermedi que el dimoni mai no ha carregat.
Si la cadena és curta, carregueu l’intermedi on mira el dimoni
Poseu l’intermedi al directori CA, no al costat del full: /etc/ipsec.d/cacerts per a un disseny amb ipsec.conf, /etc/swanctl/x509ca per a swanctl, o el camí que substitueix el vostre paquet. Recarregueu la configuració i torneu a llistar els certificats. Algunes versions també envien un paquet que conté la cadena dins del fitxer del full, però el directori CA és la disposició portàtil entre versions i paquets.
Verifiqueu-ho també des del costat del client. El telèfon només veu el que ha portat l’intercanvi, així que el registre del dimoni al nivell 2 ha de mostrar l’intermedi entre els certificats enviats. Si el registre el mostra i el telèfon encara falla, sou en una altra fila de la taula i ajustar fitxers CA no canviarà el resultat.
Si la cadena és completa, deixeu d’editar certificats
Una fallada d’identitat és un desacord entre el nom del perfil VPN i el nom del certificat. Android compara la identitat del servidor que heu configurat amb el certificat que ha validat, així que un perfil que apunta a una adreça mentre el certificat anomena un nom d’amfitrió, o un perfil que anomena un nom d’amfitrió que el certificat no cobreix, falla després d’una validació correcta de la cadena. Corregiu el costat equivocat i manteniu perfil i certificat alineats quan un dels dos canvia.
Una fallada d’algorisme apareix amb una cadena vàlida i un nom coincident. Les versions d’Android difereixen en quins tipus de clau i esquemes de signatura accepten, i el mateix tipus de perfil limita les opcions. Si la passarel·la utilitza una combinació antiga o inusual, compareu-la amb el que admet el dispositiu abans de suposar que el certificat està fet malbé. El registre del dimoni mostrarà que l’encaixada de mans avança més que en el cas de confiança, que és el senyal que la cadena ja no és el problema.
No instal·leu l’intermedi com a arrel d’usuari al telèfon
Instal·lar l’intermedi que falta com a certificat d’usuari al telèfon fa desaparèixer l’avís i canvia el model de confiança del telèfon per a cada aplicació que accepta arrels instal·lades per l’usuari. També amaga un error de lliurament que afectarà el client següent i deixa la passarel·la enviant una cadena incompleta a cada dispositiu futur. La reparació duradora és al servidor, una vegada, per a tots els clients.
Manteniu les tres decisions separades al registre de canvis: quins certificats s’han transmès, quina identitat s’ha comparat i quin algorisme s’ha negociat. Una passarel·la que sempre envia la cadena completa, un perfil que anomena correctament el certificat i un tipus de clau que la flota admet són tres fets petits, i són tota aquesta fallada.