Återkallade du fel VPN-certifikat? Återställningsalternativ och gränser

Någon har återkallat ett certifikat i CA-konsolen och nu kan en användare inte ansluta. Den första impulsen är att hitta ångra, och för de flesta PKI:er finns det inte: återkallelse är ett uttalat faktum om ett serienummer, och den stödda vägen tillbaka är ett nytt certifikat, inte en omvänd post. Gå igenom kontrollerna nedan i ordning, eftersom vilken reparation du får använda beror på orsakskoden och på om nyckeln någonsin exponerades.

Identifiera certifikatet, inte personen

Vanliga namn upprepas. En användare som registrerade sig igen förra kvartalet kan ha två certifikat med samma CN och olika serienummer, och återkallelse av det ena låter det andra fungera. Fastställ först det exakta objektet:

openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40

Skriv ned serienumret, utfärdaren, återkallelsedatumet och orsaken som registrerats i CRL:en. Bekräfta sedan vilka enheter som presenterar det serienumret, eftersom ett återkallat certifikat fortfarande kan vara installerat på en bärbar dator, en telefon och en reservrouter, och en ersättning som bara når en av dem ger en ny incident.

En snabb beteendekontroll bekräftar tillståndet utan att ändra något:

openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt

Om den rapporterar certifikatet som återkallat är CRL:en och klienten överens; om den verifierar rent är klienten du håller inte den återkallade, och sökningen fortsätter.

Kontrollera om CA:n använde spärr eller permanent återkallelse

RFC 5280 definierar certificateHold som ett tillfälligt tillstånd och removeFromCRL som signalen som frigör det. Den livscykeln är verklig, men det är inte en allmän ångraknapp. Att läsa orsakskoden säger om utfärdaren någonsin avsåg att stödja frigivning.

Fällan är att anta att en tillfällig avsikt betyder en tillfällig post. Om CA-posten bär keyCompromise eller cessationOfOperation är certifikatet permanent återkallat, oavsett vad personen som tryckte på knappen avsåg. Omvänt är en post märkt certificateHold på en CA som inte implementerar spärrfrigivning permanent i praktiken, eftersom ingenting någonsin kommer att publicera frigivningen.

OpenSSL-baserade CA:er illustrerar gränsen. Kommandot ca accepterar -crl_reason-värden, inklusive certificateHold och removeFromCRL, men det genererar inte delta-CRL:er — OpenSSL CA-dokumentationen anger den begränsningen för sin CRL-utdata. En fullständig CRL som helt enkelt utelämnar serienumret är en annan publiceringsmodell än en delta som säger "den här posten är frigiven", så att klistra in removeFromCRL i en OpenSSL-baserad VPN-CA ger inte den standarddefinierade frigivningen.

Om nyckeln kan ha exponerats, byt ut den

Ett återkallat certifikat är ett uttalande om att den här nyckeln kanske inte längre går att lita på. Om återkallelsen var sakligt korrekt — bärbar dator förlorad, nyckel kopierad till en delad disk, privat nyckel inklistrad i ett ärende — vänder återställningen av samma certifikat ett säkerhetsbeslut som fungerade som avsett.

Utfärda ett nytt nyckelpar genom registreringsprocessen, distribuera den nya profilen och låt det gamla serienumret vara återkallat hela dess livstid. Uppdatera allt som fäster identitet vid serienummer eller fingeravtryck, inklusive tillträdeslistor, enhetsinventarier och övervakning som förväntar sig ett visst certifikat.

Bekvämlighetsargumentet för att återställa det gamla är reellt, men det bör besvaras uttryckligen och inte tyst. "Användaren behöver åtkomst i dag" är ett skäl att påskynda utfärdandet, inte ett skäl att upphäva återkallelsen av en nyckel du inte kan redogöra för.

Om det var ett administrativt fel, byt ut under kontroll

När återkallelsen helt enkelt var fel och nyckeln aldrig exponerades är reparationen fortfarande ett kontrollerat utbyte och inte en redigering. Använd utfärdarens stödda process, håll serienumret och utfärdandehistoriken intakta och undvik de två frestande genvägarna: att vända statussteget i index.txt från R tillbaka till V, och att radera utfärdanderaden så att ett nytt certifikat kan återanvända serienumret.

På en OpenSSL-CA är databasen tabbseparerad och lätt att läsa fel, vilket gör manuell redigering frestande:

awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt

Läs den, skriv inte i den. Redigering av filen ändrar nästa CRL utan något revisionsspår, och varje annan CA-instans eller säkerhetskopia som fortfarande har den ursprungliga raden kommer senare att vara oenig med den.

När du har utfärdat ersättningen, publicera en färsk CRL via den normala mekanismen och låt klienterna hämta den. Att ta bort en CRL, förkorta dess livstid till ingenting eller inaktivera återkallelsekontrollen i klientprofilen reparerar en användare genom att försvaga varje annan återkallelse som CA:n någonsin har publicerat.

Bekräfta ett färskt tillträde och bevara posten

Testa med en ny anslutning, inte med sessionen som redan var öppen. En levande tunnel kör kanske inte om de tillträdeskontroller som ett färskt handskakning utför, och CRL-cachar gör att en klient kan fortsätta ansluta tills den uppdateras. Koppla från, anslut igen och bekräfta i serverloggen vilket serienummer som tilläts.

Registrera vad som hände medan det fortfarande är färskt: vilket serienummer som återkallades, av vem, med vilken orsak, vilken ersättning som utfärdades och när CRL:en publicerades igen. Den posten är det som gör nästa återkallelsegranskning möjlig, och den är också beviset på att felet hanterades i stället för att döljas.

För korta avstängningar i framtiden, använd en tillträdespausmekanism om driftsättningen har en — ett konto inaktiverat i identitetslagret, ett borttaget gruppmedlemskap, en kvarhållen klientprofil. Det håller ett tillfälligt policybeslut åtskilt från frågan om ett utfärdat certifikat fortfarande är pålitligt, och just den skillnaden gick förlorad första gången.