En TLS-konfiguration skal beskytte forbindelsen til den rigtige modpart og fungere gennem hele det relevante dataflow. Et gyldigt certifikat på forsiden fortæller ikke, om forbindelsen fra en proxy til applikationen er beskyttet, om en gammel integrationsklient bruger en svagere protokol, eller om certifikatet kan fornyes uden nedbrud.
Denne guide giver en praktisk metode til at vælge protokoller, styre certifikater og kontrollere ændringer. Eksemplet er en fiktiv kundeportal. De konkrete konfigurationsvalg er begrundede valg for eksemplet og skal tilpasses det faktiske miljø.
Afgræns hvad TLS beskytter
TLS beskytter transport mellem forbindelsens endepunkter. Når forbindelsen afsluttes i en reverse proxy, dekrypteres data dér. En efterfølgende forbindelse til applikationen er et særskilt led. Beskyttelse på det første led gør ikke automatisk det næste led sikkert.
TLS løser heller ikke adgangsstyring i applikationen, unødvendig indsamling eller for bred adgang til lagrede filer. En korrekt krypteret forbindelse kan overføre oplysninger til en bruger, som applikationen fejlagtigt har givet adgang. Knyt derfor arbejdet til den samlede krypterings- og nøglehåndtering og systemets øvrige foranstaltninger.
Den fiktive portal Fjordservice bruges af kunder til at se serviceaftaler. Trafikken går fra browser til en ekstern proxy og videre til virksomhedens applikation. Et ældre partnerprogram henter rapporter fra et separat API. It-teamet tager alle tre forbindelser med i vurderingen.
Vælg protokol efter aktuelle specifikationer
RFC 9325 beskriver anbefalinger for sikker brug af TLS og DTLS. Den fraråder forældede protokoller og giver konkrete krav og anbefalinger til blandt andet krypteringsvalg, validering og fremadrettet hemmeligholdelse. Konfigurationsarbejdet skal læse forskellen mellem et krav og en anbefaling i specifikationen.
RFC 9852, offentliggjort i juli 2026, ændrer anbefalingerne for nye protokoller, der bruger TLS: TLS 1.3 skal understøttes og være standard. TLS 1.2 kan være en yderligere mulighed, hvis hensynet til udrulning begrunder det. Ændringen vedrører TLS og omfatter ikke DTLS. Den er ikke en dansk lovbestemmelse, der automatisk forbyder enhver eksisterende TLS 1.2-forbindelse.
Fjordservice vælger TLS 1.3 som foretrukken protokol. Teamet undersøger den eksisterende partnerintegration særskilt, fordi den endnu kun understøtter TLS 1.2. En undtagelse beskriver klient, endpoint, behov, beskyttelse og planlagt erstatning. Den giver ikke tilladelse til at åbne alle virksomhedens tjenester for ældre protokoller.
TLS 1.0 og 1.1 indgår ikke i den valgte konfiguration. Hvis en klient kun fungerer med en sådan version, behandles det som et integrationsproblem, som kræver en løsning. Teamet skal ikke lade alle brugeres forbindelser falde tilbage for at undgå én fejlmeddelelse.
Krypteringsvalg skal passe til protokollen
Brug en vedligeholdt konfiguration for den konkrete server og TLS-implementering. Navne og syntaks kan variere, og indstillinger for TLS 1.2 og TLS 1.3 styres ikke nødvendigvis i samme felt. En kopieret streng fra en anden servertype kan derfor give en falsk tryghed.
For Fjordservices midlertidige TLS 1.2-forbindelse vælges en begrænset konfiguration med ECDHE og AES-GCM, som svarer til relevante anbefalinger i RFC 9325. Teamet kontrollerer den faktisk forhandlede kombination. Et RSA-certifikat skal ikke forveksles med statisk RSA-nøgleudveksling; certifikatets underskriftsfunktion og forbindelsens nøgleudveksling er forskellige spørgsmål.
Fremadrettet hemmeligholdelse begrænser, hvad kompromittering af en langsigtet nøgle kan afsløre om tidligere sessioner. Den beskytter ikke mod en angriber, der allerede læser data i den kørende applikation. Krav til softwarevedligeholdelse og hærdning af servere er derfor stadig relevante.
Aktivér heller ikke optimeringer alene, fordi de giver en lavere svartid i en prøve. Fjordservice holder 0-RTT deaktiveret, indtil teamet har vurderet genafspilningsrisiko og applikationens håndtering af handlinger. En gentaget læsning og en gentaget ændring af en ordre kan have meget forskellige konsekvenser.
Certifikatet skal kontrolleres af klienten
Registrér hvert certifikats tjenestenavn, udsteder, ejer, udløb, fornyelsesmetode og placering af privat nøgle. Undersøg hele kæden og navnematch fra den klient, som skal bruge tjenesten. Det er ikke tilstrækkeligt, at serveren blot kan præsentere et certifikat.
I eksemplet viser den eksterne portal det korrekte certifikat, men proxyen accepterer ethvert certifikat fra backend. Teamet ændrer dette, så den interne forbindelse validerer den forventede modpart gennem den aftalte tillidskæde. Ellers ville krypteringen kunne beskytte en forbindelse til en forkert modtager.
Privatnøgler må kun være tilgængelige for de nødvendige processer og administratorer. En kopi i en almindelig supportticket skaber en ny eksponering. Hvis nøglen mistænkes kompromitteret, skal håndteringen omfatte udskiftning og relevant tilbagekaldelse samt vurdering af hændelsen. Det er ikke nok at forlænge det eksisterende certifikats gyldighed.
Udfyldt ændrings- og kontrolplan
| Led i Fjordservices flow | Besluttet ændring | Prøve og forventet resultat |
|---|---|---|
| Browser til proxy | TLS 1.3 foretrækkes; forældede versioner deaktiveres | Moderne browser forbinder; forsøg med TLS 1.0 afvises |
| Proxy til applikation | Krypteret forbindelse med validering af modpart | Forkert tjenestenavn medfører afvisning |
| Partner til API | Afgrænset TLS 1.2-understøttelse under dokumenteret undtagelse | Partnerklienten gennemfører sin godkendte forespørgsel |
| Certifikatfornyelse | Automatisk fornyelse med separat alarm | Fornyelsesprøve viser nyt certifikat på det faktisk eksponerede endpoint |
| Adgang til privat nøgle | Kun nødvendig tjeneste og udpegede administratorer | Almindelig driftskonto kan ikke læse nøglen |
Tabellen angiver forventninger. Den endelige kontrolrapport skal indeholde faktiske resultater, tidspunkt og den konfiguration, som blev afprøvet. Bevar også fejlene; de kan forklare, hvorfor en ændring ikke blev frigivet.
Et udfyldt resultat i eksemplet er: »Proxyens nye certifikat blev indlæst, men én instans viste stadig det gamle. Udrulningen blev standset. Instansen blev genindlæst efter den godkendte procedure, hvorefter alle registrerede endpoints viste den nye version.« Det er mere anvendeligt end en samlet grøn markering uden målte endpoints.
Planlæg certifikatfornyelse som drift
Automatisk fornyelse er en proces med afhængigheder. Den kan kræve adgang til DNS, en valideringssti eller et internt certifikatsystem. Hvis en medarbejder ændrer firewallregler eller lukker en gammel konto, kan fornyelsen holde op med at virke, selv om dagens forbindelser fortsat fungerer.
Fjordservice udpeger en driftsansvarlig og en stedfortræder. Alarmen sendes til en overvåget funktion, ikke kun til den medarbejder, der oprindeligt bestilte certifikatet. Den skal give tid til at løse en fejl, før tjenesten bliver utilgængelig. Det konkrete varsel tilpasses gyldighedsperioden og virksomhedens responstid.
Afprøv, at fornyelsen også omfatter installation og genindlæsning på alle relevante instanser. Et nyt certifikat i et lager hjælper ikke, hvis serveren stadig bruger det gamle. Forbind varslerne med virksomhedens sikkerhedslogning og hændelsesopfølgning, så fejl får en ansvarlig modtager.
Afprøv fra flere relevante steder
En ekstern kontrol ser den offentlige side, men kan ikke nødvendigvis undersøge intern trafik eller en partnerforbindelse bag adgangsbegrænsning. Kontrollér også alternative værtsnavne, IPv6 hvor anvendt og instanser bag lastfordeling. Brug kun undersøgelser på systemer, hvor organisationen har den nødvendige tilladelse.
Gennemfør både positive og negative prøver. Det godkendte login skal virke, mens et forkert certifikat eller en uønsket protokol skal afvises. Et vellykket besøg i en browser beviser kun den ene del.
En penetrationstest med tydeligt scope kan supplere konfigurationskontrollen, men erstatter ikke løbende vedligeholdelse. Rapporten skal angive, hvilke endpoints og tidspunkter der faktisk blev undersøgt. Når en fejl er rettet, kontrolleres den relevante forbindelse igen.
Godkendelse kræver både sikkerhed og funktion
Datatilsynets vejledning om risikovurdering beskriver behovet for passende foranstaltninger ud fra risikoen for personer. Et eksternt værktøjs karakter er derfor et teknisk signal, ikke en fuldstændig GDPR-vurdering.
Fjordservice godkender ændringen, når de dokumenterede sikkerhedsprøver og de nødvendige forretningsfunktioner er gennemført. Den midlertidige partnerundtagelse forbliver synlig med en ejer og en konkret plan for afvikling. Ved en ny proxy, ændret klient eller opdateret standard genbesøges de berørte valg.
Brug systemkortlægningen som indgang til dette arbejde. Når nye forbindelser tilføjes, skal deres kryptering, modpartsvalidering og certifikatdrift følge med. Så bliver TLS en vedligeholdt egenskab ved dataflowet frem for en engangsindstilling på hjemmesiden.
Tekniske primærkilder er kontrolleret den 8. september 2026. Konfigurationen skal altid sammenholdes med den aktuelle dokumentation for den konkrete softwareversion.