Telefonen nekter å koble seg til og skriver No trusted RSA public key found for vpn.example.net, mens samme gateway-sertifikat virker fra en laptop på samme nett. Det fristende grepet er å utstede sertifikatet på nytt. Før det: finn ut hvilken av tre feil du står i, for bare én av dem gjelder innholdet i sertifikatet. Meldingen rommer en ufullstendig kjede, et identitetsavvik og en ikke-støttet nøkkel eller signatur, og hver krever ulik reparasjon.

Tre feil bak samme melding

Android bygger kjeden fra gateway-sertifikatet til CA-en som er valgt i VPN-profilen, og sjekker så servernavnet mot profilen. Varselet sier hva som skjedde, ikke hvor det stoppet. Tillitsfeil betyr at kjeden ikke lot seg fullføre med sertifikatene som ble sendt i utvekslingen; identitetsfeil betyr at kjeden ble validert, men navnet ikke passet; 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

Avgjør med bevis fremfor å prøve reparasjoner etter tur. Én kjøring på loggnivå 2 mot daemonen viser hvilken rad du er i, og det koster mindre enn å utstede på nytt et sertifikat som aldri var galt.

Avgjør først: kom hele kjeden frem?

strongSwan sender sertifikatet som er satt opp for den tilkoblingen, og mellomliggende sertifikater er egne legitimasjoner. De må lastes som CA-sertifikater før daemonen kan legge dem i en payload, så en konfigurasjon der serversertifikatet er signert av en mellomliggende, roten er tillitsanker, og den mellomliggende bare finnes i CA-ens byggemappe, gir nettopp denne feilen: bare bladet på linjen, kjeden som tar slutt tidlig på telefonen.

Se hva daemonen holder med swanctl --list-certs på en swanctl-installasjon, eller ipsec listcerts med den gamle starteren. Den mellomliggende skal dukke opp som et CA-sertifikat med roten over. Mangler den, hjelper ingen klientinnstilling; finnes den, gå til neste spørsmål.

Sjekk så om den ville bli sendt. swanctl.conf-referansen beskriver send_cert, der standardverdien ifasked bare sender sertifikater når motparten har bedt om det; always sender uansett. Den gamle tilsvarende innstillingen er leftsendcert=always i ipsec.conf. Innstillingen styrer utsending, ikke tilgjengelighet, og kan derfor ikke veie opp for en mellomliggende som daemonen aldri lastet.

Er kjeden kort, last den mellomliggende der daemonen leter

Legg den mellomliggende i CA-mappen istedenfor ved siden av bladet: /etc/ipsec.d/cacerts for ipsec.conf, /etc/swanctl/x509ca for swanctl, eller stien pakken din bruker. Last konfigurasjonen på nytt og list sertifikatene igjen. Noen versjoner sender også en bunt med kjeden inne i bladfilen, men CA-mappen er den flyttbare løsningen på tvers av versjoner og pakker.

Kontroller også fra klientsiden. Telefonen ser bare det utvekslingen bar med seg, så daemonloggen på nivå 2 skal vise den mellomliggende blant sertifikatene som sendes. Viser loggen den og telefonen likevel feiler, sitter du i en annen rad i tabellen, og videre justering av CA-filer endrer ikke utfallet.

Er kjeden komplett, slutt å redigere sertifikater

Identitetsfeil er avvik mellom navnet i VPN-profilen og navnet i sertifikatet. Android sammenligner serveridentiteten du satte opp, med sertifikatet den validerte, så en profil som peker på en adresse mens sertifikatet angir et vertsnavn, eller en profil som angir et vertsnavn sertifikatet ikke dekker, feiler etter vellykket kjedevalidering. Rett den siden som er gal, og hold profil og sertifikat i takt når en av dem endres.

Algoritmefeil dukker opp med gyldig kjede og passende navn. Android-versjoner er ulike i hvilke nøkkeltyper og signaturskjemaer de godtar, og profiltypen selv begrenser valgene. Bruker gatewayen en eldre eller uvanlig kombinasjon, sammenlign med det enheten støtter før du antar at sertifikatet er ødelagt. Daemonloggen vil vise at håndtrykket kommer lenger enn i tillitstilfellet, og det er tegnet på at kjeden ikke lenger er problemet.

Ikke installer den mellomliggende som brukerrot på telefonen

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

Hold de tre avgjørelsene 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, en profil som navngir sertifikatet riktig, og en nøkkeltype flåten støtter er tre små fakta, og de utgjør hele denne feilen.

Relaterte artikler