Eroare de încredere Android IKEv2: trimiteți CA intermediară, nu o rădăcină
Telefonul respinge gateway-ul pentru că lanțul primit se oprește prea devreme. Decideți: trimiteți intermediara, corectați identitatea sau schimbați tipul de cheie.
Telefonul refuză să se conecteze și afișează No trusted RSA public key found for vpn.example.net, în timp ce același certificat al gateway-ului funcționează de pe un laptop în aceeași rețea. Mișcarea tentantă este reemiterea certificatului. Înainte de asta, stabiliți care dintre cele trei defecțiuni o aveți, pentru că doar una dintre ele privește conținutul certificatului. Mesajul acoperă un lanț incomplet, o nepotrivire de identitate și o cheie sau semnătură neacceptată, iar fiecare are o reparație diferită.
Trei defecțiuni în spatele unui mesaj
Android construiește un lanț de la certificatul gateway-ului până la CA selectată în profilul VPN, apoi compară numele serverului cu profilul. Notificarea raportează rezultatul, nu etapa. O defecțiune de încredere înseamnă că lanțul nu a putut fi completat din certificatele livrate în schimb; o defecțiune de identitate înseamnă că lanțul a fost validat, dar numele nu s-a potrivit; o defecțiune de algoritm înseamnă că dispozitivul sau profilul nu acceptă tipul de cheie sau semnătura.
| 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 |
Decideți pe baza dovezilor, nu încercând reparații în ordine. O singură încercare la nivelul de jurnal 2 împotriva daemonului vă spune în ce rând vă aflați și costă mai puțin decât reemiterea unui certificat care nu a fost niciodată greșit.
Decideți mai întâi: a sosit lanțul complet?
strongSwan trimite certificatul configurat pentru acea conexiune, iar certificatele intermediare sunt acreditări separate. Ele trebuie încărcate ca certificate CA înainte ca daemonul să le poată plasa într-un payload, așa că o configurație în care certificatul serverului este semnat de o intermediară, rădăcina este ancora de încredere, iar intermediara există doar în directorul de compilare al CA produce exact această defecțiune: doar frunza pe fir, lanțul se termină devreme pe telefon.
Verificați ce deține daemonul cu swanctl --list-certs într-o instalare swanctl, sau ipsec listcerts cu starterul mai vechi. Intermediara ar trebui să apară ca certificat CA cu rădăcina deasupra. Dacă lipsește, nicio opțiune a clientului nu ajută; dacă este prezentă, treceți la următoarea întrebare.
Apoi verificați dacă ar fi trimisă. Referința swanctl.conf documentează send_cert, al cărui implicit ifasked trimite certificate doar când partenerul a cerut; always trimite întotdeauna. Echivalentul vechi este leftsendcert=always în ipsec.conf. Această setare controlează trimiterea, nu disponibilitatea, deci nu poate compensa o intermediară pe care daemonul nu a încărcat-o niciodată.
Dacă lanțul este scurt, încărcați intermediara acolo unde caută daemonul
Puneți intermediara în directorul CA, nu lângă frunză: /etc/ipsec.d/cacerts pentru o configurație ipsec.conf, /etc/swanctl/x509ca pentru swanctl, sau calea pe care o înlocuiește pachetul dumneavoastră. Reîncărcați configurația și listați din nou certificatele. Unele versiuni trimit și un pachet care conține lanțul în fișierul frunză, dar directorul CA este aranjamentul portabil între versiuni și pachete.
Verificați și din partea clientului. Telefonul vede doar ce a transportat schimbul, așa că jurnalul daemonului la nivelul 2 ar trebui să arate intermediara printre certificatele transmise. Dacă jurnalul o arată și telefonul tot eșuează, sunteți într-un alt rând al tabelului, iar ajustarea în continuare a fișierelor CA nu va schimba rezultatul.
Dacă lanțul este complet, opriți editarea certificatelor
O defecțiune de identitate este o nepotrivire între numele din profilul VPN și numele din certificat. Android compară identitatea serverului pe care ați configurat-o cu certificatul pe care l-a validat, așa că un profil care indică o adresă în timp ce certificatul numește un nume de gazdă, sau un profil care numește un nume de gazdă pe care certificatul nu îl acoperă, eșuează după o validare reușită a lanțului. Corectați partea greșită și mențineți profilul și certificatul aliniate când oricare se schimbă.
O defecțiune de algoritm apare cu un lanț valid și un nume potrivit. Versiunile Android diferă în privința tipurilor de cheie și a schemelor de semnătură acceptate, iar tipul de profil în sine limitează opțiunile. Dacă gateway-ul folosește o combinație mai veche sau neobișnuită, comparați-o cu ce acceptă dispozitivul înainte de a presupune că certificatul este corupt. Jurnalul daemonului va arăta handshake-ul mergând mai departe decât în cazul încrederii, iar acesta este semnalul că lanțul nu mai este problema.
Nu instalați intermediara ca rădăcină de utilizator pe telefon
Instalarea intermediarei lipsă ca certificat de utilizator pe telefon face avertismentul să dispară și schimbă modelul de încredere al telefonului pentru fiecare aplicație care acceptă rădăcini instalate de utilizator. De asemenea, ascunde o eroare de livrare care va lovi următorul client și lasă gateway-ul să trimită un lanț incomplet fiecărui dispozitiv viitor. Reparația durabilă este pe server, o dată, pentru toți clienții.
Păstrați cele trei decizii separate în registrul de modificări: ce certificate au fost transmise, ce identitate a fost comparată și ce algoritm a fost negociat. Un gateway care trimite întotdeauna lanțul complet, un profil care numește corect certificatul și un tip de cheie pe care flota îl acceptă sunt trei fapte mici, și ele sunt întreaga defecțiune.