Digitale sertifikater brukes for å bekrefte identitet. Ofte skilles det mellom å identifisere seg, og det å bekrefte sin identitet, og i denne sammenheng menes da bekreftelse av identitet. Det man ønsker er selvsagt å bekrefte handlinger til fysiske personer, eller f.eks. virksomheter, mens det i praksis alltid vil være datamaskiner som besitter tilgangsparametere (nøkler) og som utfører verifikasjonsprosedyrene. Selv med smartkort og fingeravtrykklesere.

Identifisering kan være både én-veis og to-veis. En-veis er mest vanlig på det åpne Internett, typisk i den hensikt at du som nettsurfer kan stole på at nettsteder du besøker, og programvare du installerer kommer fra en pålitelig kilde. Uten slik verifikasjon er det trivielt for uvedkommende å utgi seg for å være en annen, f.eks. banken din. To-veis verifikasjon er i prinsippet bare to instanser av en-veis identifisering, en i hver retning, og brukes ofte i forbindelse med fjernpålogging. Enten som et supplement, eller erstatning for brukernavn/passord. Autorisasjon er et relatert begrep til identifikasjon. Kort fortalt handler autorisasjon om hva du skal få lov til å gjøre, når identiteten din først er bekreftet. Men det er et annet tema.

Såkalt Extended Validation (EV) sertifikat på banksiden og en operativsystemdriver uten gyldig signatur.

For å forstå digitale sertifikater må vi først forklare kryptografi med såkalt privat-offentlig nøkkelpar. Også kjent som asymmetrisk kryptografi. Kryptografi er enkelt forklart teknikker for å gjøre informasjon helt uforståelig, men på en slik måte at de som kjenner til en hemmelighet likevel er i stand til å forstå innholdet. For eksempel en tekst eller et bilde. Motstykket til asymmetrisk kryptografi er symmetrisk kryptografi. Der brukes samme nøkkel i prosessen med å "stokke om på" og "sette sammen" det opprinnelige budskapet. Symmetrisk kryptografi er relevant i denne sammenheng grunnet ytelse. Etter at identitet er bekreftet, utveksles typisk nøkler for en symmetrisk kryptoalgoritme, som så i tur beskytter resten av samtalen.

Tilbake til privat-offentlige nøkkelpar. Her er prinsippet at to forskjellige nøkler brukes henholdsvis for å "stokke om på" og "sette sammen" en mengde informasjon. To kjente slike algoritmer er ECC og RSA. Den ene nøkkelen er privat og må holdes hemmelig. Den andre er offentlig og kan deles fritt. Det den private nøkkelen brukes for å kryptere, kan den offentlig dekryptere (reversere). Tilsvarende dersom den offentlige brukes for å kryptere. Da kan bare den private nøkkelen brukes for å dekryptere. En nøkkel i denne sammenheng er et antall tilfeldige 1-ere og 0-ere, og lengden varierer fra rundt 100 til flere tusen slike «bit».

1) Sende hemmelig informasjon til bare Ole. 2) Bekrefte at Ole er forfatter (forenklet illustrasjon uten hash-funksjoner)

Dette har noen interessante egenskaper: De som kjenner din offentlige nøkkel kan sende deg noe bare du er i stand til å se. Dette ved å kryptere den med din offentlige nøkkel. I tillegg kan du som besitter den private nøkkelen "signere" noe, for eksempel en e-post, slik at alle med din offentlige nøkkel kan verifisere at det faktisk er du som sendte den. Men vi har fortsatt et problem: hvordan vet jeg at den offentlige nøkkelen jeg har som påstår at den er fra deg, faktisk tilhører den private nøkkelen du har laget og holder skjult? Her kommer digitale sertifikater og offentlig nøkkeldistribusjon (PKI) inn i bildet.

Et sertifikat er enkelt forklart en offentlig nøkkel og en identitet, pakket sammen. Det legges på en del metadata som bruksområde og gyldighet, og så signeres hele pakken av en tiltrodd tredjepart. Denne signeringen skjer da selvsagt med tredjepartens private nøkkel. Tilliten til systemet er altså fundert på disse tredjepartene. Disse tredjepartene har såkalte "selvsignerte" sertifikat, også kalt root-sertifikat. Disse består av den offentlige nøkkelen til "tredjeparten", signert med den tilsvarende private nøkkelen. Root-sertifikater fra sertifikatutstedere (Certificate Authorities, CA) ligger forhåndsinstallert i våre operativsystem og nettlesere. De oppdateres kontinuerlig. Det er ganske mange av dem, fra alle verdens hjørner. De er 100% avhengig av tillit i markedet, og det er eksempler på leverandører som er sperret ut fra de store plattformene grunnet dårlig hendelsehåndtering. I praksis, og for å minimere konsekvens av en kompromittert privat nøkkel, finnes det mange mellomutstedere (intermediate CA), ofte i flere ledd. Sertifikatutsteder signerer da første mellomutsteder. Første mellomutsteder signerer andre mellomutsteder... og siste mellomutsteder signerer et sertifikat som bekrefter identitet på et webområde, en utvikler, en person eller tilsvarende.

Gyldighet, informasjon om signatureier, den offentlige nøkkelen samt utstederhierarkiet. Verifisert av nettleseren.

Det er selvsagt ikke nødvendig å bruke slik offentlig nøkkeldistribusjon, og for visse skjermingsverdige systemer er det anbefalt å ha egen nøkkelproduksjon og distribusjon. I praksis betyr det bare at root-sertifikat også må distribueres internt, da de ikke vil eksistere i kommersielle produkter. Dette er forsåvidt også en utfordring for systemer som av en eller annen grunn ikke får oppdatert root-sertifikatlagret automatisk over Internett.

Transport Layer Security (TLS), tidligere Secure Socket Layer (SSL) er en teknologi som ved hjelp av sertifikater utfører identitetsverifikasjonen, samt etablering av en kryptert kanal for overføring mellom to parter. For eksempel når du besøker en webside over sikker HTTP (https). Designet til SSL/TLS-protokollen er bygget rundt antakelsen at uvedkommende sitter mellom A og B, og er i stand til både å lytte og manipulere alt som blir kommunisert mellom A og B. Denne "uvedkommende" er en såkalt "man-in-the-middle" (noen foretrekker person-in-the-middle for å være kjønnsnøytrale). Stegene i prosessen handler om utveksling av sertifikater og valg av nøkler for kryptering av den nyopprettede samtalen. I tillegg brukes metoder for å kunne oppdage om noe har blitt endret underveis. Det er mange alternative algoritmer for kryptering og nøkkelutveksling. Det er funnet sårbarheter i de eldste, samtidig som at gammelt utstyr ikke støtter nye algoritmer. Det vil derfor være en prosess for å bestemme det høyeste sikkerhetsnivået begge parter støtter. Her er det særlig viktig at ikke uvedkommende skal kunne manipulere denne prosessen, slik at et lavt sikkerhetsnivå blir valgt.

Måten sesjonsnøkler blir valgt ut på er også viktig. Det vil si de nøklene som skal brukes til den symmetriske krypteringsprosessen for gjeldende samtale (ytelse). Det vi ønsker er såkalt "Perfect Forward Secrecy". Opprinnelig ble en nøkkel "valgt ut" av den ene parten, og sendt til motparten kryptert med motpartens offentlige nøkkel. Problemet med denne måten å gjøre det på, er at dersom motpartens private nøkkel en gang i fremtiden skulle komme på avveie, ja så vil det være mulig for en tredjepart som har tatt vare på alt som har blitt kommunisert, å rekonstruere all kryptert trafikk under denne private nøkkelen. For å unngå dette har vi matematikk som lar part A og B komme opp med hver sin del av nøkkelen, sende hverandre disse delene, og så sette sammen en felles nøkkel, uten at noen som lytter er i stand til å vite hva denne felles nøkkelen er. Algoritmen heter Diffie-Hellman, og den finnes i flere varianter. Poenget er da at bekreftelse av identitet og beskyttelse av innhold (konfidensialitet) blir adskilt. Sesjonsnøkkelen "eksisterer ikke" i samtalen. SSL-labs har en praktisk SSL/TLS test som sjekker etter kjente konfigurasjon og versjons-svakheter.

Sertifikater til websider varer typisk 1-2 år, noen ganger lenger. I prinsippet er alle sertifikat helt like. De gir alle mulighet til å kryptere med sterk kryptografi. Det som i praksis skiller dem er i hvilken grad utsteder har sjekket at du faktisk er du, før sertifikatet blir utstedet til deg. Det enkleste sertifikater for websider er domeneverifikasjon. Det eneste kravet er at du skal kunne verifisere at du har kontroll på domenet du søker sertifikat for. For eksempel vg.no. Det er vanlig at det sendes en e-post til da eksempelvis admin@vg.no, hvorfra det må aksepteres at sertifikatet signeres. I forkant har eieren av VG laget en privat og en offentlig nøkkel. Den offentlige nøkkelen sendes til sertifikatutstederen, som så legger ved at denne gjelder for vg.no, og signerer sertifikatet med sin private nøkkel. Sertifikatet installeres så på vg.no, sammen med alle mellomsertifikater i sertifikathierarkiet. Root-sertifikatet legges selvsagt ikke ved. Eneste grunnen til at en tilkoblet avissurfer (i dette tilfellet) ønsker å stole på VG sitt sertifikat, er at hele hierarkiet kan verifiseres basert på egen kopi av root-sertifikatet oppbevart lokalt.

Betaler man mer, er det mulig å få såkalte "Extended validation" sertifikat. Det innebærer en mye mer omfattende prosess der man knytter virksomheter og personer opp mot sertifikatet. Eksemplet øverst på siden fra nettleseren Chrome (skandiabanken.no) viser en grønn adresselinje, og navnet "Skandiabanken ASA [NO]" i tillegg til domenet. Tilsvarende nivåer eksisterer også for personsertifikater, men prinsippet er det samme. Altså prosessene rundt utstedelse.

Til sist et par ord om tilbakekallelse av sertifikater (revokering). Private nøkler vil før eller siden kunne komme på avveie. Eller de kan mistes. Det er derfor et behov for å kunne markere et sertifikat (med tilhørende offentlige nøkkel) som "ikke gyldig lenger". En måte dette kan skje på, er at det regelmessig sendes ut komplette lister over hvilke sertifikat som er utgåtte. Disse listene kan fort bli veldig store og uhåndterlige. Dette til tross for at de normalt bare varer 1-2 år og deretter ikke trenger å stå på noen liste lenger. En annen måte å løse dette på, er at den verifiserende part sjekker status via nettverket hver gang (OCSP). OCSP lekker informasjon til sertifikatutsteder relatert til hvilke nettsteder en bruker besøker, men det finnes et alternativ kalt "OCSP stapling" som skal løse denne utfordringen.