SSL- och säkerhetskoll
Kontrollera en sajts SSL-certifikat (utfärdare, giltighet, utgångsdatum) och vilka säkerhetsheaders servern skickar.
Så tolkar du resultatet
Verktyget kontrollerar två separata saker samtidigt, dels själva SSL-certifikatet, dels de säkerhetsheaders servern faktiskt skickar med varje svar. Det är lätt att blanda ihop dem, men de säger olika saker om en sajts säkerhet och behöver läsas var för sig.
Certifikatdelen visar utfärdaren (till exempel Let's Encrypt eller ett kommersiellt certifikatbolag), giltighetsperioden med start- och slutdatum, samt en badge som räknar dagar kvar. Den är grön så länge det är gott om tid, gul när färre än 14 dagar återstår, och röd om certifikatet redan gått ut. SAN-listan (Subject Alternative Name) visar exakt vilka domännamn certifikatet faktiskt gäller för, vilket kan vara fler än en, till exempel både www-versionen och roten, eller flera underdomäner i samma certifikat. Kedjelängden anger hur många certifikat som ligger mellan sajtens eget certifikat och en rot som webbläsaren litar på direkt. En ofullständig kedja är en av de vanligaste, och mest förbisedda, orsakerna till att en sajt ändå visas som osäker trots ett i grunden giltigt certifikat.
Headerdelen kontrollerar sex specifika säkerhetsheaders och markerar varje med en grön bock eller ett rött kryss. HSTS (HTTP Strict Transport Security) tvingar webbläsaren att alltid använda https för domänen, även om någon råkar skriva http. CSP (Content Security Policy) begränsar varifrån sidan får ladda skript och andra resurser, ett skydd mot vissa typer av intrångsförsök. X-Frame-Options hindrar att sidan visas inbäddad i en iframe på en annan sajt, ett skydd mot så kallad clickjacking. X-Content-Type-Options hindrar webbläsaren från att gissa filtyp på ett sätt som kan missbrukas. Referrer-Policy styr hur mycket information om varifrån besökaren kom som skickas vidare till nästa sajt. Permissions-Policy begränsar vilka webbläsarfunktioner (kamera, mikrofon, plats) sidan får begära åtkomst till.
Vanliga utfall och vad de faktiskt betyder
Samma certifikatstatus tolkas ofta fel, särskilt skillnaden mellan olika typer av "Ej säker"-varningar. Här är fem utfall som regelbundet missförstås.
| Vad du ser i resultatet | Vad det betyder i praktiken |
|---|---|
| Badgen är röd, certifikatet har gått ut | Den vanligaste orsaken bakom en "Ej säker"-varning i webbläsaren. Nästan alltid ett tecken på att automatisk förnyelse har fallerat tyst, ofta för att en DNS-utmaning eller filbehörighet slutat fungera utan att någon märkt det. |
| Kedjelängden ser kort ut, bara certifikatets eget led | En ofullständig certifikatkedja. Servern skickar inte med mellanledscertifikaten som knyter det egna certifikatet till en rot webbläsaren litar på. Vissa webbläsare accepterar det ändå eftersom de redan har mellanledet cachat, medan andra (särskilt på mobil eller äldre enheter) visar en varning. |
| SAN-listan innehåller inte den exakta domän du testade | Certifikatet gäller för fel namn. Vanligt vid en flytt där certifikatet förnyats för www-versionen men inte för roten, eller tvärtom, så att bara en av de två varianterna faktiskt är skyddad. |
| Alla sex headers visar rött kryss | Betyder inte automatiskt att sajten är osäker i grunden. Många mindre webbplatser saknar samtliga extra säkerhetsheaders utan att för den sakens skull vara sårbara. Det är ett kompletterande skydd ovanpå en fungerande https-uppkoppling, inte en förutsättning för den. |
| Giltigt certifikat men webbläsaren varnar ändå | Kontrollera om varningen faktiskt handlar om certifikatet eller om sidan laddar in osäkert (http-baserat) innehåll, till exempel bilder eller skript, på en i övrigt https-skyddad sida. Det kallas blandat innehåll och ger ofta en varning trots ett giltigt certifikat. |
Fyra vanliga orsaker bakom "Ej säker"
Ser en besökare "Ej säker" i adressfältet beror det nästan alltid på en av fyra saker. Certifikatet har gått ut och ingen har märkt det. Kedjan är ofullständig så att webbläsaren inte kan verifiera hela vägen till en betrodd rot. Certifikatet gäller för fel domännamn, till exempel bara för roten men sidan besöks via en underdomän. Eller så finns det helt enkelt inget https alls konfigurerat, och sajten körs fortfarande rakt över http. Är felet av den sista typen, att https saknas helt, är det första steget att skaffa ett certifikat och sedan se till att all trafik omdirigeras dit. Vår redirect-kollare visar om övergången från http till https faktiskt sker med en korrekt 301-omdirigering, eller om den saknas.
Ett par av dessa orsaker rör en DNS-post som få känner till, nämligen CAA (Certificate Authority Authorization). Den anger vilka certifikatutfärdare som över huvud taget får utfärda certifikat för domänen. Saknas posten får i princip vem som helst utfärda, vilket sällan är ett problem i praktiken men värt att känna till om ett certifikat plötsligt inte kan förnyas hos en specifik leverantör. Vi nämner CAA-posten i sitt DNS-sammanhang i artikeln om DNS-poster vid byte av webbhotell.
Vad verktyget inte kan se
Vi kontrollerar det certifikat och de headers som servern faktiskt skickar just nu, från en extern anslutning. Det ger en korrekt ögonblicksbild men fångar inte historik, till exempel hur länge ett problem funnits, och inte heller interna serverinställningar som inte påverkar det som skickas ut till besökaren. En sajt bakom en CDN eller en proxy kan dessutom visa ett certifikat som hör till CDN-tjänsten snarare än till ursprungsservern, vilket är helt normalt men värt att känna till vid tolkningen. Driftar du själv en server och vill härda den ytterligare, utöver certifikat och headers, går vi igenom det bredare i artikeln om att härda en VPS. Vill du läsa mer om hur Google Chrome själv resonerar kring varningar för osäkra sidor finns bakgrunden hos Googles egen hjälpsida om säkerhetsvarningar.
Vad gör du nu
Är badgen röd eller gul, kontrollera först om automatisk förnyelse är aktiverad hos webbhotellet eller hos den certifikatutfärdare som används, eftersom en fallerad förnyelse är den vanligaste orsaken. Är kedjan ofullständig behöver mellanledscertifikaten läggas till i serverns konfiguration, något webbhotellets support i regel kan hjälpa till med om du inte hanterar servern själv. Det är samtidigt det utfall som är lättast att avfärda, eftersom din egen webbläsare i regel hämtar det saknade mellanledet på egen hand medan maskinklienter inte gör det. Vad som går tyst sönder när det händer, från betalningswebhookar till länkförhandsvisningar, går vi igenom i artikeln om varför ett grönt hänglås inte betyder att SSL fungerar för alla besökare. Saknas headers helt är det inget akut, men värt att lägga till stegvis om sajten hanterar inloggning, formulär eller känslig information, eftersom de fungerar som ett extra lager skydd ovanpå ett i övrigt giltigt certifikat.