Sertifikater Forklart

This was written for internal documentation at work and I figured it might as well be posted here as well. An english translation might exist at a later point.

Generelt om sertifikater

Om du jobber med utviklere eller er en selv er sjansen stor for at du før eller siden hører snakk om sertifikater. Denne siden forsøker å forklare hva et Sertifikat er og litt om hvordan de fungerer.

Hvem trenger å vite dette?

Sertifikater er først og fremst noe som brukes i infrastruktur, til integrasjoner og blant utviklere. Likevel har disse en tendens til å treffe andre roller på teamet og også sluttbrukere - spesielt når noe går galt. Det kan derfor være litt interessant å vite hva det prates om.

Hvorfor bruker vi sertifikater?

Avhengig av kontekst brukes sertifikater til en eller flere av disse tingene:

• Autentisering
• Kryptering
• Signering

Det er derfor fort gjort å la seg forvirre noe da bruken kan være delvis overlappende. Vi skal forklare litt generelt før vi kommer tilbake til hvordan sertifikater brukes i Posten Signering.

Veldig kort om asymmetriske nøkkelpar

For å forstå sertifikater må vi kjapt touche innom såkalte nøkkelpar brukt i asymmetrisk kryptografi. Vi ignorerer all matte her, det eneste man trenger å vite er at et nøkkelpar består av to nøkler - A og B. Disse er ofte referert til som en privat nøkkel og en offentlig nøkkel da den ene skal holdes hemmelig, mens den andre fritt kan publiseres rundt om på Internett.

I symmetrisk kryptering brukes en hemmelighet eller nøkkel, for eksempel Passord123 til å kryptere og dekryptere informasjon. Asymmetrisk kryptering er forskjellig fra symmetrisk kryptering ved at det privat nøkkel A krypterer bare kan dekrypteres med offentlig nøkkel B og motsatt. Dvs at offentlig nøkkel B og kan også kryptere informasjon som bare privat nøkkel A kan dekryptere.

Konsekvensene av dette er at man kan gjøre to veldig like operasjoner, men ved veldig distinkte bruksområder

1. Hvem som helst kan benytte offentlig nøkkel B til å kryptere data som bare eier av privat nøkkel A (Alice) kan dekryptere
2. Hvis informasjon kan dekrypteres med nøkkel B så vet man at den har blitt kryptert med nøkkel A og om vi stoler på at Alice har kontroll på nøkkelen sin så vet vi også med sikkerhet hvor informasjonen stammer fra

Om man i tillegg antar at Bob har sitt eget distinkte nøkkelpar A' og B' kan man ved å kombinere Alice og Bob sine nøkler generere data som vi vet stammer fra Alice og som bare kan leses av Bob og vice versa.

Vi går ikke noe mer inn på hvorfor dette kan være veldig nyttig, men det er det altså.

Så hva er egentlig et Sertifikat?

Utfordringen med å nå situasjonen beskrevet over handler i stor grad om å vite om en offentlige nøkkel B faktisk tilhører den man tror. Det finnes flere svar på dette spørsmålet, men et av de mest utbredte er sertifikater. Sertifikater er i praksis en offentlig nøkkel med en del metadata hvis hensikt blant annet er å formidle eier av sertifikatet. Målet er altså å kunne stole på informasjonen (den offentlige nøkkelen) som presenteres oss, uten at vi nødvendigvis har møtt noen ansikt-til-ansikt og selv kan fastslå at den tilhører den vi ønsker. Vi kommer tilbake til akkurat hvordan det skjer.

Her er typisk data som et sertifikat, sammen med den offentlige nøkkelen, består av (ikke en utfylende liste):

• En identifikator av sertifikateier. Dette kan typisk være et domene, et organisasjonsnummer, en epostadresse eller en annen unik id
• En gyldighetsperiode der sertifikatet skal regnes som gyldig
• En unik identifikator på selve sertifikatet
• Typisk hvilke anvendelse sertifikatet er ment for
• En digital signatur over sertifikatet fra en tredjepart

Sertifikatautoriteter (Certificate Authorities)

For å gjøre en lang historie kort så har vi i dag ingen vanntett metode for å avsløre løgn på Internett¹. Det vil si at hvis jeg vil lage et et sertifikat der jeg påstår at jeg er “HM Kong Harald V” så er det ingen teknisk begrensning på dette. Det er derfor essensielt at et sertifikat bekreftes av en autoritet man stoler på. Vi sier ofte at et sertifikat er utstedt av en CA (Certificate Authority) selv om det som i praksis ofte skjer er at man ved en CSR (Certificate Signing Request) får sertifikatet sitt signert av en CA - en prosess der en god CA skal gå god for at informasjonen i sertifikatet stemmer.

Denne signaturen gjøres med CA-en sin private nøkkel A og vi vet jo nå at om vi bare har den offentlige nøkkelen B (som en del av et eget sertifikat) og vet at den tilhører CA så kan vi utlede at signaturen må ha kommet fra CA, og stoler vi på CA så kan vi stole på at informasjonen i sertfikatet stemmer.

Den observante leser vil kanskje se at vi nå bare har flyttet problemet et steg lenger. Hvordan vet vi at offentlig nøkkel B fra CA sitt sertifikat faktisk tilhører CA? Svaret her er rett og slett “Fordi vi har bestemt det”.

Hvordan har vi bestemt det? Ved å distribuere et sett med offentlige nøkler (sertifkater) med en enhet, et operativsystem eller en programvare som etablerer et toppnivå av tillit. Disse er ofte omtalt som rotsertifikater (eller root certificates). Hvis et sertifikat man støter på skal regnes som gyldig og stoles på må det være signert av et av disse sertifikatene eller dets barn, barnebarn, oldebarn++. Som vi så over kan et sertifikat signere et annet sertifikat og dette kan foregå i et vilkårlig antall steg opp til et av disse rotsertifikatene. Så lenge alle mellomledd i kjeden er tilgjengelig vil man kunne fastlå en såkalt “chain of trust” eller tillitskjede.

Denne tilliten forutsetter at et par ting overholdes strengt

• En CA må vite at sertifikateier er den de utgir seg for. Eksempelvis må de validere at om noen påstår de er eier av kongehuset.no så er de faktisk det
• Et rotsertifikat (eller andre sertifikater fra en CA) sin private nøkkel er ekstremt sensitiv informasjon og potensielt katastrofal at kommer på avveie. Det finnes mekanismer for å revokere sertifikater, men disse er tidvis kompliserte og vil for eksempel ikke fungere for systemer uten nettilgang

Det finnes i dag et fåtall såkalte “root programs” som administrerer hvilke CA-er som har tillit nok til å distribueres ut til sluttbrukere. Disse administreres av noen veldig få aktører - i praksis Microsoft, Apple og Mozilla. Av disse er Mozilla (de som står bak nettleseren Firefox) sitt program åpen kildekode og i praksis brukt av mange linuxdistribusjoner og andre som trenger en kilde til pålitelige rotsertifikater å distribuere.

Hjemmesnekret CA

En person, organisasjon eller til og med et land kan være sin egen CA. Man vil da introdusere sitt eget rotsertifikat ut tjenester eller enheter. For en bedrift er det en flott måte å sikre kommunikasjon mellom enheter eller tjenester, mens det for et land typisk gir autoritære stater mulighet til å avlytte datatrafikk (fordi man vil kunne utstede et sertifikat til seg selv der man påstår å være en hvilken som helst aktør).

Som mye annet er dette potensielt nyttig, men ekstremt sårbart om man ikke behandler privatnøklene som den sensitive informasjonen de er.

Kort om sertifikater som feiler

Sertifikater er ofte årsak til til at ting feiler. Grunnen til det er at problemer med sertifikater ofte manifesterer seg ved at én part nekter å prate med den andre. Det kan være en brukers nettleser som nekter å kommunisere med en webserver eller det kan være en tjeneste som nekter å koble seg til en annen.

I tillegg er sertifikater litt ekstra utsatt for å feile helt uten at noen har endret noe. Altså kan noe som har fungert - potensielt i årevis - plutselig begynne å feile. Og selv om feilen er hos oss, kan selve feilingen skje utelukkende for tredjeparter. En tjeneste kan fint kjøre og presentere et ugyldig sertifikat og være lykkelig uvitende om dette. Når feilen først er identifisert kan det også potensielt ta noe tid å få fikset dette i form av nye sertifikat da disse potensielt må utstedes eller signeres av en CA.

Andre ting som gjør sertifikaterfeil litt ekstra vanskelige å håndtere

• Feilene kan oppstå på tjenester for første gang på noen år og dermed kreve at man setter seg inn i ting helt på nytt
• Når ting feiler feiler de hardt og ting er ofte 100% utilgjengelig. Det legger ofte tidspress på feilrettingen for opprettholdelse av SLA og oppetid
• Den private nøkkelen til et sertifikat er svært sensitiv informasjon man må passe på å håndtere riktig

Under følger typiske måter sertifikater kan slutte å fungere på i sånn ca sannsynlig rekkefølge for at feilen forekommer.

Utløpt gyldighet

Sertifikater har en gitt periode det skal regnes som gyldig. Det har med andre ord en utløpsdato. Dette er den klart vanligste “feilen”. Det er jo i og for seg ikke en feil, men det medfører ofte feil når man misser en frist og ikke har rotert sertifikatet i god tid.

Revokert sertifikat

Et sertifikat kan revokeres. Det vil si at man flagger at dette sertifikatet skal ikke lenger stoles på. Det finnes litt ulike mekanismer for dette, men det trigges av en manuell prosess. Likevel, om sertifikatet ikke er tatt ut av produksjon før dette vil ting begynne å feile.

Endringer i programvare som benytter sertifikater

Kryptografi er som ellers i bransjen et domene som beveger seg fremover. Fra tid til annen slår man fast at algoritmer eller metoder som var gode nok før ikke lenger bør regnes som sikre nok. Da hender det at kryptografibiblioteker som brukes av tjenester, operativsystemer eller andre får nye krav til hva slags typer sertifikater de velger å godta. Som regel er denne prosessen treg nok til at sertifikater utstedt fra en CA rekker å løpe ut og måtte fornyes med ny teknologi i god tid før det blir et problem.

Problemer oppstår oftere når man ved bruk av en egen CA har utstedt sertifikater med veldig lang varighet (tenk 5+ år). Da kan en tilsynelatende harmløs oppdatering av et bibliotek potensielt nekte å godta sertifikater til andre tjenester. Eller en oppdatering til en utviklers maskin eller nettleser kan gjøre at man ikke lenger får tilgang til ressurser i et testmiljø.

Revokert utsteder (CA)

I noen ekstreme tilfeller har en CA som er med i et av rotprogrammene nevnt over vist seg uskikket til tilliten det innebærer. Enten grunnnet enkelte sikkerhetshendelser, eller på grunn av mindre overtramp over tid. Da kan de ende opp med at deres rotsertifikat blir fjernet fra brukeres enheter eller nettleser med det resultat at alle sertifikater som er signert “nedadgående” fra dette rotsertifikatet blir regnet som ugyldige.

Dette skjer heldigvis sjelden, og de gangene det gjøres forsøker man gjøre det så smertefritt som mulig, men det blir som regel ganske kaotisk for de som treffes av dette.

Tiltak mot feil

• Overvåk sertifikatutløp og vær ute i god tid
• Automatiser sertifikatrullering om mulig²
• Ha kontroll på private nøkler
• Vær påpasselig med bruk av egen CA
• Bruk nye algoritmer og standarder om mulig ved utstedelse av langtlevende sertifikater

Trivia om sertifikater du ikke visste du lurte på

Om du har kommet helt hit så kan du trygt slutte å lese. Under følger litt bonusinformasjon for de som er ekstra nysgjerrige på tema.

Forskjellige typer sertifikat

Rundt regnet finnes det tre typer sertifikater som kan utstedes av en CA. Disse sier noe om graden av verifisering involvert når man skal skal si hvem sertifikatet er utstedt til.

Domeneverifisering (DV)

Ved utstedelse av et domeneverifisert sertifikat har eier av et domene klart å bevise ovenfor en CA at hen kontrollerer domenet som sertifikatet utstedes til. Dette kan for eksempel gjøres ved å påvise kontroll over domenets DNS-oppføringer. Denne formen for sertifikat er 99% av alle sertifikat man støter på som vanlig forbruker der ute - blant annet alt utstedt av Let’s Encrypt.

Organisasjonsverifisering (OV)

Det er tilsynelatende litt ymse definisjoner, men for vår bruk (her i Norge) kan vi sette likhetstegn til såkalte Virksomhetssertifikater. Det er sertifikater som utstedes en virksomhet (med et organisasjonsnummer i Br.reg). Disse sertifikatene brukes mye i autentisering av en bedrift eller virksomhet i tilfeller der det skal integreres med tjenester - spesielt det som omfatter det offentlige. Virksomhetssertifikater i Norge utstedes av Buypass og Comfides, og rotsertifikatene som benyttes er ikke del av etablerte rotprogrammer. De må derfor legges til på lik linje med sertifikater fra en egen CA.

Utvidet verifisering (EV)

Sertifikater med utvidet verifisering setter høyere krav til stegene en CA må foreta seg for å bekrefte en aktørs juridiske eierskap til et domene, fysiske tilstedeværelse og eksistens innenfor en jurisdiksjon. Det er også færre CA-er med rett til å utstede denne typen sertifikater.

EV sertifikater hadde sin storhetstid i perioden der nettlesere hadde ganske tydelige visuelle skiller og indikatorer på nettsider som brukte disse. De ble tatt i bruk av banker og andre aktører som hadde ekstra ønske om å fremstå legitime og seriøse. Nettleserne har gått bort ifra disse indikatorene og nytten kan sies å ha tapt seg noe.

Idéen var i utgangspunktet god, men grunnet en del potensielle smutthull, lite dokumentert effekt på brukeres oppførsel (i en nettleser), samt ganske stive priser som hindret utbredelse så er det i praksis ikke all verdens å hente på bruk av disse sertifikatene lenger.

Revokeringsmekanismer

Revokering eller ugyldiggjøring av et sertifikat før utløpsdato er en essensiell sikkerhetsmekanisme for sikker bruk av sertifikater. Det kan være nødvendig for eksempel om private nøkler havner på avveie for å forhindre at aktører kan utgi seg for å være noen de ikke er.

Det finnes et knippe standard måter å gjøre dette på.

CRL

Certificate revocation list er liste(r) som en CA vedlikeholder med alle sertifikater de har utstedt som har blitt revokert. Ulempen ved disse er at listene kan bli ganske store og kreve både lagringsplass og båndbredde.

OCSP

Online Certificate Status Protocol er endepunkter som CA-er vedlikeholder der det er mulig å spørre om revokeringsstatusen til et enkelt sertifikat. Fordelen er at man målrettet kan sjekke enkeltsertifikaters gyldighet, mens ulempene er at det potensielt må gjøres mange enkeltkall for å sjekke mange sertifikater, med dertilhørende ventetid for sluttbrukere, samt at det potensielt har personvernskonsekvenser ved å etterlate seg eksplisitte spor om hvilke nettsider (sertifikater) en bruker benytter seg av.

CRLite

Forfatter bekjent ikke særlig utbredt per i dag, men spennende å lese om.

Failmode

Begge mekanismene krever at man tar stilling til hvordan man håndterer utilgjengelighet av henholdsvis CRL-ene og OCSP-endepunktene. En aktør som har fått hendene i en privat nøkkel kan for eksempel utvide perioden de får misbrukt denne ved å gjennomføre et tjenestenektangrep ((D)DoS) som gjør at klienter ikke får sjekket sertifikatets gyldighet. Da bør klienten velge å ikke akseptere sertifikatet før gyldigheten er fastslått. I praksis er det likevel langt vanligere at disse blir gjort utilgjengelige av mer eller mindre uskyldige årsaker og da er ulempen ved å ikke akseptere et sertifikat unødvendig høy.

Dette omtales ofte som “fail hard” eller “fail soft”.

Kryssignering

Kryssignering åpner for at et sertifikat i en kjede kan “dekkes” av mer enn et rotsertifikat. Les mer her.