En fungerande TLS-kontroll visar vilken tjänst klienten når, vilket certifikat den ser och om hela vägen till mottagande system har det avsedda skyddet. Ett hänglås i webbläsaren svarar bara på en del av frågan. Förnyelse som fungerar i certifikattjänsten kan ändå lämna ett gammalt certifikat på en lastbalanserare.
Den här guiden hjälper IT-ansvariga att skapa ett register över anslutningar och certifikat, välja en teknisk baslinje och kontrollera den efter förändringar. Resultatet är ett underlag med ägare, observerat tillstånd och öppna avvikelser. För själva riskbedömningen av uppgifter, nycklar och lagring används även guiden om kryptering av personuppgifter.
Vad TLS löser och vad som återstår
TLS kan skydda överföringens innehåll och integritet samt autentisera den server som klienten ansluter till, när konfigurationen och verifieringen fungerar. Det hindrar inte en behörig mottagare från att läsa innehållet. Det avgör heller inte om mottagaren har rätt att få uppgifterna eller hur uppgifterna lagras efter överföringen.
Artikel 32 GDPR kräver lämplig säkerhet med hänsyn till bland annat riskerna och den tekniska utvecklingen. Kryptering nämns som en möjlig åtgärd där det är lämpligt. Förordningen anger inte en universell TLS-version, ett visst skanningsbetyg eller samma certifikatinställningar för varje svensk organisation. Krav från avtal eller sektorsregler kan tillkomma. GDPR: artikel 32.
Skriv därför två separata rader i er dokumentation: vilken risk som ska hanteras och vilken teknisk konfiguration som används. Då går det att förstå varför en äldre integration kräver en åtgärd även om företagets publika webbplats får ett gott testresultat.
1. Inventera tjänsterna där TLS används
Utgå från kartläggningen av IT-system och dataflöden. Ta med webbplatser, API:er, administrativa gränssnitt, anslutningar till databaser och de integrationer som överför personuppgifter. Notera varje separat delsträcka när trafiken passerar en proxy, ett CDN eller en lastbalanserare.
För varje tjänst behöver ni värdnamn, port, driftmiljö, teknisk ägare och vilken verksamhet som påverkas vid avbrott. Dokumentera var TLS avslutas. En anslutning från webbläsaren till ett CDN och en anslutning från CDN till applikationen är två kontroller, även när användaren bara ser ett värdnamn.
Registrera också klienttypen. En modern webbläsare, en äldre maskin och en internt utvecklad integrationsklient kan ha olika stöd och olika felbeteenden. Kartlägg kompatibiliteten innan ni ändrar produktionsinställningar, men använd inte en okänd klient som ett permanent skäl att behålla osäkra protokoll.
2. Välj protokoll och kryptografisk profil med aktuella källor
TLS 1.0 och 1.1 är utfasade i IETF:s rekommendationer. För befintliga tjänster ger RFC 9325 vägledning om säker användning av TLS, inklusive TLS 1.2 och 1.3. TLS 1.2 kräver större omsorg vid val av algoritmer och andra inställningar; använd en underhållen profil för den aktuella serverprodukten. IETF: RFC 9325.
I juli 2026 publicerades RFC 9852. Den kräver att nya protokoll som använder TLS anger TLS 1.3 som standard. TLS 1.2 kan finnas som ett ytterligare alternativ när införandeförhållanden motiverar det, men inte som standardval i dessa nya protokoll. Det är ett preciserat krav på protokollutformning, inte en svensk lagregel som automatiskt förbjuder varje befintlig TLS 1.2-tjänst ett visst datum. IETF: RFC 9852.
Som intern baslinje kan en organisation välja TLS 1.3 för en ny kontrollerad integration där båda ändar stöder det. Om en befintlig partneranslutning fortfarande behöver TLS 1.2 bör registret beskriva den faktiska klienten, aktuell säker konfiguration, ansvarig för migrering och när behovet ska prövas igen. Kopiera inte algoritmnamn mellan serverprodukter utan att kontrollera hur produkten tolkar inställningarna.
3. Kontrollera certifikatets identitet och hela kedjan
Certifikatet måste passa det namn som klienten avser att nå. Testa därför det riktiga tjänstenamnet, inte bara en IP-adress som råkar svara. Kontrollera giltighetstid, namn, utfärdare och att klienten kan bygga en betrodd certifikatkedja. Ett internt certifikat kan fungera korrekt för förvaltade klienter med rätt tillitsankare även om en extern webbläsare inte litar på det.
Skriv upp var den privata nyckeln finns, vem som kan använda den och hur den ersätts vid misstänkt kompromettering. En inventeringsfil ska innehålla en hänvisning till nyckelhanteringen, inte själva privata nyckeln. Stora generella behörigheter till DNS eller certifikatkonto kan göra en automatiserad förnyelse till en ny angreppsväg.
OpenSSL kan användas för en avgränsad kontroll av en egen eller uttryckligen godkänd tjänst. Följande exempel visar en TLS 1.3-anslutning och begär både verifiering av värdnamnet och avbrott vid verifieringsfel. Byt exempeladressen mot den godkända tjänsten. För interna utfärdare behövs även korrekt konfiguration av klientens betrodda CA-certifikat.
openssl s_client -connect portal.example:443 -servername portal.example -verify_hostname portal.example -verify_return_error -tls1_3
Spara verifieringsresultat och förhandlad version i kontrollärendet. Kommandot visar inte alla versioner servern accepterar och är inte ett fullständigt applikationstest. Kör inte med en inställning som ignorerar certifikatfel och tolka sedan anslutningen som godkänd. OpenSSL: s_client och verifieringsalternativ.
4. Följ trafiken efter lastbalanseraren
Kontrollera vilken identitet proxyn använder mot den bakomliggande tjänsten och om den faktiskt verifierar certifikatet där. Att markera ”HTTPS till backend” utan fungerande verifiering lämnar en annan risk än en verifierad anslutning. Ange också om backend kan nås direkt och därmed kringgå kontroller i den yttre tjänsten.
Om någon delsträcka går i klartext behöver det framgå uttryckligen, tillsammans med nätets skydd, åtkomliga aktörer och riskbedömningen. Utgå inte från att ett internt nät är en garanti för sekretess. Använd systemets härdningsrutin för Windows och Linux för att knyta nätgränser och tjänstekonton till den faktiska driften.
För webbtjänster kan HSTS instruera webbläsaren att använda HTTPS för värden under en angiven tid. Inför det med kännedom om underdomäner och återställningsmöjligheter. Direktivet includeSubDomains påverkar även underdomäner; ett långvarigt värde bör föregås av kontroll att berörda tjänster verkligen fungerar över HTTPS. HSTS ersätter inte certifikatförnyelsen. IETF: HSTS, RFC 6797.
5. Gör förnyelsen till en övervakad driftuppgift
Bestäm vem som ansvarar för utfärdande, installation och kontroll från klientens perspektiv. De tre stegen kan utföras av olika tjänster. Ett automatiskt jobb kan lyckas skapa ett nytt certifikat medan en misslyckad omstart lämnar det tidigare certifikatet i användning.
Välj varningsnivåer efter certifikatens faktiska livslängd och den tid ni behöver för felsökning. Kontrollera larmets mottagare även när en administratör slutar. För tjänster med mycket korta certifikat behöver övervakningen upptäcka misslyckad förnyelse betydligt tidigare än en gammal årlig kalenderpåminnelse skulle göra.
Räkna inte med att utfärdaren skickar ett mejl som räddar situationen. Let’s Encrypt avslutade sina meddelanden om utgående certifikat den 4 juni 2025 och hänvisar till egen övervakning eller andra lösningar. Kontrollera motsvarande villkor för den utfärdare ni använder. Let’s Encrypt: expiration emails.
6. Fyll kontrollregistret och följ upp avvikelser
Nedan visas ett fiktivt kontrollresultat. Det är ett exempel på hur observationer kan dokumenteras, inte ett test av en verklig kundmiljö.
| Anslutning | Observerat resultat | Beslut och ägare | Bevis för avslut |
|---|---|---|---|
| Kundportal till yttre proxy | TLS 1.3, korrekt värdnamn och betrodd kedja | Drift behåller profilen och övervakningen | Daterat klientresultat efter nästa förnyelse |
| Proxy till ordertjänst | Kryptering aktiv men certifikatverifiering avstängd | Plattformsteamet inför verifiering i pilot före ändring | Avsiktligt fel certifikat avvisas i isolerad testmiljö |
| Partnerintegration | TLS 1.2 behövs av identifierad äldre klient | Integrationsägaren verifierar säker profil och planerar uppdatering | Godkänd anslutning med uppdaterad klient och stängt undantag |
| Reservmiljö | Förnyat certifikat finns men gammal version serveras | Drift rättar distributionssteget | Kontroll från reservmiljöns normala klientväg |
Spara även misslyckade kontroller. Ett saknat resultat ska stå som ej verifierat, inte räknas som godkänt. Koppla varje kvarstående avvikelse till säkerhetsåtgärdernas ansvar och dokumentation. Om avvikelsen kräver en djupare prövning av angreppsvägar kan den ingå i en avgränsad beställning av penetrationstest.
Vanliga frågor
Räcker ett bra betyg från en publik TLS-skanner?
Betyget är användbart som en observation av den testade externa tjänsten. Det visar inte den interna delsträckan, alla klienters verifiering, behörigheter till privata nycklar eller att nästa förnyelse kommer att installeras. Behåll den externa kontrollen och komplettera med de delar som skannern inte ser.
Behöver vi ett särskilt dyrt certifikat för GDPR?
GDPR anger ingen prisklass eller generell skyldighet att använda en viss kommersiell certifikattyp. Välj efter identitet, klienternas tillit, driftkrav och säker nyckelhantering. Ett inköp ersätter inte kontroll av att rätt certifikat faktiskt serveras.
Vad ska göras när förnyelsen misslyckas?
Kontrollera validering, behörighet, utfärdande och distribution var för sig. Verifiera därefter tjänsten från klientens väg. Använd en planerad reservlösning om tjänsten annars måste stoppas; instruera inte användarna att rutinmässigt klicka förbi certifikatvarningar. Knyt scenariot till kontinuitetsplanen, så att verksamheten vet hur den arbetar under felsökningen.