Sertifikatenes livssyklus og tilbakekalling

Alle digitale sertifikater følger en definert livssyklus fra opprettelse til avvikling. Trinnene er: forespørsel og registrering (generere nøkkelpar, opprette CSR), utstedelse (CA-en validerer og signerer), distribusjon (installere på server eller enhet), bruk (aktiv driftsperiode), fornyelse (før utløp) og tilbakekalling eller utløp (slutten på levetiden). Håndtering av denne livssyklusen i stor skala – særlig i virksomheter med tusenvis av sertifikater – krever automatisering og verktøy for sertifikatlivssyklusstyring (CLM), siden manuell oppfølging uunngåelig fører til utløpte sertifikater som forårsaker driftsavbrudd.

Sertifikatets livssyklus begynner med en Certificate Signing Request (CSR). Den som ber om sertifikatet, genererer et nøkkelpar og oppretter deretter en CSR som inneholder den offentlige nøkkelen og Subject-informasjon (CN, O, C), og som signeres med den private nøkkelen (noe som beviser eierskap til den private nøkkelen uten å avsløre den). CSR-en sendes til CA-en, som validerer identiteten til den som ber om sertifikatet, og signerer sertifikatet dersom forespørselen godkjennes. Den private nøkkelen forlater aldri den som ba om sertifikatet. Generering av CSR er det avgjørende trinnet der nøkkelstyrken fastsettes – bruk minst 2048-bit RSA eller 256-bit ECC.

Sertifikater må fornyes før datoen notAfter utløper. Anbefalt praksis er å starte fornyelsesprosessen minst 30 dager før utløp (mange virksomheter tar sikte på 60–90 dager). Fornyelse innebærer vanligvis å generere en ny CSR og privat nøkkel, sende dette til CA-en og erstatte det gamle sertifikatet og den gamle nøkkelen på alle servere der de er distribuert. Let's Encrypt automatiserer denne prosessen ved hjelp av ACME-protokollen – verktøyet certbot fornyer automatisk sertifikater når det er mindre enn 30 dager igjen. Utløpte sertifikater fører til nettleserfeil som hindrer brukere i å få tilgang til tjenester.

Sertifikattilbakekalling er prosessen med å ugyldiggjøre et sertifikat før den planlagte utløpsdatoen. Grunner til tilbakekalling omfatter: at den private nøkkelen er kompromittert (mest kritisk – umiddelbar tilbakekalling er nødvendig), at sertifikatet ble utstedt ved en feil (feil domene eller feil virksomhet), at informasjonen om Subject er endret (virksomheten har skiftet navn eller en ansatt har sluttet), eller at CA-en selv er kompromittert. Tilbakekalling er avgjørende fordi nettlesere og systemer som ikke vet at et sertifikat er tilbakekalt, fortsetter å stole på det – noe som gir en angriper med den stjålne private nøkkelen mulighet til aktiv MITM-angrep frem til sertifikatet utløper eller det blir kjent at det er tilbakekalt.

En Certificate Revocation List (CRL) er en signert liste som publiseres av en CA, og som inneholder serienumrene til alle sertifikater CA-en har tilbakekalt, men som ennå ikke er utløpt. Klienter laster ned CRL-en, mellomlagrer den og kontrollerer om serienummeret til et presentert sertifikat finnes på listen. CRL-er har betydelige begrensninger: De kan være svært store (store CA-er har millioner av tilbakekalte sertifikater), klienter mellomlagrer dem ofte i timer eller dager, noe som fører til forsinkelser, og det er ineffektivt å laste ned hele CRL-en for hver tilkobling. CRL-er brukes fortsatt, men suppleres eller erstattes i økende grad av OCSP.

OCSP (Online Certificate Status Protocol) muliggjør sanntidskontroll av sertifikattilbakekalling uten at klienter må laste ned komplette CRL-er. Klienten sender en forespørsel til CA-ens OCSP-responder med sertifikatets serienummer. Responderen svarer med et signert svar som angir om sertifikatet er good, revoked (med dato og årsak for tilbakekallingen) eller unknown. OCSP er raskere og mer oppdatert enn CRL, men hver TLS-tilkobling krever en ekstra HTTP-tur-retur til OCSP-responderen, noe som øker forsinkelsen. OCSP-svar signeres av CA-en for å hindre manipulering.

OCSP Stapling løser forsinkelsesproblemet ved sanntidskontroll med OCSP. I stedet for at klienten spør CA-ens OCSP-responder under hvert TLS-håndtrykk, henter serveren sitt eget OCSP-svar på forhånd fra CA-en og «stapler» (legger det ved) i TLS-håndtrykket. Klienten mottar et ferskt, CA-signert OCSP-svar direkte fra serveren – uten behov for en ekstra rundtur. Serveren oppdaterer det vedlagte OCSP-svaret med jevne mellomrom (vanligvis hver time). OCSP Stapling forbedrer tilkoblingshastigheten og reduserer belastningen på CA-enes OCSP-respondere, samtidig som kontroll av tilbakekalling opprettholdes.

OCSP Must-Staple er en X.509-utvidelse som forteller nettlesere at serveren må oppgi et vedlagt OCSP-svar. Uten denne utvidelsen utfører nettlesere en «soft fail» hvis OCSP-kontrollen mislykkes – de tillater tilkoblingen likevel (for å hindre at avbrudd hos OCSP-responderen blokkerer all TLS-trafikk). En angriper kan utnytte denne oppførselen ved soft fail ved å blokkere klientens OCSP-forespørsel, slik at det ser ut som sertifikatet fortsatt er gyldig selv etter tilbakekalling. OCSP Must-Staple forhindrer dette ved å kreve et gyldig vedlagt svar; uten det nekter nettleseren tilkoblingen. Utbredelsen er fortsatt begrenset på grunn av kompleksiteten ved utrulling.

Sertifik tilbakekalling og sertifikatfiksering håndterer det samme problemet – tillit til falske sertifikater – men fra ulike vinkler. Tilbakekalling (CRL/OCSP) er en reaktiv mekanisme: CA-en ugyldiggjør et sertifikat etter at et problem er oppdaget. Fiksering er en proaktiv mekanisme: programmet avviser alle sertifikater bortsett fra et som er forhåndsgodkjent. Fiksering gir sterkere garantier enn tilbakekalling fordi den fungerer selv om CA-en ikke tilbakekaller sertifikatet raskt nok, men innfører mindre fleksibilitet ved utrulling. Til Security+-eksamen må De kjenne til begge mekanismene og forstå at tilbakekalling er standardmekanismen i PKI, mens fiksering er et valgfritt forsvar-i-dybden-tiltak.

Når et sertifikat tilbakekalles, tilordner CA-en en årsaks kode for tilbakekalling som hjelper klienter og administratorer med å forstå hvorfor. Vanlige årsakskoder som er definert i RFC 5280, omfatter: keyCompromise (den private nøkkelen er kompromittert), cACompromise (utstedende CA er kompromittert), affiliationChanged (organisasjonen til subjektet er endret), superseded (et nytt sertifikat er utstedt som erstatning), cessationOfOperation (domenet er ikke lenger aktivt) og privilegeWithdrawn (tillatelsen er trukket tilbake). Årsakskoden vises både i CRL-oppføringer og OCSP-svar, og gir kontekst for hendelseshåndteringsteam som undersøker tilbakekallingshendelser.

Protokollen ACME (Automatic Certificate Management Environment), som brukes av Let's Encrypt, automatiserer hele sertifikatlivssyklusen. ACME-klienter (for eksempel certbot) ber automatisk om, fornyer og distribuerer sertifikater uten menneskelig inngripen. CA-en bruker utfordringer for domenevalidering til å bekrefte eierskap til domenet: HTTP-01-utfordringen krever at en bestemt fil plasseres på en kjent URL, mens DNS-01-utfordringen krever at det opprettes en DNS TXT-post. ACME har endret sertifikathåndtering fundamentalt – 90-dagers sertifikater fra Let's Encrypt driver nå en stor andel av internetts HTTPS-trafikk, og alle fornyes automatisk.

I denne leksjonen har De lært at sertifikatlivssyklusen går fra generering av CSR via utstedelse og distribusjon til fornyelse eller tilbakekalling; CRL tilbyr tilbakekallingslister i grupper, mens OCSP tilbyr sanntidsstatus for enkeltsertifikater; OCSP Stapling fjerner forsinkelsen ved sanntids-OCSP; og ACME (Let's Encrypt) automatiserer hele fornyelseslivssyklusen. Neste tema er brukstilfeller for PKI.