Viktige dataformater

X.509

X.509 er selve standarden for digitale sertifikater. Det fantes tidligere konkurrenter som OpenPGP, men de brukes langt sjeldnere i dag. Men vent litt: X.509 er egentlig ikke den riktige standarden. X.509 er faktisk en ITU-T-standard, mens definisjonene som virkelig betyr noe, er en del av RFC 5280, altså en standard fra IETF og ikke fra ITU-T. RFC-en definerer «PKI-profilen for internett» basert på X.509, og det er den eneste profilen som har reell betydning i praksis.

Et digitalt sertifikat bruker asymmetrisk kryptografi og særlig digitale signaturer. Det vanligste bruksområdet for digitale sertifikater i dag er serverautentisering. Alle har brukt dem allerede, sannsynligvis uten å vite at det dreide seg om et X.509-sertifikat: Hver gang du åpner et HTTPS-nettsted, oppretter nettleseren en TLS-forbindelse til webserveren. Webserveren bruker et X.509-sertifikat til å bevise hvem den er. Når folk går inn på nettsiden til banken sin for å overføre penger fra kontoen, vil de være sikre på at de faktisk kommuniserer med banken. Angripere kan forsøke å utgi seg for å være banknettstedet, lese brukerens passord og engangskode og så overføre pengene til en konto de selv kontrollerer. HTTPS bidrar til å hindre dette, fordi angriperne ikke har X.509-sertifikatet til bankens webserver. Når nettleseren sier at du besøker et bestemt domene og at forbindelsen er HTTPS, sørger sertifikatet for at du virkelig er koblet til en webserver som tilhører noen som eier det domenet.

Hvordan får sertifikatet dette til? Sertifikatet inneholder noen metadata, den offentlige nøkkelen i et kryptografisk nøkkelpar og en signatur fra en sertifikatmyndighet. La oss gå gjennom de tre delene:

Innholdet i et X.509-sertifikat

Metadata

Metadataene i X.509-sertifikatet angir blant annet hvilket tidsrom det er gyldig i, hva sertifikatet skal brukes til, og hvem det ble utstedt til. For et TLS-serversertifikat inneholder de særlig domenet til webserveren. Nettleseren sammenligner domenet den forsøkte å åpne, med domenet i sertifikatet. Stemmer de ikke overens, går ikke nettleseren videre, men viser en advarsel. Har sertifikatet utløpt, viser den også en advarsel.

Merkelig nok viste nettlesere ofte ingen advarsel hvis du åpnet et HTTP-nettsted uten TLS, selv om det er enda mindre sikkert. Åpnet du en webserver med et ugyldig X.509-sertifikat, kunne det rett og slett være en feilkonfigurasjon, og du kunne faktisk være beskyttet mot angripere som spionerer på forbindelsen, mens HTTP-forbindelsen ikke gir noen beskyttelse i det hele tatt.

Det finnes likevel framgang på dette området, for eksempel Certificate Pinning. Men det er et avansert tema, så la oss se på de to andre tingene som finnes i et X.509-sertifikat.

Offentlig nøkkel

Sertifikatet inneholder den offentlige delen av et asymmetrisk nøkkelpar. Kryptografien gjør at webserveren, eller mer generelt sertifikatinnehaveren i andre bruksområder, kan bevise at den også har den private delen av nøkkelparet uten å avsløre den for klienten som kobler seg til, eller for andre. Dermed kan klienten være sikker på at webserveren faktisk eier sertifikatet og ikke bare har kopiert det. Å kopiere selve sertifikatet er ganske enkelt, siden webserveren sender en kopi av det til alle som forsøker å koble seg til serveren. Å stjele den private nøkkelen er vanskelig eller umulig, siden den aldri forlater webserveren. Det finnes ulike metoder for å gjøre tyveri av den private nøkkelen vanskeligere, for eksempel HSM-er og TPM-er.

Signatur fra en sertifikatmyndighet

Metadataene lar klienten kontrollere at sertifikatet passer til det aktuelle bruksområdet. Den offentlige nøkkelen viser at motparten faktisk eier sertifikatet. Men en angriper kan jo bare opprette et nytt nøkkelpar og et nytt sertifikat som også oppfyller disse to kriteriene. Hvordan skal en klient vite at sertifikatet er til å stole på?

Sertifikatet inneholder en kryptografisk signatur fra et annet nøkkelpar som hører til et sertifikat for en sertifikatmyndighet (CA). CA-sertifikatet kan kontrolleres på samme måte og er også signert av et sertifikat. Klienten kan følge denne tillitskjeden fra det såkalte bladsertifikatet helt opp til rot-CA-sertifikatet, som den kjenner igjen på at det er selvsignert, altså at signaturen i sertifikatet kommer fra sertifikatets eget nøkkelpar. Vanligvis er dette bare ett eller to trinn, så det er bare ett eller to CA-sertifikater involvert.

CA-er må kontrollere nøye at metadataene er riktige når de utsteder et sertifikat. Vil du for eksempel ha et TLS-serversertifikat for ditt eget domene, må du bevise overfor CA-en at du virkelig eier det. Hvor grundig denne kontrollen er, avgjør om du får et vanlig sertifikat eller et Extended Validation-sertifikat (EV).

Hver nettleser og hvert operativsystem leveres med en liste over forhåndsdefinerte betrodde rot-CA-er. Brukere og administratorer kan legge til flere betrodde rot-CA-er. Noen rot-CA-er er bare betrodd for bestemte formål, andre har en mer generell tillit. Klienten kontrollerer om tillitskjeden ender i en betrodd rot-CA. Gjør den det, og alle sertifikatene i tillitskjeden fortsatt er gyldige og metadataene sier at de brukes i tråd med formålet sitt, er bladsertifikatet til webserveren betrodd, og forbindelsen opprettes.

Gyldigheten til X.509-sertifikater

X.509-sertifikater handler helt og holdent om tillit som må etableres. Som forklart er ett kriterium for tillit at et sertifikat må kjede seg opp til en betrodd rot-CA. Et annet er at det er innenfor gyldighetsperioden sin. Vanligvis betyr det at det ikke er utløpt, men et sertifikat kan også være ennå ikke gyldig, som regel på grunn av tekniske feil. Og det finnes ett kriterium til: CA-en som utstedte sertifikatet, må ikke ha tilbakekalt det. Fordi dette er et tema for seg, har vi en egen artikkel om det.

PKCS#7

PKCS#7 er den sveitsiske lommekniven blant kryptografiske dataformater og kan inneholde omtrent hva som helst: krypterte meldinger, signerte meldinger, signerte og krypterte meldinger, sertifikater og private nøkler

Dette er samtidig den største ulempen med formatet. Får en applikasjon eller en bruker en PKCS#7, er det ikke uten videre klart hva som skal gjøres med den. Her er noen viktige bruksområder:

• S/MIME-meldinger er i bunn og grunn e-poster med PKCS#7-innhold eller PKCS#7-vedlegg.
• SCEP-forespørsler og SCEP-svar er i praksis begge signerte PKCS#7-meldinger.
• EST-svar er CMS-meldinger.

Koding

Vanlige filendelser er .p7b (DER-kodet), .p7s (en signert melding eller en meldingssignatur) og .p7m (en signert og/eller kryptert melding). PEM-kodingen med etiketten «PKCS7» er også definert, men brukes sjelden.

Verktøy

I Windows kan du åpne PKCS#7-meldinger med et dobbeltklikk, og Crypto-shell-utvidelsene viser dem for deg. Som regel kan du likevel bare hente ut sertifikater og de private nøklene deres, ikke innholdet i meldingene.

Du kan konvertere disse filene til andre formater med verktøy som OpenSSL.

PKCS#10

En sertifikatsigneringsforespørsel (CSR) slik den er definert i PKCS#10, er en fil som beskriver et sertifikat du gjerne vil få fra en sertifikatmyndighet (CA). Den har en struktur som ligner på et X.509-sertifikat, men den mangler signaturen fra en CA. I stedet inneholder den signaturen til den som ber om sertifikatet. Det er fortsatt et annet format, så den er ikke det samme som et selvsignert sertifikat.

Den kan være binært DER-kodet eller PEM-kodet med etiketten «CERTIFICATE REQUEST».

PKCS#12

PKCS#12 er også kjent som PFX, særlig i Windows-miljøer. Vanlige filendelser er derfor .pfx og .p12. Formatet inneholder X.509-sertifikater og nesten alltid tilhørende private nøkler, selv om det strengt tatt ikke er teknisk påkrevd.

Data i en PKCS#12-fil er vanligvis kryptert med passord. Ofte er bare den private nøkkelen kryptert, så du kan hente ut sertifikatene uten å kjenne passordene hvis applikasjonen din tillater det, og det gjør de fleste ikke. PKCS#12 er den vanligste måten å lagre et sertifikat og den private nøkkelen til det i en fil på i Windows-miljøer. I Linux-miljøer er PEM-kodede PKCS#8-filer vanligere.

Fordi standarden gir mange valg for hvordan sertifikater og private nøkler kan lagres i nøstede «safebags», har PKCS#12-filer visse kompatibilitetsproblemer, blant annet:

• Windows er beryktet for å knytte private nøkler i PKCS#12 til alle sertifikatene som hentes ut av filen, ikke bare til det sertifikatet nøkkelen hører til. Inneholder PKCS#12-filen en sertifikatkjede, kan Windows vise at den har den private nøkkelen til CA-sertifikatet.
• På macOS kan du ikke importere PKCS#12-filer hvis de kryptografiske algoritmene er for nye.
• Det kan være nødvendig å kryptere sertifikatene i en PKCS#12-fil for at mottakerapplikasjonene skal kunne hente dem ut. Men noen støtter bare svært gamle og svake algoritmer, og det er vanligvis ikke noe problem, siden informasjonen uansett er offentlig. OpenSSL 3.x støtter derimot ikke disse gamle og sårbare algoritmene og nekter å åpne PKCS#12-filen.

ASN.1 og PEM

Abstract Syntax Notation One (ASN.1) er et språk som brukes til å beskrive datastrukturer. Det finnes noen forhåndsdefinerte grunnleggende datatyper, for eksempel heltall eller sekvenser, og den som lager en protokoll eller et filformat, kan deretter definere egne datatyper med utgangspunkt i de grunnleggende.

DER-koding

ITU-T-standarden X.680 definerer ulike kodinger for data som er angitt som ASN.1. For X.509-relaterte data er DER den viktigste kodingen, fordi det bare finnes én måte å kode en type på. En hashverdi av den binære DER-representasjonen av typen vil derfor alltid ha samme verdi, noe som er viktig for eksempel ved signering av ASN.1-kodede data.

PEM-koding

For mange, men ikke alle, X.509-relaterte filtyper kan du enten lagre filen binært i DER-koding eller legge en ekstra PEM-koding oppå DER-kodingen. PEM bruker bare ASCII-tegn og kan derfor enkelt kopieres og limes inn via utklippstavlen, eller sendes på e-post, slik det var relevant for noen tiår siden.

Verktøy

Har du en ASN.1-kodet fil og enten ikke vet hvilken type det er, eller mangler en applikasjon som håndterer nettopp den typen, kan du likevel dekode den rå ASN.1-strukturen og se hva den inneholder. I Windows kan det innebygde verktøyet certutil gjøre dette med kommandoen certutil -decode.