Tilbakekalte du feil VPN-sertifikat? Gjenopprettingsmuligheter og grenser
Identifiser utstederen, serienummeret og årsakskoden før du rører CA-en. Permanent tilbakekalling, sertifikatsperre og en opptakspause er tre reparasjoner.
Noen har tilbakekalt et sertifikat i CA-konsollen, og nå kan ikke en bruker koble til. Den første innskytelsen er å finne angre, og for de fleste PKI-er finnes det ikke: tilbakekalling er et erklært faktum om et serienummer, og den støttede veien tilbake er et nytt sertifikat, ikke en omvendt post. Gå gjennom kontrollene nedenfor i rekkefølge, fordi hvilken reparasjon du har lov til å bruke avhenger av årsakskoden og av om nøkkelen noen gang ble eksponert.
Identifiser sertifikatet, ikke personen
Vanlige navn gjentas. En bruker som registrerte seg på nytt i forrige kvartal kan ha to sertifikater med samme CN og ulike serienumre, og tilbakekalling av det ene lar det andre virke. Fastslå først det nøyaktige objektet:
openssl x509 -in client.crt -noout -serial -issuer -subject -dates
openssl crl -in ca.crl -noout -text | head -40
Skriv ned serienummeret, utstederen, tilbakekallingsdatoen og årsaken som er registrert i CRL-en. Bekreft deretter hvilke enheter som presenterer det serienummeret, fordi et tilbakekalt sertifikat fortsatt kan være installert på en bærbar PC, en telefon og en reserve-ruter, og en erstatning som bare når én av dem gir en ny hendelse.
En rask atferdssjekk bekrefter tilstanden uten å endre noe:
openssl verify -crl_check -CAfile ca.crt -CRLfile ca.crl client.crt
Hvis den rapporterer sertifikatet som tilbakekalt, er CRL-en og klienten enige; hvis den verifiserer rent, er klienten du holder ikke den tilbakekalte, og søket fortsetter.
Sjekk om CA-en brukte sperre eller permanent tilbakekalling
RFC 5280 definerer certificateHold som en midlertidig tilstand, og removeFromCRL som signalet som frigjør den. Den livssyklusen er reell, men det er ikke en generell angreknapp. Å lese årsakskoden forteller deg om utstederen noen gang mente å støtte frigivelse.
Fellen er å anta at en midlertidig intensjon betyr en midlertidig post. Hvis CA-posten bærer keyCompromise eller cessationOfOperation, er sertifikatet permanent tilbakekalt, uansett hva personen som trykket på knappen mente. Omvendt er en post merket certificateHold på en CA som ikke implementerer sperrefrigivelse, permanent i praksis, fordi ingenting noen gang vil publisere frigivelsen.
OpenSSL-baserte CA-er illustrerer grensen. Kommandoen ca godtar -crl_reason-verdier, inkludert certificateHold og removeFromCRL, men den genererer ikke delta-CRL-er — OpenSSL CA-dokumentasjonen nevner denne begrensningen for CRL-utdataene. En full CRL som bare utelater serienummeret er en annen publiseringsmodell enn en delta som sier "denne posten er frigitt", så å lime inn removeFromCRL i en OpenSSL-basert VPN-CA gir ikke den standarddefinerte frigivelsen.
Hvis nøkkelen kan ha vært eksponert, bytt den ut
Et tilbakekalt sertifikat er en erklæring om at denne nøkkelen kanskje ikke lenger kan stoles på. Hvis tilbakekallingen var saklig riktig — bærbar PC mistet, nøkkel kopiert til en delt disk, privat nøkkel limt inn i en sak — reverserer gjenoppretting av samme sertifikat en sikkerhetsbeslutning som fungerte som tiltenkt.
Utsted et nytt nøkkelpar gjennom registreringsprosessen, distribuer den nye profilen og la det gamle serienummeret være tilbakekalt hele levetiden. Oppdater alt som fester identitet til serienummer eller fingeravtrykk, inkludert opptaksøster, enhetsoversikter og overvåking som forventer et bestemt sertifikat.
Bekvemmelighetsargumentet for å gjenopprette det gamle er reelt, men det bør besvares eksplisitt og ikke stille. "Brukeren trenger tilgang i dag" er en grunn til å fremskynde utstedelsen, ikke en grunn til å oppheve tilbakekallingen av en nøkkel du ikke kan gjøre rede for.
Hvis det var en administrativ feil, erstatt under kontroll
Når tilbakekallingen rett og slett var feil og nøkkelen aldri ble eksponert, er reparasjonen fortsatt en kontrollert utskifting og ikke en redigering. Bruk utstederens støttede prosess, hold serienummeret og utstedelseshistorikken intakt, og unngå de to fristende snarveiene: å snu statusstegnet i index.txt fra R tilbake til V, og å slette utstedelsesraden slik at et nytt sertifikat kan gjenbruke serienummeret.
På en OpenSSL-CA er databasen tabulatorseparert og lett å lese feil, noe som gjør manuell redigering fristende:
awk -F'\t' '$1=="R" {print $4, $3, $6}' index.txt
Les den, ikke skriv i den. Redigering av filen endrer neste CRL uten noe revisjonsspor, og enhver annen CA-forekomst eller sikkerhetskopi som fortsatt har den opprinnelige raden vil være uenig med den senere.
Etter at du har utstedt erstatningen, publiser en fersk CRL gjennom den normale mekanismen og la klientene hente den. Å fjerne en CRL, forkorte levetiden til ingenting eller deaktivere tilbakekallingskontroll i klientprofilen reparerer én bruker ved å svekke enhver annen tilbakekalling CA-en noen gang har publisert.
Bekreft et ferskt opptak og ta vare på posten
Test med en ny tilkobling, ikke økten som allerede var åpen. En levende tunnel kjører kanskje ikke opptakskontrollene på nytt som et ferskt håndtrykk utfører, og CRL-buffere betyr at en klient kan fortsette å koble til til den oppdateres. Koble fra, koble til igjen, og bekreft i serverloggen hvilket serienummer som ble tillatt.
Registrer hva som skjedde mens det fortsatt er ferskt: hvilket serienummer som ble tilbakekalt, av hvem, med hvilken årsak, hvilken erstatning som ble utstedt, og når CRL-en ble republisert. Den posten er det som gjør neste tilbakekallingsgjennomgang mulig, og den er også beviset på at feilen ble håndtert i stedet for skjult.
For korte suspensjoner i fremtiden, bruk en opptakspausemekanisme hvis utrullingen har en — en konto deaktivert i identitetslaget, et fjernet gruppemedlemskap, en tilbakeholdt klientprofil. Det holder en midlertidig policybeslutning atskilt fra spørsmålet om et utstedt sertifikat fortsatt er pålitelig, og nettopp den forskjellen gikk tapt første gang.