Checklista för TLS-certifikat på er webbplats

Ett certifikatproblem är ett av få säkerhetsproblem som varje besökare ser. Ett utgånget certifikat lägger en helsidesvarning framför er webbplats, och API-klienter och appar slutar helt enkelt att ansluta. De flesta sådana fel går att undvika, och resten är snabba att hitta. Den här checklistan går igenom vad som ska vara rätt på varje värd med HTTPS, hur ni kontrollerar det själva och vad TrustSek rapporterar.

Många säger fortfarande SSL-certifikat. Det är samma sak: SSL är föregångaren, och det protokoll som används i dag heter TLS.

Exemplen använder example.com. Byt ut den mot ert eget värdnamn.

1. Giltighetstid: automatisera förnyelsen

Certifikaten blir kortare. Enligt CA/Browser Forums Baseline Requirements får allmänt betrodda TLS-certifikat som utfärdas från och med 15 mars 2026 vara giltiga i högst 200 dagar. Gränsen sjunker till 100 dagar från 15 mars 2027 och till 47 dagar från 15 mars 2029. En rutin som bygger på att någon kommer ihåg en gång om året fungerar inte längre.

Automatisera förnyelsen med ACME (RFC 8555), protokollet bakom Let's Encrypt som även många kommersiella certifikatutfärdare stöder, eller använd plattformens hanterade certifikat. Kontrollera sedan att automatiken faktiskt fungerar:

• förnyelsen startar i god tid, vanligen när ungefär en tredjedel av giltighetstiden återstår
• det nya certifikatet laddas, vilket kan kräva omstart av webbserver, lastbalanserare eller CDN
• en misslyckad förnyelse når en människa, inte bara en loggfil
• certifikat som installerats för hand (apparater, VPN-gateways, äldre servrar) finns på en lista med ansvarig och datum

Kontrollera datumen själva:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

2. Kedjan: skicka med mellancertifikaten

En server ska skicka sitt eget certifikat följt av de mellancertifikat som kopplar det till en betrodd rot. Webbläsare lagar ofta ett saknat mellancertifikat ur sin cache, så webbplatsen ser bra ut i er webbläsare medan kommandoradsverktyg, äldre telefoner och andra servrar som anropar ert API misslyckas.

Kontrollera kedjan som servern faktiskt skickar:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Leta efter Verify return code: 0 (ok) och efter mer än ett certifikat i utskriften. Använd filen med hela kedjan (full chain) som certifikatutfärdaren eller ACME-klienten ger er, inte bara servercertifikatet.

3. Värdnamn: täck alla namn ni använder

Ett certifikat gäller bara för de namn som står i fältet Subject Alternative Name (SAN). Webbläsare bryr sig inte om det äldre fältet Common Name. Se till att certifikatet täcker alla namn som leder till servern, oftast både example.com och www.example.com, och alla andra namn som pekar på samma värd.

Jokerteckencertifikat (wildcard) täcker bara en nivå: *.example.com gäller för shop.example.com men inte för example.com, och inte för eu.shop.example.com. Ett jokerteckencertifikat sprider också en och samma privata nyckel över många tjänster, så en läcka på en av dem drabbar alla. Välj hellre certifikat med namngivna värdar där automatiken gör det enkelt.

Så ser ni vilka namn ett certifikat täcker:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

4. Protokollversioner: bara TLS 1.2 och 1.3

TLS 1.0 och TLS 1.1 avvecklades formellt av IETF 2021 (RFC 8996). RFC 9325 rekommenderar TLS 1.2 som lägsta nivå och TLS 1.3 (RFC 8446) där det finns. Att fortfarande erbjuda de gamla versionerna hjälper sällan någon verklig användare och är ett synligt tecken på att konfigurationen inte har setts över.

På nginx, till exempel:

ssl_protocols TLSv1.2 TLSv1.3;

Testa att de gamla versionerna nekas. Lyckas handslaget här tar servern fortfarande emot TLS 1.1 (er lokala OpenSSL måste själv stödja versionen för att testet ska säga något):

openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

5. Chiffer: forward secrecy och AEAD

Med TLS 1.2 väljer servern bland de chiffersviter ni tillåter. Tillåt bara sviter med forward secrecy (nyckelutbyte med ECDHE) och autentiserad kryptering (AES-GCM eller ChaCha20-Poly1305). Stäng av RC4, DES och 3DES, export- och NULL-sviter och allt som bygger på MD5. TLS 1.3 har en kort, fast lista och behöver ingen justering.

Skriv inte chifferlistan för hand. Utgå från Mozilla SSL Configuration Generator med profilen ”intermediate”, som ger en testad konfiguration för vanliga servrar.

6. HSTS: låt inte första anropet gå okrypterat

En omdirigering från http:// till https:// skyddar besökaren först efter det första anropet, som fortfarande skickas okrypterat och kan avlyssnas. HTTP Strict Transport Security (RFC 6797) talar om för webbläsaren att alltid använda HTTPS för er webbplats framöver, och att inte låta användaren klicka sig förbi certifikatvarningar.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Börja med ett kort max-age, några timmar, för att se att inget går sönder, och höj sedan. Lägg bara till includeSubDomains när alla subdomäner har HTTPS, eftersom webbläsarna sparar headern och den är svår att ångra. Preload-listan tar bort även det första okrypterade anropet, men kräver max-age på minst ett år, includeSubDomains och preload, och det tar tid att komma bort från den. Guiden om säkerhetsheaders går igenom HSTS tillsammans med de andra headrarna.

7. CAA: bestäm vilka som får utfärda certifikat

En CAA-post (RFC 8659) anger vilka certifikatutfärdare som får utfärda certifikat för er domän. Allmänt betrodda utfärdare måste kontrollera den innan de utfärdar, så en beställning hos någon annan utfärdare nekas.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

Exemplet tillåter en utfärdare, förbjuder jokerteckencertifikat och ber om rapporter när en beställning nekas. Lista innan ni publicerar alla utfärdare som ni och era leverantörer faktiskt använder, även CDN-tjänster och webbhotell som beställer certifikat åt er, annars börjar deras förnyelser att misslyckas.

8. Certificate Transparency: vet vad som har utfärdats

Allmänt betrodda certifikat förs in i offentliga loggar för Certificate Transparency, CT (RFC 6962), och de stora webbläsarna kräver det. Vem som helst kan söka i loggarna, och det gäller åt båda håll:

• ni kan se varje certifikat som utfärdats för er domän, och upptäcka ett som ni inte har beställt
• alla andra kan se varje värdnamn ni har lagt i ett certifikat, även namn på test- och interna miljöer

Sök i loggarna efter er domän då och då, till exempel på crt.sh, eller använd en tjänst som bevakar CT-loggarna. Behandla ett oväntat certifikat som en säkerhetshändelse. Håll interna värdnamn borta från offentliga certifikat där det går.

Så rapporterar TrustSek detta

Modulen TLS och webbhygien gör en TLS-anslutning till port 443 på den domän ni anger, plus ett anrop över HTTPS och ett över HTTP, som en webbläsare skulle göra. Den läser certifikatet och den protokollversion och det chiffer som handslaget landar i. Det är en avläsning vid ett enda tillfälle, av just den värden.

Fynden står på engelska, så som TrustSek rapporterar dem i dag.

En webbplats helt utan HTTPS rapporteras för sig, och ett certifikat som finns på abuse.ch SSL Blacklist ger ett fynd med allvarlighetsgrad Kritisk. Certificate Transparency används på ett annat sätt: TrustSek läser CT-loggarna för att kartlägga era subdomäner i modulen attackyta.

Det här kontrolleras inte, så kontrollera det själva med kommandona ovan:

• Att kedjan är hel och att värdnamnen stämmer. Kontrollen validerar inte kedjan som servern skickar eller om namnen i certifikatet stämmer.
• Alla versioner och chiffer som servern accepterar. Ett handslag visar vad servern kommer överens om med en modern klient. En server som tar emot TLS 1.0 vid sidan av TLS 1.3 väljer 1.3, och den gamla versionen flaggas inte.
• Andra värdar. Kontrollen ansluter bara till den domän ni anger. Subdomäner, e-postservrar och API:er på andra namn behöver kontrolleras var för sig.
• Detaljer i HSTS. Kontrollen rapporterar om headern finns, inte dess max-age eller direktiv.

Att det inte blir något fynd betyder att inget av ovanstående syntes vid den avläsningen. Det betyder inte att värden är säker. Metoden förklarar hur allvarlighetsgraden påverkar poängen.

Kontrollera er domäns certifikat och TLS

Se vilket certifikat, vilket protokoll och vilka headers er domän har i dag, tillsammans med e-postsäkerhet och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.