Din VPN-klient säger att certifikatet inte kunde verifieras, och dialogen stannar där. Filen finns, servern är uppe, och samma profil fungerade på en annan bärbar dator i förra månaden. Under den enradiga varningen lät klienten peer-certifikatet passera fyra grindar: en certifikatmyndighet som du har konfigurerat garanterar signaturvägen, vägen når myndigheten, peernamnet är det du bad om, och certifikatet kan användas nu för detta syfte. Hitta grinden som stängdes och reparationen är oftast en fil; hoppa över det steget och du importerar om buntar hela eftermiddagen.

Läs dialogen innan du redigerar profilen

Certifikatfel formuleras av biblioteket under, inte av VPN-produkten du installerade, så den exakta strängen är ditt första bevis. ”Det gick inte att hämta certifikatet från den lokala utfärdaren” pekar på vägen eller på förtroendeankaret. ”Certifikatet har gått ut eller är ännu inte giltigt” pekar på tiden. ”Certifikatets syfte stöds inte” pekar på utökad nyckelanvändning. En namnavvikelse berättar vilket namn den ville ha. Ingen av de fyra åtgärdas genom att installera om klienten.

Höj loggnivån innan du ändrar något. OpenVPN rapporterar verifieringsfelet kring handskakningen när du kör det med --verb 4, och strongSwan skriver sina identitets- och kedjebeslut till charon-loggen. Bekräfta sedan vilket certifikat du undersöker, eftersom folk rutinmässigt testar filen på disken medan profilen bäddar in en äldre kopia. När profilen bäddar in PEM-block är det inbäddade certifikatet det som testas.

En certifikatmyndighet signerar identiteter, inte behörigheter

Myndigheten håller ett namn och en signeringsnyckel. Den utfärdar certifikat som binder en publik nyckel till det namnet enligt sin egen policy, med ett giltighetsfönster och användningsbegränsningar bifogade. Din klient behöver bara myndighetens certifikat för att känna igen utfärdaren; den behöver aldrig signeringsnyckeln, och att skicka den nyckeln till klienter skulle ge dem möjligheten att skapa vilken identitet som helst som driftsättningen litar på.

Att lita på en myndighet gör varje certifikat den har signerat till en kandidat, inte rätt peer. Ett webbservercertifikat från samma interna CA är också en kandidat. Därför finns namn- och syftesgrindarna, och därför väger en komprometterad CA-nyckel tyngre än någon enskild server: den når varje identitet som myndigheten någonsin har utfärdat. Dela ut klientcertifikat per enhet, så att en förlorad bärbar dator är en återkallning i stället för ett nyckelbyte för hela driftsättningen.

Bygg om vägen som klienten försöker bygga

Vägen går från peer-certifikatet, genom noll eller fler mellanliggande certifikat, till en rot i ditt förtroendelager. Ett saknat mellanliggande certifikat är det vanligaste kedjefelet, och från klientsidan ser det identiskt ut med en icke betrodd rot. Läs bladet först och låt sedan OpenSSL bygga vägen från materialet du tänker skicka.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Utgångsstatus noll betyder att vägen byggdes från dessa filer; ett fel namnger certifikatet den inte kunde nå. Om openssl verify lyckas medan klienten fortfarande vägrar ligger skillnaden i vad servern faktiskt skickar eller i vilken förtroendefil profilen läser in. I OpenVPN kan mellanliggande certifikat följa med servercertifikatfilen eller levereras separat med --extra-certs, och en bunt med två rötter skrivna under samma subjektnamn skickar en av dina klienter ned i fel gren.

Namn och syfte är separata grindar

Kedjebyggnad frågar aldrig om namnet är ditt. OpenVPN kontrollerar det bara när profilen sätter --verify-x509-name, och den äldre vanan att bara matcha det vanliga namnet bryts på certifikat vars identiteter lever i subjectAltName. IKEv2-driftsättningar matchar den konfigurerade identiteten mot SAN-poster eller mot det särskiljande namnet, beroende på klienten, och ett wildcard- eller %any-värde slår tyst av jämförelsen du trodde du hade.

Därefter kommer tid och syfte. En bärbar dator vars klocka går ett par timmar för fort avvisar ett certifikat som ännu inte är giltigt, och ett utgånget mellanliggande certifikat får vägen att misslyckas medan bladet är giltigt. Syftesfel kommer från ett certifikat utan serverAuth i utökad nyckelanvändning, eller med en keyUsage som inte tillåter handskakningssignaturen, vilket OpenSSL rapporterar som ett icke stött certifikatsyfte. Utfärda på nytt från rätt mall; ingenting i det meddelandet är skäl att stänga av verifieringen.

Återkallning körs bara om någon har konfigurerat den

En CRL eller ett OCSP-svar konsulteras inte automatiskt. På en OpenVPN-server kontrolleras klientcertifikat mot en lista bara när --crl-verify pekar på en. Klientsidans kontroll av servercertifikatet beror på implementeringen och saknas ofta. strongSwan behöver sitt återkallningsinsticksprogram och en policy innan det tittar på en CRL för en peer.

Det förklarar ärendet du till slut får: ett återkallat klientcertifikat ansluter fortfarande, och alla drar slutsatsen att återkallningen är trasig. Ingenting kontrollerade. Publicera och uppdatera CRL:en, eller håll klientcertifikaten så kortlivade att en inaktuell återkallning bara spelar roll en kort tid, och öva återkallningsvägen på ett laboratoriecertifikat innan du behöver den under en incident.

En reparationsordning som håller verifieringen på

Sortera efter symptom innan du rör filer, eftersom varje rad i tabellen skickar dig till ett annat objekt.

Client saysMost likely gateFirst check
unable to get local issuer certificatetrust anchor or missing intermediateyour own openssl verify against the files the profile loads
expired or not yet validvalidity windowleaf and intermediate dates against the device clock
unsupported certificate purposeextended key usageserverAuth present, keyUsage allows the handshake
name mismatchpeer identitysubjectAltName entries versus the profile name

Gå igenom listan i en enda omgång: bekräfta filen profilen läser in, bygg vägen själv, kontrollera att servern skickar det mellanliggande certifikatet, jämför klockan, läs SAN, läs EKU, och återanslut sedan och se samma logglinje försvinna. Om en enhet inte alls kan få någon CA är pinnning det ärliga alternativet, eftersom OpenVPN 2.6 accepterar --peer-fingerprint och snävar in förtroendet till en nyckel i stället för att ta bort kontrollen. RFC 5280 är referensen för vad vart och ett av dessa fält betyder.

Relaterade artiklar