Självsignerat VPN-certifikat: vad det betyder och vad det litar på

Här gör två övertygelser mest skada: att ett självsignerat VPN-certifikat betyder att tunneln inte är krypterad, och att installation av vad VPN-klienten än bad om bara påverkar VPN:en. Ingen av dem överlever kontakten med en verklig utrullning. Ett självsignerat certifikat beskriver en signaturrelation, inte en säkerhetsdom, och räckvidden för det förtroende du lägger till beror på vilket lager det hamnar i. Jag har sett en helpdesk importera en leverantörsrot i en Windows-dator för att tysta en varning och sedan tillbringa en eftermiddag med att förklara varför webbläsaren slutade klaga på en orelaterad portal. De två halvorna av den här frågan hör ihop, så behandla dem som en.

Ett certifikat är inte ett förtroendelager

Filen som servern presenterar bär en offentlig nyckel, ett subjektnamn, ett utgivarnamn, giltighetsdatum och tillägg. Självsignerat betyder att subjektet och utgivaren är samma entitet och signaturen verifieras med certifikatets egen nyckel. Ingenting i den definitionen säger att anslutningen är svag, och ingenting säger att klienten kommer att acceptera den.

Acceptans kommer någon annanstans ifrån: en CA-fil som du pekar klienten mot, ett fingeravtryck som du jämför för hand, eller en rot som redan ligger i ett lager som klienten läser. En utrullning kan vara helt frisk medan dess certifikat skulle underkännas i varje offentligt test. openssl verify mot systembunten rapporterar en okänd utgivare, och den rapporten är korrekt, inte ett fel.

OpenVPN:s ca-alternativ är det tydligaste fallet av appbegränsat förtroende. Den filen namnger de ankare som klienten accepterar, och den kan innehålla en privat CA eller, i en liten utrullning, serverns eget självsignerade certifikat. Version 2.6 accepterar även --peer-fingerprint för att fästa ett SHA-256-fingeravtryck i stället för att distribuera en CA-fil. WireGuard ligger ännu längre bort: det har inga certifikat alls, bara en statisk offentlig nyckel per peer, så frågan om självsignering passar inte på det.

Var du installerar förtroende avgör vem som ärver det

Sätt samma certifikat på tre ställen och du får tre olika sprängradier. En bunt som bara VPN-klienten läser påverkar den klienten. En rot i operativsystemets lager påverkar varje program som rådgör med det lagret. En webbläsare med egen förtroendedatabas kan ignorera båda, och därför kan en varning överleva en import som verkade fungera.

På Debian eller Ubuntu ändrar det systembunten att lägga en fil i /usr/local/share/ca-certificates/ och köra update-ca-certificates. På Windows skriver certutil -addstore -f Root till maskinlagret och kräver en förhöjd kommandotolk, medan tillägget av -user i stället riktar sig mot den aktuella användarens lager; de två är inte utbytbara. Firefox håller sin egen NSS-databas, så en import på OS-nivå kanske aldrig dyker upp där.

Omfattningen spelar roll på grund av vad en myndighet kan göra. En utgivande CA kan signera namn som den inte har någon relation till, så allt som litar på det lagret accepterar dessa signaturer. Ett enda fäst blad kan inte göra det; det autentiserar exakt en peer-identitet. Om målet är att få en VPN att ansluta, når en appbegränsad CA eller ett fäst blad det, medan en maskinvidd rot är en mycket större eftergift än symptomet kräver.

Du krypterar fortfarande utan en offentlig CA

TLS-handskakningen härleder sessionsnycklar oavsett om peer-certifikatet kedjar till något du redan litar på. Självsignerat betyder inte klartext, och inte att trafiken är läsbar under färd. Det betyder att klienten inte har någon a priori anledning att tro att nyckeln tillhör den server den bad om.

I den luckan lever riktiga attacker. En klient som är konfigurerad att acceptera vilket certifikat som helst, antingen genom en inaktiverad verifieringsinställning eller en lita-på-det-ändå-knapp som klickats en gång och glömts, krypterar glatt till den som svarar. Avlyssningen sker i autentiseringssteget, innan applikationsdata rör sig. Kryptering utan identitetskontroll håller en passiv observatör ute och gör lite annat.

Att lita på utgivaren hoppar inte över namnkontrollen

Kedjevalidering, namnmatchning och certifikatets syfte är separata beslut. En kedja kan vara giltig medan namnet är fel, och ett namn kan matcha medan certifikatet utfärdades för en annan roll. RFC 5280 definierar de fält som bär dessa begränsningar, och hur strikt en klient genomdriver dem är en sak för varje applikation.

OpenVPN gör uppdelningen synlig. verify-x509-name fäster det förväntade subjektet genom name-, name-prefix- eller subject-matchning. remote-cert-tls server kräver att peer-certifikatet kan användas som servercertifikat, vilket avvisar ett klient-bara-certifikat även när utgivaren är betrodd. Ingen av inställningarna ersätts av att skicka en CA-fil.

Undersök certifikatet innan du bestämmer något:

• openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName visar vem som utfärdade det, för vilka namn och till när.
• openssl verify -CAfile ca.crt server.crt kontrollerar om kedjan du planerar att skicka faktiskt validerar bladet.
• openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -CAfile ca.crt -verify_return_error fungerar för TLS-slutpunkter som en webbportal; OpenVPN-protokollet på 1194 är inte ett vanligt TLS-flöde, så det testet gäller inte där.

Ett certifikat med utgånget datum, utan subjectAltName för namnet du ansluter till, eller utan serverAuth-användning misslyckas oavsett hur noggrant ankaret installerades.

Fem kontroller innan du accepterar ett

Jämför fingeravtrycket över en kanal som inte är anslutningen du försöker reparera: en konsol, ett installationsprogram du redan har, en signerad konfigurationsfil. openssl x509 -in server.crt -noout -fingerprint -sha256 på servern och samma värde i klientloggen räcker för att veta att du tittar på ett objekt.

Bestäm sedan vad du installerar: ett blad eller en myndighet som kan prägla fler. Bestäm därefter var det tar vägen, och namnge de applikationer som läser det lagret. Skriv ner borttagningsvägen medan du fortfarande minns den, för lita-på-det-och-gå-vidare är hur en tillfällig import blir permanent.

Planera till sist ändringen. Ett fäst certifikat eller fingeravtryck måste uppdateras genom samma betrodda kanal när certifikatet roterar, och en privat CA har sin egen livscykel för utfärdande och återkallande. Om den privata nyckeln läcker reparerar det ingenting att lita på en kopia av samma certifikat igen; identiteten måste bytas ut.

Om en varning överlever alla fem kontrollerna är den användbara frågan inte vilken knapp som tystar den, utan vilket lager klienten faktiskt läser och varifrån den roten kom. Svara på det, och importen du är på väg att göra blir ett beslut i stället för en reflex.