Självsignerat klientcertifikat? VPN-servern avvisar det ändå

Operatören skickar en adress och ett användarnamn, och klienten ber om en CA-fil, ett certifikat och en nyckel. Att generera dessa tre lokalt känns som det uppenbara nästa steget. Det ger ett certifikat som bara din egen maskin tror på. Serverns tillit är förankrad i en CA som du inte kontrollerar, så handskakningen slutar innan den börjar.

Tillit bor på servern, inte i din profil

Certifikatautentisering är en jämförelse. Klienten visar ett certifikat; gatewayen kontrollerar om det signerades av en av CA:erna i dess konfiguration.

Din profil anger CA-filen som klienten ska använda för att verifiera servern. Den kan inte ange en CA som servern ska använda för att verifiera dig. Den halvan av konfigurationen är inte din.

Ett hemgjort certifikat misslyckas i den här jämförelsen även när det är tekniskt perfekt. Det har en giltig signatur, ett subjekt och datum, men utfärdaren är en CA som gatewayen aldrig har hört talas om. Felet visas under handskakningen, efter att servern redan har bett om ett certifikat. Ingenting i klientprofilen kan ändra svaret.

Varför ett självsignerat certifikat inte kan ersätta det

Ett självsignerat certifikat signeras med sin egen nyckel. Signaturen verifieras mot samma fil, vilket gör det självkonsistent och oanvändbart som legitimation för någon annans gateway.

Gatewayen frågar inte om certifikatet är internt konsistent. Den frågar om en betrodd utfärdare signerade det.

Därför är felmeddelandena förvirrande. Klienten kan rapportera ett verifieringsfel som låter som ett serverproblem, medan servern loggar en okänd utfärdare. Båda beskriver samma brist på överensstämmelse från motsatta ändar.

CSR-vägen behåller din privata nyckel

Du kan fortfarande göra det mesta av arbetet lokalt. Generera ett nyckelpar, bygg en begäran om certifikatsignering kring den offentliga halvan och skicka begäran till operatören. Bara begäran lämnar din maskin. Den privata halvan stannar där du genererade den.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Operatören signerar begäran med sin CA och returnerar ett certifikat. Din privata nyckel har aldrig rest, och resultatet kedjar till ankaret som gatewayen litar på.

Hanterade tjänster hoppar ofta över CSR:n och utfärdar hela paketet. Det är ett rimligt byte när samma leverantör redan avslutar tunneln och har CA:n. Nyckelns förvaring blir inte bättre av att du behåller den, eftersom leverantören kan skapa en ny när som helst.

Paket importeras, de installeras inte

Leverantörspaket med säkerhetsklingande namn är ofta OpenVPN-profiler. De innehåller konfiguration och ibland certifikat, och de installerar ingenting. Importera filen i en klient som talar protokollet, och anslutningen är konfigurerad.

Hanteringsregeln följer av innehållet. Om profilen bäddar in en privat nyckel är det en legitimation och förtjänar samma omsorg som ett lösenord: ingen e-post, inget kodförråd, ingen delad nedladdningsmapp. När operatören levererar ca.crt, client.crt och client.key separat, förvara dem tillsammans med restriktiva behörigheter och peka profilen mot dem.

Lägg till kontrollerna som operatören kan ha hoppat över

En routergenererad profil saknar ibland peer-verifiering. remote-cert-tls server kräver att peer-certifikatet bär syftet serverautentisering, så att ett klientcertifikat inte kan spelas upp som server. Den enda raden är en liten ändring med tydlig motivering.

verify-x509-name går längre när operatören kan ange förväntat subjekt eller SAN. Båda är små tillägg till en profil, och båda är försvarbara. Granska vad du fick innan du importerar det.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Verifieringsinställningar är inte en reparation av en bruten kedja. Om utfärdaren är fel är svaret ett certifikat från rätt CA, inte en flagga som stänger av kontrollen. Att stänga av verifiering gör ett autentiseringsfel till ett oupptäckt fel.

Be om ett enda paket: myndighetens certifikat som PEM, ett klientcertifikat som myndigheten signerat, en nyckel som du genererat eller som kommit via en kanal du litar på, och det exakta servernamn som certifikatet ska presentera. Notera utgångsdatumet i samma meddelande, eftersom ett utgånget certifikat ser ut som ett nätverksfel månader senare.