IKEv2-tillidsfejl på Android: send den mellemliggende CA, ikke en rod
Telefonen afviser gatewayen, fordi den modtagne kæde stopper tidligt. Beslut: send den mellemliggende, ret identiteten, eller skift nøgletypen.
Telefonen nægter at forbinde og udskriver No trusted RSA public key found for vpn.example.net, mens det samme gateway-certifikat virker fra en bærbar computer på samme netværk. Den fristende handling er at udstede certifikatet igen. Før du gør det, find ud af, hvilken af tre fejl du har, for kun én af dem handler om certifikatets indhold.
Tre fejl bag én meddelelse
Android bygger en kæde fra gateway-certifikatet til den CA, der er valgt i VPN-profilen, og sammenligner derefter servernavnet med profilen. Meddelelsen rapporterer resultatet, ikke trinnet. En tillidsfejl betyder, at kæden ikke kunne fuldføres med de certifikater, der blev leveret i udvekslingen; en identitetsfejl betyder, at kæden er gyldig, men navnet passede ikke; en algoritmefejl betyder, at enheden eller profilen ikke accepterer nøgletypen eller signaturen.
| 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 |
Beslut ud fra beviser i stedet for at prøve reparationer i rækkefølge. Ét forsøg på logniveau 2 på dæmonen fortæller dig, hvilken række du er i, og det koster mindre end at udstede et certifikat igen, som aldrig var forkert.
Beslut først: kom hele kæden?
strongSwan sender det certifikat, der er konfigureret til den forbindelse, og mellemliggende certifikater er separate legitimationsoplysninger. De skal indlæses som CA-certifikater, før dæmonen kan sætte dem i en nyttelast, så et layout, hvor servercertifikatet er signeret af en mellemliggende, roden er tillidsankeret, og den mellemliggende kun ligger i CA’ens build-mappe, giver præcis denne fejl: kun bladet på ledningen, og kæden slutter tidligt på telefonen.
Kontroller, hvad dæmonen har, med swanctl --list-certs på en swanctl-udrulning eller ipsec listcerts med den ældre starter. Den mellemliggende bør fremstå som et CA-certifikat med roden over sig. Hvis den mangler, hjælper ingen klientindstilling; hvis den findes, gå videre til næste spørgsmål.
Kontroller derefter, om den ville blive sendt. swanctl.conf-referencen dokumenterer send_cert, hvis standard ifasked kun sender certifikater, når modparten har spurgt, mens always altid sender. Den gamle ækvivalent er leftsendcert=always i ipsec.conf. Indstillingen styrer afsendelse, ikke tilgængelighed, så den kan ikke opveje en mellemliggende, som dæmonen aldrig har indlæst.
Er kæden kort, så indlæs den mellemliggende, hvor dæmonen leder
Læg den mellemliggende i CA-mappen, ikke ved siden af bladet: /etc/ipsec.d/cacerts til et layout med ipsec.conf, /etc/swanctl/x509ca til swanctl, eller den sti din pakke erstatter. Genindlæs konfigurationen, og vis certifikaterne igen. Nogle versioner sender også en pakke med kæden inde i bladfilen, men CA-mappen er den portable ordning på tværs af versioner og pakker.
Kontroller også fra klientsiden. Telefonen ser kun det, udvekslingen bar, så dæmonens log på niveau 2 bør vise den mellemliggende blandt de sendte certifikater. Viser loggen den, og fejler telefonen stadig, er du i en anden række i tabellen, og justering af CA-filer ændrer ikke resultatet.
Er kæden komplet, så stop med at redigere certifikater
En identitetsfejl er uoverensstemmelse mellem navnet i VPN-profilen og navnet i certifikatet. Android sammenligner den serveridentitet, du konfigurerede, med det certifikat, den validerede, så en profil, der peger på en adresse, mens certifikatet angiver et værtsnavn, eller en profil med et værtsnavn, certifikatet ikke dækker, fejler efter en vellykket kædevalidering. Ret den forkerte side, og hold profil og certifikat i overensstemmelse, når en af dem ændres.
En algoritmefejl vises med en gyldig kæde og et matchende navn. Android-versioner er forskellige med hensyn til, hvilke nøgletyper og signaturskemaer de accepterer, og selve profiltypen begrænser indstillingerne. Bruger gatewayen en ældre eller usædvanlig kombination, så sammenlign den med det, enheden understøtter, før du antager, at certifikatet er beskadiget. Dæmonens log vil vise, at håndtrykket går længere end i tillids-tilfældet, hvilket er signalet om, at kæden ikke længere er problemet.
Installer ikke den mellemliggende som brugerrod på telefonen
At installere den manglende mellemliggende som brugercertifikat på telefonen fjerner advarslen og ændrer telefonens tillidsmodel for enhver app, der accepterer brugerinstallerede rødder. Det skjuler også en leveringsfejl, der vil ramme den næste klient, og lader gatewayen sende en ufuldstændig kæde til enhver fremtidig enhed. Den holdbare reparation er på serveren, én gang, for alle klienter.
Hold de tre beslutninger adskilt i ændringsloggen: hvilke certifikater blev sendt, hvilken identitet blev sammenlignet, og hvilken algoritme blev forhandlet. En gateway, der altid sender sin fulde kæde, en profil, der navngiver certifikatet korrekt, og en nøgletype, flåden understøtter, er tre små fakta, og de er hele denne fejl.