Hvad SSL/TLS faktisk gør
SSL og TLS bruges ofte i flæng, men TLS er den moderne standard. Når en browser eller klient forbinder til en server via HTTPS eller en anden TLS-baseret tjeneste, forhandles der først parametre for forbindelsen, og derefter sendes data over en krypteret kanal. Resultatet er, at indholdet bliver læst og ændret vanskeligere for andre i netværket, og at klienten kan verificere, at den forbinder til den rigtige server via certifikatet.
Det er vigtigt at skelne mellem:
- Kryptering i transit (beskyttelse mellem klient og server)
- God autenticitetskontrol (certifikat og tillid)
- Rigtig konfiguration (TLS-versioner, ciphers/algoritmer og sikkerhedsindstillinger)
Et simpelt mentalmodel for implementeringen
Tænk processen som tre lag, der skal spille sammen:
- Certifikatet: Identitet på serveren.
- TLS-handshake: Forhandling af krypteringsmetode og etablering af den sikre kanal.
- Server- og klientkonfiguration: Hvilke TLS-versioner, protokoller og indstillinger der accepteres.
Hvis én af disse dele er forkert, kan du få fejl som “ugyldigt certifikat”, “handshake failed” eller forbindelser der falder tilbage til mindre sikre metoder. Derfor bør du arbejde sekventielt: først certifikatets korrekthed, derefter TLS-understøttelse og til sidst validering af selve forbindelsen.
Trin for trin: fra forberedelse til test
1) Afklar hvor TLS skal bruges
Start med at identificere, hvilke endpoints og services der skal være TLS-beskyttede (typisk HTTP over TLS, altså HTTPS, men også andre protokoller hvor TLS er relevant). Herefter vælger du det miljø, du vil implementere i (fx test og produktion) og en plan for ændringer.
2) Klargør certifikatet og certifikatkæden
Du skal have et servercertifikat, der passer til det navn (domæne eller host), klienten bruger. Derudover skal certifikatkæden typisk kunne bygges korrekt, så klienten kan finde tillid til udstederen (chain-of-trust).
Kontroller især:
- At certifikatet matcher domænenavnet
- At du installerer “hele” kæden der forventes i konfigurationen (ofte: servercertifikat + eventuelle mellemliggende certifikater)
- At certifikatet ikke er udløbet
3) Konfigurer serveren til TLS
På serversiden skal du aktivere TLS og pege på certifikat og nøgle. Samtidig bør du indstille, hvilke TLS-versioner der er acceptable. En moderne tilgang er at undgå gamle protokoller og kun tillade versioner, der er anset som sikre i praksis.
Derudover indgår typisk valg af:
- Hvilke protokoller der accepteres
- Hvilke kryptografiske algoritmer/ciphers der bruges
- Hvordan sessioner genbruges (hvor relevant)
Konsekvensen af dårlige valg er ofte enten svage forbindelser eller direkte fejl fra klienter, der ikke accepterer dine indstillinger.
4) Begræns og håndter fallback fra gamle klienter
TLS kræver ofte et kompromis mellem sikkerhed og kompatibilitet. Hvis du tillader for gamle versioner, øger du angrebsfladen. Hvis du derimod slukker for meget, kan ældre klienter helt miste adgang.
Praktisk strategi:
- Rul ændringer ud i etaper (test først)
- Overvåg hvilke klienter der faktisk fejler
- Planlæg et tidspunkt hvor du helt udfaser usikre/forældede muligheder
5) Aktiver sikre standarder på applikationsniveau (hvor relevant)
Selv om TLS beskytter forbindelsen, kan applikationen stadig have sikkerhedsemner. Særligt når man opsætter HTTPS, bør du sikre at svar og cookies håndteres korrekt (fx korrekt brug af sikre flags, hvor det gælder din stack). Dette er ikke et “TLS-krav” i sig selv, men en almindelig del af en samlet sikker opsætning.
6) Test end-to-end, ikke kun på serveren
Når konfigurationen er på plads, skal du verificere i praksis, at klienter får en korrekt TLS-forbindelse.
Test der typisk afslører problemer:
- Browser-test: Ser du advarsler om certifikat eller problemer med forbindelsen?
- Handshake-succes: Kan klienten forhandle TLS uden fejl?
- Protokol og krypteringsvalg: Bruger forbindelsen de forventede TLS-versioner/indstillinger?
- Belastnings- og genforbindelsesscenarier: Virker det ved genbesøg og på tværs af miljøer?
Forskelle, grænser og undtagelser
TLS vs. “HTTPS virker”
At “HTTPS åbner i browseren” er ikke nødvendigvis nok til at sige, at opsætningen er optimal eller robust. Det kan også betyde at der bruges en ældre TLS-version, eller at nogle klienter bruger alternative stier. Derfor bør du validere hvad der faktisk forhandles.
Certifikatfornyelse er en del af implementeringen
TLS er en løbende driftssag. Selv et perfekt opsat TLS-miljø fejler, hvis certifikatet udløber og der ikke er en proces for fornyelse. Planlæg derfor, hvordan du håndterer fornyelser uden lange udfald.
Proxyer, load balancere og flere lag kan ændre adfærden
I mange setup ligger TLS terminering ikke direkte i applikationsserveren, men i et frontlag (fx en reverse proxy eller load balancer). Det betyder, at der kan være flere forbindelser: klient→front og front→backend. Hver forbindelse kan have sine egne TLS-indstillinger og certifikater, og det påvirker både sikkerhed og fejlsøgning.
“Sikkerhed” afhænger også af konfigurationsvalg
Selv med et korrekt certifikat kan en svag TLS-konfiguration gøre forbindelsen mindre sikker. Omvendt kan meget restriktive indstillinger skabe kompatibilitetsproblemer. Derfor er det vigtigt at teste mod rigtige klienttyper og at bruge en gradvis udfasningsstrategi.
Praktisk kontrol: sådan verificerer du, at det er rigtigt
Brug en tjekliste, som du kan gentage ved hver ændring:
- Certifikat: matcher domænenavn, gyldigt tidsrum, korrekt kæde.
- TLS-forhandling: ingen handshake-fejl i klienten.
- Forhandlet sikkerhed: forbindelsen bruger forventede TLS-versioner og sikre indstillinger.
- Ingen utilsigtet fallback til ældre/skrøbelige protokoller.
- Drift: certifikatfornyelsesplan og overvågning af fejl.
Hvis du støder på problemer, starter du typisk med certifikatoverensstemmelse (navn/kæde/udløb), derefter TLS-kompatibilitet (protokol/version) og til sidst eventuelle frontlags-proxyer (flere TLS-hop). Det er sjældent én “magic fix”, men næsten altid en systematisk gennemgang af de tre lag: certifikat, handshake og konfiguration.