Anvendelser af certifikater

Transport Layer Security (TLS)

Hvilke to spørgsmål skal en klient stille, når den modtager et certifikat fra en server?

1. Er certifikatet gyldigt og betroet? Klienten skal verificere, at certifikatet er udstedt af en betroet certifikatmyndighed (CA), og at det hverken er udløbet eller tilbagekaldt. Det indebærer at kontrollere certifikatets gyldighedsperiode og at sikre, at det er signeret af en CA, som klienten har tillid til.
2. Stemmer certifikatet overens med serverens identitet? Klienten skal sikre, at oplysningerne i certifikatet, for eksempel Common Name (CN) eller Subject Alternative Name (SAN), svarer til serverens domænenavn. Det er med til at bekræfte, at certifikatet rent faktisk er tiltænkt den server, klienten forsøger at forbinde til.

Hvordan validerer klienten, at et certifikat kan betros?

1. Kontroller certifikaternes tillidskæde: Klienten verificerer certifikatkæden, der består af serverens certifikat, eventuelle mellemliggende certifikater og rodcertifikatet. Hvert certifikat i kæden skal være signeret af den næste myndighed i rækken, så kæden til sidst fører til et betroet rodcertifikat.
2. Verificer certifikatets gyldighedsperiode: Klienten kontrollerer certifikatets gyldighedsperiode for at sikre, at det hverken er udløbet eller endnu ikke gyldigt. Det indebærer at kontrollere datoerne "Not Before" og "Not After" i certifikatet.
3. Match certifikatet med serverens identitet: Klienten sikrer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Det bekræfter, at certifikatet er tiltænkt den server, klienten forbinder til.
4. Kontroller for tilbagekaldelse: Klienten kontrollerer, om certifikatet er tilbagekaldt, ved at forespørge Certificate Revocation List (CRL) eller ved at bruge Online Certificate Status Protocol (OCSP). Et tilbagekaldt certifikat er ikke længere betroet.
5. Verificer den digitale signatur: Klienten verificerer den digitale signatur på certifikatet for at sikre, at det ikke er blevet manipuleret. Det indebærer at kontrollere den kryptografiske signatur mod den udstedende CA's offentlige nøgle.

Hvordan validerer klienten, at serveren rent faktisk ejer certifikatet?

1. Verifikation af certifikatkæden: Klienten verificerer certifikatkæden og sikrer, at hvert certifikat i kæden er signeret af en betroet certifikatmyndighed (CA). Kæden starter ved serverens certifikat og slutter ved et betroet rodcertifikat.
2. Match af domænenavn: Klienten kontrollerer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Det sikrer, at certifikatet er tiltænkt den server, klienten forbinder til.
3. Verifikation af den digitale signatur: Klienten verificerer den digitale signatur på certifikatet med den udstedende CA's offentlige nøgle. Det sikrer, at certifikatet ikke er blevet manipuleret, og at det rent faktisk er udstedt af en betroet CA.
4. Certifikatets gyldighedsperiode: Klienten kontrollerer certifikatets gyldighedsperiode for at sikre, at det er gyldigt netop nu og ikke er udløbet.
5. Kontrol af tilbagekaldelsesstatus: Klienten kontrollerer, om certifikatet er tilbagekaldt, ved at forespørge Certificate Revocation List (CRL) eller ved at bruge Online Certificate Status Protocol (OCSP). Et tilbagekaldt certifikat er ikke længere betroet.

Hvorfor er ejerskab vigtigt, når du allerede har kontrolleret, at certifikatet er betroet?

Certifikatets gyldighed og tillid: Dette trin sikrer, at certifikatet er udstedt af en betroet certifikatmyndighed (CA), at det er inden for sin gyldighedsperiode, og at det ikke er tilbagekaldt. Det bekræfter, at certifikatet er legitimt og ikke er blevet manipuleret.

Verifikation af serverens identitet: Selv hvis et certifikat er gyldigt og betroet, skal det også bekræftes, at det tilhører den server, du forbinder til. Det indebærer at kontrollere, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn. Trinnet sikrer, at certifikatet er tiltænkt den konkrete server, og det forhindrer man-in-the-middle-angreb, hvor en angriber kan fremvise et gyldigt certifikat til et andet domæne.

Hvilke to metoder bruger klienten til at besvare spørgsmålet, og hvilke to resultater kan hver metode give?

1. Verifikation via Domain Name System (DNS): Klienten kontrollerer, at certifikatets Common Name (CN) eller Subject Alternative Name (SAN) svarer til serverens domænenavn.
   Resultat:
   • Match: Hvis navnene stemmer overens, kan klienten fortsætte med forbindelsen i tillid til, at certifikatet er tiltænkt serveren.
   • Uoverensstemmelse: Hvis navnene ikke stemmer overens, afbryder klienten sandsynligvis forbindelsen eller viser en advarsel om en mulig sikkerhedsrisiko.
2. Verifikation via Public Key Infrastructure (PKI): Klienten verificerer den digitale signatur på certifikatet med den udstedende certifikatmyndigheds (CA) offentlige nøgle.
   Resultat:
   • Gyldig signatur: Hvis signaturen er gyldig, bekræfter det, at certifikatet ikke er blevet manipuleret, og at det er udstedt af en betroet CA.
   • Ugyldig signatur: Hvis signaturen er ugyldig, afbryder klienten forbindelsen eller viser en advarsel om, at certifikatet kan være kompromitteret eller forfalsket.

Hvad afgør, hvilken metode der bruges?

Verifikation via Domain Name System (DNS):

• Anvendelse: Metoden bruges altid som en del af TLS-handshaket. Klienten kontrollerer certifikatets Common Name (CN) eller Subject Alternative Name (SAN) mod serverens domænenavn for at sikre, at de stemmer overens.
• Afgørende faktorer: Det er en fast del af TLS-protokollen, og klienten udfører det automatisk, når en sikker forbindelse oprettes.

Verifikation via Public Key Infrastructure (PKI):

• Anvendelse: Metoden bruges også altid under TLS-handshaket. Klienten verificerer den digitale signatur på certifikatet med den udstedende certifikatmyndigheds (CA) offentlige nøgle.
• Afgørende faktorer: Det er endnu en fast del af TLS-protokollen. Klienten udfører automatisk kontrollen for at sikre, at certifikatet er gyldigt og ikke er blevet manipuleret.

Hvilke certifikater skal serveren sende til klienten?

Under TLS-handshaket bør serveren sende følgende certifikater til klienten:

• Slutentitetscertifikatet: Det er serverens eget certifikat, som beviser dens identitet over for klienten.
• Mellemliggende certifikater: Certifikaterne forbinder slutentitetscertifikatet med det betroede rodcertifikat. De er med til at etablere en tillidskæde fra serverens certifikat tilbage til et betroet rodcertifikat.

Hvad er Domain Validation- og Extended Validation-certifikater?

Domain Validation-certifikater (DV) er en type TLS-certifikat, hvor certifikatmyndigheden (CA) verificerer, at ansøgeren har kontrol over domænet. Det sker typisk ved at:

• Svare på en e-mail sendt til domænets administrative kontakt.
• Tilføje en DNS TXT-post.
• Uploade en fil til webserveren.

Vigtigste kendetegn:

• Hurtig udstedelse: De kan udstedes hurtigt, ofte i løbet af minutter, fordi de kræver minimal validering.
• Grundlæggende sikkerhed: De giver kryptering og en grundlæggende sikkerhed for, at domænet kontrolleres af den enhed, der anmoder om certifikatet.
• God økonomi: De er ofte billigere eller helt gratis, og det gør dem tilgængelige for små websteder og private projekter.

Extended Validation-certifikater (EV) er en højere klasse af TLS-certifikater, der kræver en mere grundig valideringsproces. CA'en verificerer den juridiske, fysiske og operationelle eksistens af den enhed, der anmoder om certifikatet. Det omfatter at:

• Bekræfte enhedens juridiske identitet og status.
• Verificere enhedens fysiske og operationelle tilstedeværelse.
• Sikre, at enheden har eneret til at bruge domænet.

Vigtigste kendetegn:

• Høj sikkerhed: Giver brugerne den højeste grad af tillid og sikkerhed, fordi processen indebærer en grundig kontrol.
• Synlige indikatorer: I nogle browsere viste EV-certifikater tidligere organisationens navn i adresselinjen, men det er mindre udbredt i dag.
• Styrket tillid: Ideel til websteder, der håndterer følsomme oplysninger, for eksempel finansielle institutioner og e-handelssteder.

Hvilke er mest sikre?

Extended Validation-certifikater (EV) anses generelt for mere sikre end Domain Validation-certifikater (DV) på grund af den grundige valideringsproces, de gennemgår. Her er en sammenligning:

Domain Validation-certifikater (DV)

• Valideringsniveau: Verificerer kun kontrol over domænet.
• Sikkerhed: Giver grundlæggende kryptering og sikkerhed.
• Anvendelse: Egner sig til private websteder, blogs og små virksomheder.

Extended Validation-certifikater (EV)

• Valideringsniveau: Verificerer den juridiske, fysiske og operationelle eksistens af enheden.
• Sikkerhed: Giver en højere grad af tillid og sikkerhed på grund af den grundige kontrol.
• Anvendelse: Ideel til finansielle institutioner, e-handelssteder og alle websteder, der håndterer følsomme oplysninger.

Derfor er EV-certifikater mere sikre:

• Grundig kontrol: EV-certifikater kræver omfattende validering, og det gør det sværere for ondsindede aktører at få fat i dem.
• Tillidsindikatorer: Selvom det er mindre udbredt i dag, viste EV-certifikater tidligere organisationens navn i browserens adresselinje og gav dermed brugerne en synlig bekræftelse.
• Højere sikkerhed: Den detaljerede verifikationsproces sikrer, at den enhed, der står bag certifikatet, er legitim, og det mindsker risikoen for phishing og andre angreb.

Hvordan foregår tilbagekaldelse med OCSP Stapling

OCSP stapling forbedrer den almindelige OCSP-proces ved at reducere svartiden og styrke privatlivets fred. Sådan fungerer det:

1. Serveren anmoder om et OCSP-svar: Webserveren anmoder med jævne mellemrum OCSP-responderen, en server, der drives af certifikatmyndigheden (CA), om tilbagekaldelsesstatus for sit certifikat. Anmodningen sker i baggrunden og ikke ved hver enkelt klientforbindelse.
2. OCSP-responderen leverer et svar: OCSP-responderen sender et signeret OCSP-svar med tidsstempel tilbage med certifikatets status, for eksempel "good", "revoked" eller "unknown". Serveren cacher svaret.
3. TLS-handshake med et staplet svar: Når en klient, for eksempel en webbrowser, opretter en forbindelse til serveren, medsender serveren det cachede OCSP-svar i TLS-handshaket. Det kaldes at "staple" svaret til handshaket.
4. Klienten verificerer OCSP-svaret: Klienten verificerer det staplede OCSP-svar. Da svaret er signeret af CA'en, kan klienten stole på dets gyldighed. Hvis svaret viser, at certifikatet er tilbagekaldt, opretter klienten ikke en sikker forbindelse.
5. Løbende opdateringer: Serveren opdaterer fortsat sit cachede OCSP-svar med jævne mellemrum, så den altid har en aktuel status at levere under TLS-handshaket.

Processen mindsker behovet for, at klienter skal sende separate OCSP-anmodninger, og det forbedrer både ydelsen og privatlivets fred.