Hvad er SSL? Alt du skal vide om certifikater og kryptering
De fleste "hvad er SSL"-sider er skrevet af sælgere. Denne er skrevet af folk, der har arbejdet med PKI og certifikater i over 16 år.
Vi forklarer SSL/TLS i tre niveauer: fra det basale (hvad er hængelåsen?) over den tekniske mekanik (handshakes, certifikatkæder, nøgletyper) til avancerede emner for IT-professionelle (cipher suites, Certificate Transparency, trust stores, ACME). Spring til det niveau, der passer dig.
Niveau 1: Det grundlæggende
Hvad er et SSL-certifikat?
Et SSL-certifikat er en lille datafil, der installeres på en webserver. Det løser tre grundlæggende problemer:
Identitet: Er det virkelig banken?
Når du besøger www.din-bank.dk, garanterer certifikatet, at du faktisk kommunikerer med bankens server og ikke en angriber. En uafhængig certifikatudsteder (CA) har kontrolleret ejerens identitet og underskrevet certifikatet digitalt, så din browser kan stole på det.
Kryptering: Ingen kan læse med
Din browser og serveren opretter selv en krypteret forbindelse. Certifikatet laver ikke selve krypteringen, men sikrer under opsætningen, at du forhandler med den rigtige server og ikke en angriber imellem.
Når forbindelsen er oprettet, krypteres alt data. Ingen undervejs kan læse indholdet. Selv din internetudbyder kan kun se, hvilken server du besøger, ikke hvad du sender eller modtager.
Dataintegritet: Ingen kan ændre data undervejs
Hvis nogen forsøger at ændre data undervejs, opdager modtageren det øjeblikkeligt og afbryder forbindelsen. Det forhindrer angribere i at indsætte falske oplysninger eller ondsindet kode i datastrømmen mellem dig og serveren.
SSL vs TLS: Hvad er forskellen?
SSL (Secure Sockets Layer) var den originale protokol fra Netscape. Den er forældet og usikker. Alle moderne forbindelser bruger efterfølgeren TLS (Transport Layer Security). Branchen bruger stadig "SSL" som samlebetegnelse, men certifikatet er det samme uanset TLS-version.
Udviklet af Netscape. Så usikker at den aldrig blev taget i brug.
Første offentlige version. Fundamentalt usikker.
Bedre, men knækket af POODLE-angrebet (2014). Forældet.
IETF overtog udviklingen og omdøbte protokollen. Droppet af browsere i 2020.
Marginale forbedringer. Droppet af browsere i 2020.
Stadig udbredt. Sikker med korrekt konfiguration (kun ECDHE + AEAD).
Aktuel standard (RFC 8446). Fjernede alle usikre algoritmer. Hurtigere handshake. Forward secrecy som standard.
HTTP vs HTTPS
HTTP sender data i klartekst. Alle mellem dig og serveren kan læse med: internetudbydere, wifi-hotspot ejere, enhver router undervejs. HTTPS tilføjer TLS-kryptering, så data bliver ulæseligt for alle andre end afsender og modtager.
Alle moderne browsere markerer HTTP-sider som "Ikke sikker". Google bruger HTTPS som rangeringssignal, og webteknologier som HTTP/2, Service Workers og Geolocation API kræver HTTPS. Der er ingen god grund til at køre HTTP i dag.
De tre valideringstyper
Certifikater fås med forskellige niveauer af identitetsverifikation. Valideringstypen bestemmer, hvor grundigt CA'en har undersøgt dig som certifikatejer, ikke hvor stærk krypteringen er (den er ens):
Bekræfter at du kontrollerer domænet via DNS- eller HTTP-challenge. Automatisk udstedelse, typisk under 2 minutter med ACME. Billigst. Ingen virksomhedsoplysninger i certifikatet.
Bekræfter også din virksomhedsregistrering mod offentlige registre (CVR i Danmark). Virksomhedsnavnet står i certifikatets Organization-felt. FairSSL udfører OV-validering på dansk for GlobalSign, typisk under 1 time.
Strengeste verifikation med juridisk, operationel og fysisk bekræftelse. Viser virksomhedsnavn og land i certifikatet. Kræves til kodesigneringscertifikater og visse brancher.
Alle tre typer giver den samme krypteringsstyrke. Browsere viser ikke længere en grøn bjælke for EV (Chrome fjernede det i version 77, september 2019, og andre browsere fulgte efter). Virksomhedsoplysningerne er stadig i certifikatet, men brugere skal klikke på hængelåsen for at se dem.
Certifikattyper: Single Domain, Wildcard og SAN
- Single Domain: Dækker ét specifikt domæne, f.eks.
www.dit-domæne.dk. De fleste DV-certifikater inkluderer automatisk bådewwwog base-domænet som SAN (Subject Alternative Name). - Wildcard: Dækker alle subdomæner på ét niveau under et domæne, f.eks.
*.dit-domæne.dk(dækkerwww,mail,apiosv.). Dækker ikke base-domænetdit-domæne.dkselv, medmindre det er tilføjet som ekstra SAN. Dækker heller ikke dybere niveauer somsub.api.dit-domæne.dk. - Multi-Domain (SAN): Dækker en liste af specifikke navne, som kan være fra helt forskellige domæner:
dit-domæne.dk,dit-domæne.com,din-webshop.dk. Antallet af tilladte SANs varierer per produkt (typisk 25-250).
Valget afhænger af din infrastruktur. Wildcard er nemmere at administrere, men alle servere deler den samme private nøgle. Hvis én server kompromitteres, kan nøglen bruges til at udgive sig for enhver subdomæne. SAN-certifikater giver mere kontrol og kan blande domæner frit. Se vores wildcard SSL-side og multi-domain SSL-side for detaljeret sammenligning.
Niveau 2: Sådan virker det teknisk
TLS-handshake: Hvad sker der, når du åbner en HTTPS-side?
Når din browser forbinder til en HTTPS-server, udføres et TLS-handshake. I TLS 1.3 tager det én roundtrip (typisk 50-100 ms). Formålet er at aftale en krypteringsnøgle, uden at nøglen nogensinde sendes over nettet:
- 1 Client Hello. Browseren sender en liste over understøttede TLS-versioner, cipher suites og nøgleudvekslingsparametre (key shares). I TLS 1.3 sender browseren allerede sin nøgleandel i første besked, så serveren kan svare med det samme.
- 2 Server Hello + certifikat. Serveren vælger cipher suite og sender sin nøgleandel. Derefter sender serveren sit certifikat (med den offentlige nøgle og hele certifikatkæden) i en krypteret besked, beskyttet af den netop aftalte nøgle.
- 3 Certifikatverifikation. Browseren kontrollerer: er certifikatet udstedt af en betroet CA? Er det ikke udløbet? Matcher domænenavnet (i SAN-feltet)? Er det logget i Certificate Transparency? Er det tilbagekaldt? Bygger kæden korrekt op til en betroet rod?
- 4 Sessionsnøgler. Allerede i trin 1-2 udvekslede browser og server nøgleandele via Elliptic Curve Diffie-Hellman (ECDHE). Disse kombineres til en fælles hemmelighed, der bruges til at udlede sessionsnøgler. Den private nøgle sendes aldrig over nettet. Selv hvis nogen opfanger hele handshake, kan de ikke beregne sessionsnøglen.
- 5 Krypteret kommunikation. Al efterfølgende trafik krypteres med sessionsnøglen (symmetrisk kryptering, typisk AES-256-GCM eller ChaCha20-Poly1305). Symmetrisk kryptering er ordener af størrelsesgrader hurtigere end asymmetrisk.
TLS 1.3 vs 1.2: TLS 1.2 bruger to roundtrips (dobbelt latency). Den tillader også RSA key exchange (uden forward secrecy), CBC-mode ciphers (sårbare over for padding oracle-angreb) og en lang række usikre konfigurationer. TLS 1.3 fjernede alt det. Hvis din server stadig tilbyder TLS 1.0 eller 1.1, bør de deaktiveres. Alle moderne browsere har droppet support for dem.
Hvad er der inde i et certifikat? (X.509-anatomi)
Et SSL-certifikat er et X.509v3-certifikat kodet i ASN.1 DER-format (typisk Base64-indkapslet som PEM). Det indeholder:
SAN (Subject Alternative Name) er det felt, der faktisk bestemmer, hvilke domænenavne certifikatet dækker. CN (Common Name) i Subject-feltet bruges historisk, men moderne browsere ignorerer CN og bruger udelukkende SAN. Et certifikat uden SAN vil blive afvist.
Certifikatkæden: Root, intermediate og leaf
Dit SSL-certifikat (leaf-certifikatet) er en del af en tillitskæde. Browseren verificerer kæden fra dit certifikat og op til en betroet rod:
Rodcertifikater er forudinstalleret i trust stores, der vedligeholdes af fire store root-programmer: Microsoft (Windows/Edge), Apple (macOS/iOS/Safari), Mozilla (Firefox), og Google (Chrome Root Store, lanceret 2023). For at blive optaget skal CA'en bestå en WebTrust- eller ETSI-audit og overholde CA/Browser Forum Baseline Requirements.
Din server skal sende hele kæden (leaf + intermediate), men ikke rodcertifikatet (browseren har det allerede). Rækkefølgen er vigtig: leaf først, derefter intermediates i stigende rækkefølge.
Almindelig fejl: Hvis serveren kun sender leaf-certifikatet uden intermediate, kan browsere på nogle platforme ikke verificere kæden. Desktop-Chrome kan ofte selv finde det manglende intermediate (via Authority Information Access), men mobile browsere og curl/Python fejler. Kontrollér altid kæden med vores SSL Scanner.
Cross-signing i praksis: Når en CA har en ny rod, der endnu ikke er i alle trust stores, kan den cross-signe sit intermediate med en ældre, bredt betroet rod. Let's Encrypt brugte dette: deres ISRG Root X1 var cross-signet af IdenTrust DST Root CA X3 for at opnå kompatibilitet med ældre enheder. Da DST Root CA X3 udløb den 30. september 2021, brød det certifikatverifikation på ældre Android-enheder, OpenSSL 1.0.x og IoT-enheder verden over.
Nøgletyper: RSA vs ECDSA
Certifikatets nøgletype bestemmer, hvilken kryptografisk algoritme der bruges til at signere og verificere certifikatet. Der er to gængse typer:
| Egenskab | RSA | ECDSA (P-384) |
|---|---|---|
| Nøglestørrelse | 2048 eller 4096 bit | 384 bit |
| Sikkerhedsniveau | RSA 2048 ≈ 112 bit, RSA 4096 ≈ 140 bit | P-384 ≈ 192 bit |
| Handshake-hastighed | Langsom (stor nøgle, tung beregning) | Hurtig (lille nøgle, effektiv) |
| Båndbredde | Større certifikat (256-512 bytes for nøgle) | Lille certifikat (96 bytes for nøgle) |
| Kompatibilitet | Alle platforme | Alle moderne platforme (Windows Vista+, Android 4+) |
Vi anbefaler ECDSA P-384 eller RSA 3072 til nye installationer. P-384 giver hurtigere handshakes end RSA, bruger mindre båndbredde og har et sikkerhedsniveau svarende til RSA 7680 bit. P-384 er stadig så hurtigt, at den marginale hastighedsforskel til P-256 ikke retfærdiggør det lavere sikkerhedsniveau. RSA 3072 er det oplagte valg, hvis du har brug for RSA-kompatibilitet. Undgå RSA 2048, da det vil være det første der blokeres, når kravene skærpes.
Nøgletypen i certifikatet er uafhængig af TLS-forbindelsens cipher suite. Du kan have et RSA-certifikat og stadig bruge ECDHE til nøgleudveksling (og dermed forward secrecy). TLS 1.3 kræver altid ECDHE, uanset certifikattype.
Certifikatets levetid og fornyelse
Certifikater har en begrænset teknisk levetid. CA/Browser Forum, det internationale organ der fastlægger reglerne for SSL-branchen, har vedtaget en aggressiv reduktion af den maksimale levetid:
Formålet med kortere levetider er at reducere skadesvinduet, hvis en nøgle kompromitteres, og at tvinge automatisering af certifikathåndtering. Med 47-dages certifikater i 2029 er manuel fornyelse ikke realistisk for nogen infrastruktur af nævneværdig størrelse.
Automatisering via ACME-protokollen er svaret. Læs mere om SSL-automatisering og den fulde tidslinje for SSL-levetid.
Niveau 3: For IT-professionelle
Cipher suites og forward secrecy
En cipher suite er den specifikke kombination af algoritmer, der bruges i en TLS-forbindelse: nøgleudveksling, signaturalgoritme, symmetrisk kryptering og hash. TLS 1.3 ryddede dramatisk op. Hvor TLS 1.2 havde hundredvis af mulige kombinationer, hvoraf en del var usikre, har TLS 1.3 kun fem:
Nøgleudveksling er ikke en del af cipher suite-navnet i TLS 1.3, fordi den altid er ephemeral Diffie-Hellman (ECDHE med X25519 eller P-256, eller DHE med ffdhe2048+). RSA key exchange er fjernet helt. Det giver forward secrecy som standard: hver session bruger unikke, midlertidige nøgler. Selvom serverens private nøgle kompromitteres i fremtiden, kan opfanget trafik ikke dekrypteres bagudrettet. Efterretningstjenester er kendt for at opsamle krypteret trafik til fremtidig dekryptering ("collect now, decrypt later").
Hvis du stadig kører TLS 1.2 (f.eks. for kompatibilitet med ældre systemer), bør du eksplicit kun tillade sikre suites og tvinge forward secrecy. En god TLS 1.2-konfiguration tillader kun ECDHE-baserede suites med AEAD-ciphers (AES-GCM, ChaCha20-Poly1305). Undgå CBC-mode (sårbar over for padding oracle) og RSA key exchange (ingen forward secrecy).
Cipher suites: Hvad du bør bruge, og hvad du bør undgå
| Cipher suite | Status | Bemærkning |
|---|---|---|
| TLS_AES_256_GCM_SHA384 | Anbefalet | TLS 1.3. Stærkeste standardvalg. |
| TLS_CHACHA20_POLY1305_SHA256 | Anbefalet | TLS 1.3. Hurtig på enheder uden AES-NI (mobil, ARM). |
| TLS_AES_128_GCM_SHA256 | OK | TLS 1.3. Obligatorisk i standarden. Acceptabel sikkerhed. |
| ECDHE-ECDSA-AES256-GCM-SHA384 | Acceptabel | TLS 1.2. Bedste valg med ECDSA-certifikat. Forward secrecy + AEAD. |
| ECDHE-RSA-AES256-GCM-SHA384 | Acceptabel | TLS 1.2. Bedste valg med RSA-certifikat. Forward secrecy + AEAD. |
| AES256-SHA256 | Undgå | RSA key exchange. Ingen forward secrecy. Opfanget trafik kan dekrypteres, hvis nøglen lækker. |
| ECDHE-RSA-AES128-SHA | Undgå | CBC-mode. Sårbar over for padding oracle-angreb (BEAST, Lucky13). |
| DES-CBC3-SHA | Farlig | 3DES. Knækket (Sweet32-angreb). Aldrig acceptabel. |
| RC4-SHA | Farlig | RC4 er fundamentalt brudt. Forbudt i RFC 7465. |
Faldgruben ved den "perfekte" A+ konfiguration
Det er fristende at hærde sin TLS-konfiguration til kun at tillade de nyeste og stærkeste cipher suites. Men i praksis kan en alt for aggressiv konfiguration skabe reelle problemer:
- Ældre e-mail servere (Exchange 2010/2013, ældre SMTP-relays) understøtter ofte kun TLS 1.0/1.1 med CBC-ciphers. Hvis din mailserver afviser dem, dropper afsendere ned til ukrypteret SMTP, og dine e-mails sendes i klartekst.
- Ældre mobiltelefoner (Android 4.x, ældre IoT-enheder) mangler support for TLS 1.2 og AEAD-ciphers. Brugere får en fejlside uden forklaring.
- Betalingsgateways og API-integrationer bruger ofte ældre TLS-stacks. En stram konfiguration kan bryde kritiske forretningsprocesser.
- Interne systemer (printere, scannere, overvågningskameraer) kører sjældent opdateret firmware og understøtter måske kun ældre ciphers.
Vores anbefaling: Start med Mozillas "Intermediate" profil fra SSL Configuration Generator. Den giver en god balance mellem sikkerhed og kompatibilitet. Hærd derefter gradvist, baseret på hvad dine klienter faktisk understøtter. Brug logning til at identificere, hvilke cipher suites der reelt bruges, før du fjerner dem.
En A+ score på SSL Labs er meningsløs, hvis halvdelen af dine brugere eller integrationer ikke kan forbinde. Sikkerhed handler om at beskytte kommunikation, ikke om at samle point i en test.
Brug vores SSL Scanner til at tjekke din konfiguration. Til konfigurationsværktøjer: Mozillas SSL Configuration Generator genererer sikre konfigurationer for Apache, Nginx, HAProxy m.fl. På Windows er IIS Crypto det nemmeste værktøj til at hærde TLS-konfigurationen på IIS og Remote Desktop. Se også vores guide til Mozilla SSL Configuration Generator.
Trust stores og root-programmer
Hele PKI-systemets tillid starter med rodcertifikater, der er forudinstalleret på din computer eller enhed. Disse rødder vedligeholdes af fire store programmer med hver deres regler og audits:
Bruges af Windows, Edge og alle .NET-applikationer. Opdateres via Windows Update. Kræver årlig WebTrust-audit.
Bruges af macOS, iOS og Safari. Opdateres via OS-opdateringer. Strenge krav til CT-logging.
Bruges af Firefox og en lang række open source-projekter. Den mest transparente process. De fleste Linux-distributioner bruger Mozillas rødder.
Lanceret 2023. Chrome brugte tidligere OS-truststore, men har nu sin egen. Kræver Certificate Transparency og ACME-support for nye optagelser. Bruger CCADB (Common CA Database) som delt infrastruktur med Mozilla.
Valget af CA (certifikatudsteder) har betydning. Ikke alle CA'er har rødder i alle trust stores, og ikke alle rødder har samme dækning på tværs af platforme. En svag rod kan betyde, at dit certifikat ikke virker på ældre Android-enheder eller i specifikke enterprise-miljøer. FairSSL sælger fra DigiCert, GlobalSign og Sectigo, fordi de tre har den bredeste og mest stabile roddækning.
Certificate Transparency (CT)
Certificate Transparency (RFC 6962) er et offentligt, append-only logsystem, hvor alle udstedte SSL-certifikater registreres. Systemet blev foreslået af Google i 2013, primært motiveret af DigiNotar-skandalen i 2011, hvor en kompromitteret CA udstedte falske certifikater for bl.a. google.com. CT hjalp senere med at afsløre Symantecs uautoriserede certifikatudstedelser (2015-2017), som førte til at Symantecs rod blev fjernet fra alle browsere.
Alle offentlige CA'er er forpligtet til at logge certifikater i mindst to-tre uafhængige CT-logs, før certifikatet er gyldigt. CA'en modtager en Signed Certificate Timestamp (SCT) fra hver log, som indlejres i certifikatet (eller leveres via OCSP stapling eller TLS extension). Browsere kræver SCT'er og afviser certifikater uden dem. Chrome kræver mindst to SCT'er fra forskellige log-operatører.
Du kan overvåge CT-logs for dit domæne via crt.sh eller Googles Transparency Report. Det er gratis og viser alle certifikater, der er udstedt for dit domæne. Sæt overvågning op for dit domæne.
OCSP, CRL og tilbagekaldelse
Når et certifikat skal tilbagekaldes (kompromitteret nøgle, fejludstedelse, ophørt domæneejerskab), skal browsere og klienter vide det. Der er tre mekanismer:
- CRL (Certificate Revocation List): En komplet liste over tilbagekaldte certifikater fra den pågældende CA. Browseren downloader listen og tjekker serienummeret. Listerne kan blive store (flere MB) og opdateres typisk hver 1-24 timer. Skalerer dårligt.
- OCSP (Online Certificate Status Protocol): Browseren sender certifikatets serienummer til CA'ens OCSP-responder og får et signeret svar ("good", "revoked" eller "unknown"). Realtidstjek, men skaber et privatlivsproblem (CA'en kan se, hvilke sider du besøger) og et tilgængelighedsproblem (hvad hvis OCSP-serveren er nede?). Mange browsere "soft-fails": hvis OCSP-serveren ikke svarer, accepterer de certifikatet alligevel.
- OCSP Stapling: Serveren henter selv OCSP-svaret fra CA'en periodisk (f.eks. hver 4. time) og sender det signerede svar sammen med certifikatet under TLS-handshake. Browseren behøver ikke kontakte CA'en. Ingen privatlivslæk, ingen ekstra latency. Aktivér det med
ssl_stapling on;i Nginx ellerSSLUseStapling Oni Apache.
Vores anbefaling: Aktivér OCSP Stapling. Det er den eneste revocation-mekanisme, der reelt virker for alle klienter uden privatlivsproblemer. Serveren leverer beviset proaktivt, og klienten behøver ikke foretage eksterne opslag.
Tilbagekaldelse er i praksis brudt
Google Chrome tjekker hverken CRL eller OCSP for almindelige certifikater. Googles argument er, at OCSP-opslag giver CA'er mulighed for at tracke brugernes besøgsmønstre, og at soft-fail (acceptér certifikatet, hvis OCSP-serveren ikke svarer) gør mekanismen meningsløs mod aktive angribere.
I stedet bruger Chrome sin egen CRLite-liste, der kun dækker de største og mest kritiske sites. Resultatet er, at tilbagekaldelse af et certifikat for et almindeligt domæne reelt ikke beskytter Chrome-brugere. Certifikatet vises stadig som gyldigt, selv efter tilbagekaldelse. Firefox og andre browsere tjekker stadig OCSP/CRL, men med Chrome på over 65% markedsandel er det flertallet af brugere, der ikke er beskyttet.
Det har konkrete sikkerhedskonsekvenser: hvis din private nøgle kompromitteres, kan en angriber fortsætte med at bruge certifikatet mod Chrome-brugere, selv efter at du har tilbagekaldt det hos CA'en. Certifikatet virker indtil det udløber.
Derfor bør du:
- Undgå wildcard-certifikater på rod-niveau af kritiske domæner. Hvis
*.dit-domæne.dkkompromitteres, kan du ikke tilbagekalde det effektivt, og angriberen kan udgive sig for ethvert subdomæne. - Sørg for mulighed for at skifte FQDN i en nødsituation. Hvis du kan pege trafikken til et nyt hostname, kan du undgå et man-in-the-middle angreb med det kompromitterede certifikat.
- Brug korte certifikatlevetider, men stol ikke på dem alene. Googles argument er, at korte levetider (47 dage i 2029) reducerer skadesvinduet nok til at gøre tilbagekaldelse overflødig. Det er vi ikke enige i. 47 dage er rigeligt til at forårsage alvorlig skade, og selv få dage med et kompromitteret certifikat kan være katastrofalt, hvis timingen er rigtig. Korte levetider hjælper, men erstatter ikke reel tilbagekaldelse.
Let's Encrypt udfasede OCSP helt i 2025. Tendensen er klar: branchen bevæger sig mod korte levetider som erstatning for tilbagekaldelse. Det gør ACME-automatisering endnu mere kritisk.
CAA records: Begræns hvem der kan udstede
DNS CAA records (Certification Authority Authorization, RFC 8659) er en simpel mekanisme, der fortæller CA'er, om de har lov til at udstede certifikater for dit domæne. Alle CA'er er forpligtet til at tjekke CAA, før de udsteder. Hvis din CAA record kun tillader DigiCert, kan hverken Sectigo, Let's Encrypt eller nogen anden CA udstede til dit domæne.
iodef-recorden i eksemplet er et notifikationssystem: hvis en CA, der ikke er i din CAA-liste, modtager en anmodning om at udstede et certifikat for dit domæne, skal den sende en rapport til den angivne e-mail eller URL. Det giver dig besked om uautoriserede udstedelsesforsøg, uanset om de lykkes eller ej.
CAA er enkel at sætte op og giver en stærk sikkerhedsgaranti. Brug FairSSLs CAA record generator til at bygge din konfiguration.
HPKP (HTTP Public Key Pinning): Udgået og farlig
HPKP (RFC 7469) var en HTTP-header, der pinnede specifikke offentlige nøgler i browseren. Når en bruger besøgte dit site, huskede browseren, hvilke nøgler den havde set, og afviste fremtidige forbindelser med andre nøgler i hele pin-perioden (typisk 60 dage).
Idéen var at forhindre man-in-the-middle angreb med falske certifikater: selv hvis en angriber fik en CA til at udstede et certifikat for dit domæne, ville browseren afvise det, fordi nøglen ikke matchede den pinnede.
Hvorfor HPKP blev fjernet
I praksis viste HPKP sig at være farligere end de angreb, den skulle beskytte mod:
- Selvlåsning. En fejlkonfiguration, et mistet nøglepar eller et CA-skifte kunne permanent låse alle brugere ude af dit site i uger eller måneder. Der var ingen måde at rulle en aktiv pin tilbage.
- HPKP Suicide. Angribere kunne sætte en ondsindet pin på et kompromitteret site og derefter fjerne den rigtige nøgle. Sitet blev permanent utilgængeligt for alle brugere, der havde modtaget pinnen.
- Ransomware-vektor. En angriber med midlertidig kontrol over en server kunne sætte en pin til sin egen nøgle og derefter kræve løsepenge for at frigive domænet.
Alle browsere har fjernet HPKP. Chrome fjernede det i version 72 (januar 2019), Firefox i version 72 (januar 2020). Mozilla har fjernet HPKP fra deres Web Security Guidelines. Hvis du stadig sender HPKP-headere, gør de ingen skade, men de har ingen effekt.
Erstatningen er CAA records (se ovenfor). CAA giver lignende beskyttelse mod uautoriseret certifikatudstedelse, men uden risikoen for at låse dig selv ude. CAA håndhæves af CA'erne (server-side), ikke af browserne (klient-side), så en fejlkonfiguration kan rettes uden at påvirke brugere.
HSTS og preloading
HTTP Strict Transport Security (RFC 6797) er en HTTP-header, der instruerer browsere om altid at bruge HTTPS:
Når browseren har modtaget denne header, vil den aldrig forsøge en HTTP-forbindelse i max-age perioden (her 2 år). Det beskytter mod SSL-stripping angreb (f.eks. Moxie Marlinspikes sslstrip), hvor en angriber nedgraderer forbindelsen fra HTTPS til HTTP.
HSTS Preloading går et skridt videre: dit domæne optages på en liste, der er hardkodet i browserne. Så selv det allerførste besøg bruger HTTPS (TOFU-problemet elimineres). Ansøg via hstspreload.org.
Advarsel: Preloading er svært at fjerne. Processen for at komme af listen tager måneder og kræver, at alle browsere udgiver en opdatering. Sørg for, at HTTPS virker korrekt på alle subdomæner (inkl. interne), før du ansøger. includeSubDomains er et krav for preloading.
Automatisering med ACME
ACME (Automatic Certificate Management Environment, RFC 8555) er en protokol til automatisk udstedelse og fornyelse af certifikater. Let's Encrypt gjorde ACME populært fra 2016, men protokollen er åben og bruges af kommercielle CA'er som DigiCert, GlobalSign og Sectigo. Via FairSSLs ACME-server får du DigiCert-familien og GlobalSign.
ACME validerer domæneejerskab automatisk via tre challenge-typer:
- HTTP-01: CA'en kontrollerer en specifik fil under
/.well-known/acme-challenge/. Kræver port 80 åben. Kan ikke bruges til wildcard. - DNS-01: CA'en tjekker en TXT record under
_acme-challenge.ditdomaene.dk. Kræver DNS API-adgang (eller CNAME-delegation). Kan bruges til wildcard. - TLS-ALPN-01: CA'en forbinder til port 443 med en speciel ALPN extension. Bruges af Caddy og til situationer, hvor port 80 er blokeret.
FairSSL tilbyder ACME med AutoDNS-validering: opret en permanent CNAME-viderestilling fra _dnsauth.ditdomaene.dk til FairSSLs valideringsinfrastruktur. Så håndteres DNS-validering automatisk, uden at du giver DNS API-nøgler til servere.
ACME Renewal Information (ARI, RFC 9773) er den seneste udvidelse: CA'en kan fortælle din ACME-klient præcis, hvornår den bør forny, f.eks. fordi et certifikat tilbagekaldes eller et intermediate skiftes ud. Med 47-dages certifikater i 2029 bliver timing for fornyelse kritisk. Læs mere om SSL-automatisering med FairSSL.
Almindelige fejl og fejlfinding
De hyppigste fejl:
Serveren sender kun leaf-certifikatet. Virker i Chrome (der kan finde intermediate via AIA), men fejler i curl, Python, mobile apps og CI/CD-pipelines. Løsning: installér hele kæden.
Siden bruger HTTPS, men loader billeder, scripts eller stylesheets over HTTP. Browseren blokerer eller nedgraderer sikkerheden. Løsning: alle ressourcer skal bruge HTTPS eller protokol-relative URLs.
Certifikatet er udstedt til www.dit-domæne.dk, men serveren svarer også på dit-domæne.dk (uden www), som ikke er i SAN-feltet. Løsning: inkludér begge navne i certifikatet, eller brug et redirect.
Serveren tillader forældede TLS-versioner. Disse har kendte sårbarheder (BEAST, CRIME) og er ikke tilladt under PCI DSS. Alle moderne browsere har droppet support. Løsning: deaktivér TLS 1.0 og 1.1, tillad kun TLS 1.2 og 1.3.
Produktionssites får typisk opmærksomhed, men interne systemer (admin-paneler, CI/CD, monitoring) glemmes ofte. Et udløbet certifikat på en intern service kan bryde hele deployment-pipelinen. Løsning: ACME-automatisering på alle services, ikke kun de offentlige.
Ofte stillede spørgsmål om SSL
Find svar på de mest almindelige spørgsmål om SSL certifikater og FairSSL.
Klar til at oprette en gratis konto?
Opret en gratis konto og udsted dit første certifikat på under 10 minutter.