Android IKEv2 fertrouwensflater: stjoer de tuskenlizzende CA, gjin woartel
De telefoan wegeret it doarpaad om’t de ûntfongen keatling te betiid einiget. Beslis: stjoer de tuskenlizzende, reparear de identiteit of feroarje it kaai type.
De telefoan wegeret te ferbinen en printsjet No trusted RSA public key found for vpn.example.net, wylst itselde doarpaad-sertifikaat fan in laptop op itselde netwurk wurket. De ferliedlike stap is it sertifikaat opnij útjaan. Foardat jo dat dogge, fêststelje hokker fan de trije fouten jo hawwe, want mar ien giet oer de ynhâld fan it sertifikaat.
Trije fouten efter ien berjocht
Android bout in keatling fan it doarpaad-sertifikaat nei de CA dy’t yn it VPN-profyl keazen is, en ferjout dan de servernamme mei it profyl. De melding rapportearret it resultaat, net de stap. In fertrouwensflater betsjut dat de keatling net foltôge wurde koe mei de sertifikaten út de útwikseling; in identiteitsflater dat de keatling jildich is mar de namme net past; in algoritmeflater dat it apparaat of it profyl it kaai type of de hantekening net akseptearret.
| 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 |
Beslis mei bewiis ynstee fan reparaasjes op folchoarder te besykjen. Ien besykjen op lognivo 2 op de daemon fertelt jo yn hokker rige jo binne, en it kostet minder as it opnij útjaan fan in sertifikaat dat nea ferkeard wie.
Beslis earst: kaam de hiele keatling?
strongSwan stjoert it sertifikaat dat foar dy ferbining ynsteld is, en tuskenlizzende sertifikaten binne aparte bewizen. Se moatte as CA-sertifikaten laden wurde foardat de daemon se yn in lading pleatse kin, dat in opbou wêrby’t it server-sertifikaat troch in tuskenlizzende ûndertekene is, de woartel it fertrouwensanker is en de tuskenlizzende allinnich yn de boumap fan de CA libbet, jout krekt dizze flater: allinnich it blêd op de tried en de keatling einiget betiid op de telefoan.
Kontrolearje wat de daemon hat mei swanctl --list-certs op in swanctl-ynstallaasje, of ipsec listcerts mei de âldere starter. De tuskenlizzende moat as CA-sertifikaat ferskine mei de woartel derboppe. As it mist, helpt gjin inkelde kliïntopsje; as it der is, gean nei de folgjende fraach.
Kontrolearje dan oft it stjoerd wurde soe. De swanctl.conf-referinsje dokumintearret send_cert, wêrfan de standert ifasked sertifikaten allinnich stjoert as de partner frege hat, wylst always altyd stjoert. It âlde ekwivalent is leftsendcert=always yn ipsec.conf. Dy ynstelling regelet it stjoeren, net de beskikberens, dat it kin in tuskenlizzende dy’t de daemon nea laden hat net kompensearje.
Is de keatling koart, laad de tuskenlizzende dêr’t de daemon siket
Set de tuskenlizzende yn de CA-map, net njonken it blêd: /etc/ipsec.d/cacerts foar in opbou mei ipsec.conf, /etc/swanctl/x509ca foar swanctl, of it paad dat jo pakket ferfangt. Laad de konfiguraasje opnij en list de sertifikaten wer. Guon ferzjes stjoere ek in bondel mei de keatling yn it blêd bestân, mar de CA-map is de draachbere regeling tusken ferzjes en pakketten.
Kontrolearje ek fan de kliïntkant. De telefoan sjocht allinnich wat de útwikseling droegen hat, dat de daemonlog op nivo 2 moat de tuskenlizzende tusken de stjoerde sertifikaten sjen litte. As de log it sjen lit en de telefoan dochs mist, binne jo yn in oare rige fan de tabel, en it oanpassen fan CA-bestannen sil it resultaat net feroarje.
Is de keatling folslein, stop dan mei it bewurkjen fan sertifikaten
In identiteitsflater is in misferstân tusken de namme yn it VPN-profyl en de namme yn it sertifikaat. Android ferjout de serveridentiteit dy’t jo ynsteld hawwe mei it sertifikaat dat it falidearre hat, dat in profyl dat nei in adres wiist wylst it sertifikaat in hostnamme neamt, of in profyl mei in hostnamme dy’t it sertifikaat net dekt, mist nei in suksesfolle keatlingfalidaasje. Reparearje de ferkearde kant en hâld profyl en sertifikaat yn oerienstimming.
In algoritmeflater ferskynt mei in jildige keatling en in passende namme. Android-ferzjes ferskille yn hokker kaaitypes en hantekening skema’s se akseptearje, en it profyltype sels beheint de opsjes. As it doarpaad in âldere of ûngewoane kombinaasje brûkt, fergelykje dy dan mei wat it apparaat stipet foardat jo oannimme dat it sertifikaat skansearre is. De log sil sjen litte dat de hânskodding fierder giet as yn it fertrouwensgefal, wat it sinjaal is dat de keatling net langer it probleem is.
Ynstallearje de tuskenlizzende net as brûkerwoartel op de telefoan
It ynstallearjen fan de ûntbrekkende tuskenlizzende as brûkerssertifikaat op de telefoan lit de warskôging ferdwine en feroaret it fertrouwensmodel fan de telefoan foar elke app dy’t brûker-ynstalleare woartels akseptearret. It ferberget ek in leveringsflater dy’t de folgjende kliïnt rekket, en lit it doarpaad in ûnfolsleine keatling nei elk takomstich apparaat stjoere. De bliuwende reparaasje is op de server, ien kear, foar alle kliïnten.
Hâld de trije besluten apart yn it feroaringslog: hokker sertifikaten oerdroegen binne, hokker identiteit ferjûn is en hokker algoritme ûnderhannele is. In doarpaad dat altyd syn folsleine keatling stjoert, in profyl dat it sertifikaat korrekt neamt en in kaai type dat de float stipet binne trije lytse feiten, en se binne de hiele flater.