Telefonen nekter å koble til og skriver ut No trusted RSA public key found for vpn.example.net, mens det samme gateway-sertifikatet fungerer fra en bærbar PC på samme nettverk. Det fristende trekket er å utstede sertifikatet på nytt. Før du gjør det, finn ut hvilken av tre feil du har, fordi bare én av dem handler om sertifikatets innhold. Meldingen dekker en ufullstendig kjede, en identitetsavvik og en nøkkel eller signatur som ikke støttes, og hver har en forskjellig reparasjon.

Tre feil bak én melding

Android bygger en kjede fra gateway-sertifikatet til CA-en som er valgt i VPN-profilen, og sammenligner deretter servernavnet med profilen. Varselet rapporterer resultatet, ikke trinnet. En tillitsfeil betyr at kjeden ikke kunne fullføres fra sertifikatene som ble levert i utvekslingen; en identitetsfeil betyr at kjeden ble validert, men navnet samsvarte ikke; en algoritmefeil betyr at enheten eller profilen ikke godtar nøkkeltypen eller signaturen.

What you seeWhat it points toFirst move
Chain stops after the leaf in the daemon logintermediate not loaded or not sentload the intermediate as CA material
Chain validates, name differs from the profileidentity mismatchfix the profile name or the certificate SAN
Chain validates, handshake still failskey or signature not acceptedcompare key type against the device

Bestem ut fra bevis i stedet for å prøve reparasjoner i rekkefølge. Ett forsøk på loggnivå 2 mot daemonen forteller deg hvilken rad du er i, og det koster mindre enn å utstede et sertifikat som aldri var feil på nytt.

Bestem først: kom hele kjeden frem?

strongSwan sender sertifikatet som er konfigurert for den tilkoblingen, og mellomliggende sertifikater er separate legitimasjoner. De må lastes inn som CA-sertifikater før daemonen kan plassere dem i en nyttelast, så et oppsett der server sertifikatet er signert av en mellomliggende, roten er tillitsankeret, og den mellomliggende bare ligger i CA-ens byggekatalog, gir nøyaktig denne feilen: bare bladet på tråden, kjeden som slutter tidlig på telefonen.

Sjekk hva daemonen har med swanctl --list-certs på en swanctl-installasjon, eller ipsec listcerts med den eldre starteren. Den mellomliggende skal vises som et CA-sertifikat med roten over seg. Hvis den mangler, hjelper ingen klientinnstilling; hvis den finnes, gå videre til neste spørsmål.

Sjekk deretter om den ville bli sendt. swanctl.conf-referansen dokumenterer send_cert, der standarden ifasked bare sender sertifikater når motparten har spurt; always sender uansett. Den eldre ekvivalenten er leftsendcert=always i ipsec.conf. Den innstillingen styrer sending, ikke tilgjengelighet, så den kan ikke kompensere for en mellomliggende som daemonen aldri lastet.

Hvis kjeden er kort, last den mellomliggende der daemonen leter

Legg den mellomliggende i CA-katalogen i stedet for ved siden av bladet: /etc/ipsec.d/cacerts for et ipsec.conf-oppsett, /etc/swanctl/x509ca for swanctl, eller banen pakken din erstatter. Last konfigurasjonen på nytt og list sertifikatene igjen. Noen versjoner sender også en bunt som inneholder kjeden i bladfilen, men CA-katalogen er den flyttbare ordningen på tvers av versjoner og pakker.

Verifiser også fra klientsiden. Telefonen ser bare det utvekslingen brakte med seg, så daemonloggen på nivå 2 skal vise den mellomliggende blant sertifikatene som sendes. Hvis loggen viser den og telefonen fortsatt feiler, er du i en annen rad i tabellen, og å fortsette å justere CA-filer vil ikke endre resultatet.

Hvis kjeden er komplett, slutt å redigere sertifikater

En identitetsfeil er et avvik mellom navnet i VPN-profilen og navnet i sertifikatet. Android sammenligner serveridentiteten du konfigurerte, med sertifikatet den validerte, så en profil som peker på en adresse mens sertifikatet navngir et vertsnavn, eller en profil som navngir et vertsnavn sertifikatet ikke dekker, feiler etter vellykket kjedevidering. Rett den siden som er feil, og hold profilen og sertifikatet i samsvar når en av dem endres.

En algoritmefeil vises med en gyldig kjede og et samsvarende navn. Android-versjoner er forskjellige i hvilke nøkkeltyper og signaturskjemaer de godtar, og profiltypen selv begrenser valgene. Hvis gatewayen bruker en eldre eller uvanlig kombinasjon, sammenlign den med det enheten støtter før du antar at sertifikatet er ødelagt. Daemonloggen vil vise at håndtrykket går lenger enn i tillitstilfellet, og det er signalet om at kjeden ikke lenger er problemet.

Ikke installer den mellomliggende som brukerrot på telefonen

Å installere den manglende mellomliggende som et brukersertifikat på telefonen fjerner advarselen og endrer telefonens tillitsmodell for hver app som godtar brukerinstallerte røtter. Det skjuler også en leveringsfeil som vil ramme neste klient, og lar gatewayen sende en ufullstendig kjede til hver fremtidige enhet. Den varige reparasjonen er på serveren, én gang, for alle klienter.

Hold de tre beslutningene atskilt i endringsloggen: hvilke sertifikater som ble sendt, hvilken identitet som ble sammenlignet, og hvilken algoritme som ble forhandlet. En gateway som alltid sender hele kjeden sin, en profil som navngir sertifikatet riktig, og en nøkkeltype flåten støtter er tre små fakta, og de er hele denne feilen.

Relaterte artikler