Vad är SSL? Allt du behöver veta om certifikat och kryptering
De flesta "vad är SSL"-sidor är skrivna av säljare. Den här är skriven av personer som har arbetat med PKI och certifikat i över 16 år.
Vi förklarar SSL/TLS på tre nivåer: från grunderna (vad är hänglåset?) via den tekniska mekaniken (handshakes, certifikatkedjor, nyckeltyper) till avancerade ämnen för IT-proffs (cipher suites, Certificate Transparency, trust stores, ACME). Hoppa till den nivå som passar dig.
Nivå 1: Grunderna
Vad är ett SSL-certifikat?
Ett SSL-certifikat är en liten datafil som installeras på en webbserver. Det löser tre grundläggande problem:
Identitet: Är det verkligen banken?
När du besöker www.din-bank.se garanterar certifikatet att du faktiskt kommunicerar med bankens server och inte en angripare. En oberoende certifikatutfärdare (CA) har kontrollerat ägarens identitet och signerat certifikatet digitalt, så att din webbläsare kan lita på det.
Kryptering: Ingen kan avlyssna
Din webbläsare och servern upprättar själva en krypterad anslutning. Certifikatet utför inte själva krypteringen, men säkerställer under uppkopplingen att du förhandlar med rätt server och inte en angripare emellan.
När anslutningen har upprättats krypteras all data. Ingen på vägen kan läsa innehållet. Inte ens din internetleverantör kan se vad du skickar eller tar emot, bara vilken server du besöker.
Dataintegritet: Ingen kan ändra data på vägen
Om någon försöker ändra data på vägen upptäcker mottagaren det omedelbart och avbryter anslutningen. Det förhindrar angripare från att infoga falsk information eller skadlig kod i dataströmmen mellan dig och servern.
SSL vs TLS: Vad är skillnaden?
SSL (Secure Sockets Layer) var det ursprungliga protokollet från Netscape. Det är föråldrat och osäkert. Alla moderna anslutningar använder efterföljaren TLS (Transport Layer Security). Branschen använder fortfarande "SSL" som samlingsbegrepp, men certifikatet är detsamma oavsett TLS-version.
Utvecklad av Netscape. Så osäker att den aldrig togs i bruk.
Första offentliga versionen. Fundamentalt osäker.
Bättre, men bruten av POODLE-attacken (2014). Föråldrad.
IETF tog över utvecklingen och döpte om protokollet. Borttaget av webbläsare 2020.
Marginella förbättringar. Borttaget av webbläsare 2020.
Fortfarande utbredd. Säker med korrekt konfiguration (enbart ECDHE + AEAD).
Aktuell standard (RFC 8446). Tog bort alla osäkra algoritmer. Snabbare handshake. Forward secrecy som standard.
HTTP vs HTTPS
HTTP skickar data i klartext. Alla mellan dig och servern kan avlyssna trafiken: internetleverantörer, wifi-hotspot-ägare, varje router på vägen. HTTPS lägger till TLS-kryptering, så data blir oläsbart för alla andra än avsändare och mottagare.
Alla moderna webbläsare markerar HTTP-sidor som "Inte säker". Google använder HTTPS som rankningssignal, och många webbteknologier (HTTP/2, Service Workers, Geolocation API) kräver HTTPS. Det finns ingen bra anledning att köra HTTP idag.
De tre valideringstyperna
Certifikat finns med olika nivåer av identitetsverifiering. Valideringstypen bestämmer hur noggrant CA:n har granskat dig som certifikatägare, inte hur stark krypteringen är (den är densamma):
Bekräftar att du kontrollerar domänen via DNS- eller HTTP-challenge. Automatiskt utfärdande, vanligtvis under 2 minuter med ACME. Billigast. Inga företagsuppgifter i certifikatet.
Bekräftar även din företagsregistrering mot offentliga register. Företagsnamnet står i certifikatets Organization-fält. FairSSL utför OV-validering på svenska för GlobalSign, vanligtvis under 1 timme.
Strängaste verifieringen med juridisk, operativ och fysisk bekräftelse. Visar företagsnamn och land i certifikatet. Krävs för code signing-certifikat och vissa branscher.
Alla tre typer ger samma krypteringsstyrka. Webbläsare visar inte längre ett grönt fält för EV (Chrome tog bort det i version 77, september 2019, och andra webbläsare följde efter). Företagsuppgifterna finns fortfarande i certifikatet, men användare måste klicka på hänglåset för att se dem.
Certifikattyper: Single Domain, Wildcard och SAN
- Single Domain: Täcker en specifik domän, t.ex.
www.ditt-doman.se. De flesta DV-certifikat inkluderar automatiskt bådewwwoch basdomänen som SAN (Subject Alternative Name). - Wildcard: Täcker alla subdomäner på en nivå under en domän, t.ex.
*.ditt-doman.se(täckerwww,mail,apiosv.). Täcker inte basdomänenditt-doman.sesjälv, om den inte är tillagd som extra SAN. Täcker inte heller djupare nivåer somsub.api.ditt-doman.se. - Multi-Domain (SAN): Täcker en lista av specifika namn, som kan vara från helt olika domäner:
ditt-doman.se,ditt-doman.com,din-webshop.se. Antalet tillåtna SAN:er varierar per produkt (vanligtvis 25-250).
Valet beror på din infrastruktur. Wildcard är enklare att administrera, men alla servrar delar samma privata nyckel. Om en server komprometteras kan nyckeln användas för att utge sig för vilken subdomän som helst. SAN-certifikat ger mer kontroll och kan blanda domäner fritt. Se vår wildcard SSL-sida och multi-domain SSL-sida för detaljerad jämförelse.
Nivå 2: Så fungerar det tekniskt
TLS-handshake: Vad händer när du öppnar en HTTPS-sida?
När din webbläsare ansluter till en HTTPS-server utförs ett TLS-handshake. I TLS 1.3 tar det en roundtrip (vanligtvis 50-100 ms). Syftet är att komma överens om en krypteringsnyckel, utan att nyckeln någonsin skickas över nätet:
- 1 Client Hello. Webbläsaren skickar en lista över stödda TLS-versioner, cipher suites och nyckelutbytesparametrar (key shares). I TLS 1.3 skickar webbläsaren redan sin nyckelandel i första meddelandet, så att servern kan svara direkt.
- 2 Server Hello + certifikat. Servern väljer cipher suite och skickar sin nyckelandel. Därefter skickar servern sitt certifikat (med den offentliga nyckeln och hela certifikatkedjan) i ett krypterat meddelande, skyddat av den just överenskomna nyckeln.
- 3 Certifikatverifiering. Webbläsaren kontrollerar: är certifikatet utfärdat av en betrodd CA? Har det inte löpt ut? Matchar domännamnet (i SAN-fältet)? Är det loggat i Certificate Transparency? Är det återkallat? Bygger kedjan korrekt upp till en betrodd rot?
- 4 Sessionsnycklar. Redan i steg 1-2 utbytte webbläsaren och servern nyckelandelar via Elliptic Curve Diffie-Hellman (ECDHE). Dessa kombineras till en delad hemlighet som används för att härleda sessionsnycklar. Den privata nyckeln skickas aldrig över nätet. Även om någon fångar upp hela handskaket kan de inte beräkna sessionsnyckeln.
- 5 Krypterad kommunikation. All efterföljande trafik krypteras med sessionsnyckeln (symmetrisk kryptering, vanligtvis AES-256-GCM eller ChaCha20-Poly1305). Symmetrisk kryptering är storleksordningar snabbare än asymmetrisk.
TLS 1.3 vs 1.2: TLS 1.2 använder två roundtrips (dubbel latens). Den tillåter även RSA key exchange (utan forward secrecy), CBC-mode ciphers (sårbara för padding oracle-attacker) och en lång rad osäkra konfigurationer. TLS 1.3 tog bort allt det. Om din server fortfarande erbjuder TLS 1.0 eller 1.1 bör de avaktiveras. Alla moderna webbläsare har tagit bort stödet för dem.
Vad finns inuti ett certifikat? (X.509-anatomi)
Ett SSL-certifikat är ett X.509v3-certifikat kodat i ASN.1 DER-format (vanligtvis Base64-inkapslat som PEM). Det innehåller:
SAN (Subject Alternative Name) är det fält som faktiskt bestämmer vilka domännamn certifikatet täcker. CN (Common Name) i Subject-fältet används historiskt, men moderna webbläsare ignorerar CN och använder uteslutande SAN. Ett certifikat utan SAN kommer att avvisas.
Certifikatkedjan: Root, intermediate och leaf
Ditt SSL-certifikat (leaf-certifikatet) är en del av en tillitskedja. Webbläsaren verifierar kedjan från ditt certifikat och upp till en betrodd rot:
Rotcertifikat är förinstallerade i trust stores som underhålls av fyra stora rotprogram: Microsoft (Windows/Edge), Apple (macOS/iOS/Safari), Mozilla (Firefox) och Google (Chrome Root Store, lanserat 2023). För att bli upptagen måste CA:n klara en WebTrust- eller ETSI-revision och följa CA/Browser Forum Baseline Requirements.
Din server måste skicka hela kedjan (leaf + intermediate), men inte rotcertifikatet (webbläsaren har det redan). Ordningen är viktig: leaf först, sedan intermediates i stigande ordning.
Vanligt fel: Om servern bara skickar leaf-certifikatet utan intermediate kan webbläsare på vissa plattformar inte verifiera kedjan. Desktop-Chrome kan ofta själv hitta det saknade intermediate (via Authority Information Access), men mobila webbläsare och curl/Python misslyckas. Kontrollera alltid kedjan med vår SSL Scanner.
Cross-signing i praktiken: När en CA har en ny rot som ännu inte finns i alla trust stores kan den cross-signera sitt intermediate med en äldre, brett betrodd rot. Let's Encrypt använde detta: deras ISRG Root X1 var cross-signerad av IdenTrust DST Root CA X3 för att uppnå kompatibilitet med äldre enheter. När DST Root CA X3 löpte ut den 30 september 2021 bröt det certifikatverifieringen på äldre Android-enheter, OpenSSL 1.0.x och många IoT-enheter världen över.
Nyckeltyper: RSA vs ECDSA
Certifikatets nyckeltyp bestämmer vilken kryptografisk algoritm som används för att signera och verifiera certifikatet. Det finns två vanliga typer:
| Egenskap | RSA | ECDSA (P-384) |
|---|---|---|
| Nyckelstorlek | 2048 eller 4096 bitar | 384 bitar |
| Säkerhetsnivå | RSA 2048 ≈ 112 bitar, RSA 4096 ≈ 140 bitar | P-384 ≈ 192 bitar |
| Handshake-hastighet | Långsam (stor nyckel, tung beräkning) | Snabb (liten nyckel, effektiv) |
| Bandbredd | Större certifikat (256-512 byte för nyckel) | Litet certifikat (96 byte för nyckel) |
| Kompatibilitet | Alla plattformar | Alla moderna plattformar (Windows Vista+, Android 4+) |
Vi rekommenderar ECDSA P-384 eller RSA 3072 för nya installationer. P-384 ger snabbare handshakes än RSA, använder mindre bandbredd och har en säkerhetsnivå motsvarande RSA 7680 bitar. P-384 är fortfarande så snabb att den marginella hastighetsskillnaden mot P-256 inte motiverar den lägre säkerhetsnivån. RSA 3072 är det uppenbara valet om du behöver RSA-kompatibilitet. Undvik RSA 2048, då det kommer att vara det första som blockeras när kraven skärps.
Nyckeltypen i certifikatet är oberoende av TLS-anslutningens cipher suite. Du kan ha ett RSA-certifikat och ändå använda ECDHE för nyckelutbyte (och därmed forward secrecy). TLS 1.3 kräver alltid ECDHE, oavsett certifikattyp.
Certifikatets livstid och förnyelse
Certifikat har en begränsad teknisk livstid. CA/Browser Forum, det internationella organ som fastställer reglerna för SSL-branschen, har beslutat om en aggressiv minskning av den maximala livstiden:
Syftet med kortare livstider är att minska skadans omfattning om en nyckel komprometteras, och att tvinga fram automatisering av certifikathantering. Med 47-dagars certifikat 2029 är manuell förnyelse inte realistisk för någon infrastruktur av nämnvärd storlek.
Automatisering via ACME-protokollet är svaret. Läs mer om SSL-automatisering och den fullständiga tidslinjen för SSL-livslängd.
Nivå 3: För IT-proffs
Cipher suites och forward secrecy
En cipher suite är den specifika kombinationen av algoritmer som används i en TLS-anslutning: nyckelutbyte, signaturalgoritm, symmetrisk kryptering och hash. TLS 1.3 gallrade kraftigt. Där TLS 1.2 hade hundratals möjliga kombinationer (många osäkra) har TLS 1.3 bara fem:
Nyckelutbyte ingår inte i cipher suite-namnet i TLS 1.3, eftersom det alltid är ephemeral Diffie-Hellman (ECDHE med X25519 eller P-256, eller DHE med ffdhe2048+). RSA key exchange är helt borttaget. Det ger forward secrecy som standard: varje session använder unika, tillfälliga nycklar. Även om serverns privata nyckel komprometteras i framtiden kan uppfångad trafik inte dekrypteras i efterhand. Underrättelsetjänster är kända för att samla in krypterad trafik för framtida dekryptering ("collect now, decrypt later").
Om du fortfarande kör TLS 1.2 (t.ex. för kompatibilitet med äldre system) bör du explicit bara tillåta säkra suites och tvinga forward secrecy. En bra TLS 1.2-konfiguration tillåter bara ECDHE-baserade suites med AEAD-ciphers (AES-GCM, ChaCha20-Poly1305). Undvik CBC-mode (sårbar för padding oracle) och RSA key exchange (ingen forward secrecy).
Cipher suites: Vad du bör använda, och vad du bör undvika
| Cipher suite | Status | Kommentar |
|---|---|---|
| TLS_AES_256_GCM_SHA384 | Rekommenderad | TLS 1.3. Starkaste standardvalet. |
| TLS_CHACHA20_POLY1305_SHA256 | Rekommenderad | TLS 1.3. Snabb på enheter utan AES-NI (mobil, ARM). |
| TLS_AES_128_GCM_SHA256 | OK | TLS 1.3. Obligatorisk i standarden. Acceptabel säkerhet. |
| ECDHE-ECDSA-AES256-GCM-SHA384 | Acceptabel | TLS 1.2. Bästa valet med ECDSA-certifikat. Forward secrecy + AEAD. |
| ECDHE-RSA-AES256-GCM-SHA384 | Acceptabel | TLS 1.2. Bästa valet med RSA-certifikat. Forward secrecy + AEAD. |
| AES256-SHA256 | Undvik | RSA key exchange. Ingen forward secrecy. Uppfångad trafik kan dekrypteras om nyckeln läcker. |
| ECDHE-RSA-AES128-SHA | Undvik | CBC-mode. Sårbar för padding oracle-attacker (BEAST, Lucky13). |
| DES-CBC3-SHA | Farlig | 3DES. Bruten (Sweet32-attack). Aldrig acceptabel. |
| RC4-SHA | Farlig | RC4 är fundamentalt bruten. Förbjuden i RFC 7465. |
Fallgropen med den "perfekta" A+-konfigurationen
Det är frestande att härda sin TLS-konfiguration till att bara tillåta de nyaste och starkaste cipher suites. Men i praktiken kan en alltför aggressiv konfiguration skapa verkliga problem:
- Äldre e-postservrar (Exchange 2010/2013, äldre SMTP-relayer) stödjer ofta bara TLS 1.0/1.1 med CBC-ciphers. Om din e-postserver avvisar dem faller avsändare ner till okrypterad SMTP, och dina e-postmeddelanden skickas i klartext.
- Äldre mobiltelefoner (Android 4.x, äldre IoT-enheter) saknar stöd för TLS 1.2 och AEAD-ciphers. Användare får en felsida utan förklaring.
- Betalningsgateways och API-integrationer använder ofta äldre TLS-stackar. En stram konfiguration kan bryta kritiska affärsprocesser.
- Interna system (skrivare, skannrar, övervakningskameror) kör sällan uppdaterad firmware och stödjer kanske bara äldre ciphers.
Vår rekommendation: Börja med Mozillas "Intermediate"-profil från SSL Configuration Generator. Den ger en bra balans mellan säkerhet och kompatibilitet. Härda sedan gradvis, baserat på vad dina klienter faktiskt stödjer. Använd loggning för att identifiera vilka cipher suites som verkligen används innan du tar bort dem.
En A+-poäng på SSL Labs är meningslös om hälften av dina användare eller integrationer inte kan ansluta. Säkerhet handlar om att skydda kommunikation, inte om att samla poäng i ett test.
Använd vår SSL Scanner för att kontrollera din konfiguration. För konfigurationsverktyg: Mozillas SSL Configuration Generator genererar säkra konfigurationer för Apache, Nginx, HAProxy m.fl. På Windows är IIS Crypto det enklaste verktyget för att härda TLS-konfigurationen på IIS och Remote Desktop. Se även vår guide till Mozilla SSL Configuration Generator.
Trust stores och rotprogram
Hela PKI-systemets tillit börjar med rotcertifikat som är förinstallerade på din dator eller enhet. Dessa rötter underhålls av fyra stora program med var sina regler och revisioner:
Används av Windows, Edge och alla .NET-applikationer. Uppdateras via Windows Update. Kräver årlig WebTrust-revision.
Används av macOS, iOS och Safari. Uppdateras via OS-uppdateringar. Strikta krav på CT-loggning.
Används av Firefox och många open source-projekt. Den mest transparenta processen. Många Linux-distributioner använder Mozillas rötter.
Lanserat 2023. Chrome använde tidigare OS-truststore, men har nu sin egen. Kräver Certificate Transparency och ACME-stöd för nya upptaganden. Använder CCADB (Common CA Database) som delad infrastruktur med Mozilla.
Valet av CA (certifikatutfärdare) har betydelse. Inte alla CA:er har rötter i alla trust stores, och inte alla rötter har samma täckning på olika plattformar. En svag rot kan innebära att ditt certifikat inte fungerar på äldre Android-enheter eller i specifika företagsmiljöer. FairSSL säljer från DigiCert, GlobalSign och Sectigo, eftersom de tre har den bredaste och mest stabila rottäckningen.
Certificate Transparency (CT)
Certificate Transparency (RFC 6962) är ett offentligt, append-only loggsystem där alla utfärdade SSL-certifikat registreras. Systemet föreslogs av Google 2013, främst motiverat av DigiNotar-skandalen 2011, då en komprometterad CA utfärdade falska certifikat för bl.a. google.com. CT bidrog senare till att avslöja Symantecs obehöriga certifikatutfärdanden (2015-2017), vilket ledde till att Symantecs rot togs bort från alla webbläsare.
Alla offentliga CA:er är skyldiga att logga certifikat i minst två till tre oberoende CT-loggar innan certifikatet är giltigt. CA:n tar emot en Signed Certificate Timestamp (SCT) från varje logg, som bäddas in i certifikatet (eller levereras via OCSP stapling eller TLS extension). Webbläsare kräver SCT:er och avvisar certifikat utan dem. Chrome kräver minst två SCT:er från olika loggoperatörer.
Du kan övervaka CT-loggar för din domän via crt.sh eller Googles Transparency Report. Det är gratis och visar alla certifikat som utfärdats för din domän. Sätt upp övervakning för din domän.
OCSP, CRL och återkallelse
När ett certifikat behöver återkallas (komprometterad nyckel, felutfärdande, upphört domänägande) måste webbläsare och klienter veta det. Det finns tre mekanismer:
- CRL (Certificate Revocation List): En komplett lista över återkallade certifikat från den aktuella CA:n. Webbläsaren laddar ner listan och kontrollerar serienumret. Listorna kan bli stora (flera MB) och uppdateras vanligtvis var 1-24 timme. Skalerar dåligt.
- OCSP (Online Certificate Status Protocol): Webbläsaren skickar certifikatets serienummer till CA:ns OCSP-responder och får ett signerat svar ("good", "revoked" eller "unknown"). Realtidskontroll, men skapar ett integritetsproblem (CA:n kan se vilka sidor du besöker) och ett tillgänglighetsproblem (vad händer om OCSP-servern är nere?). Många webbläsare gör "soft-fail": om OCSP-servern inte svarar accepterar de certifikatet ändå.
- OCSP Stapling: Servern hämtar själv OCSP-svaret från CA:n periodiskt (t.ex. var 4:e timme) och skickar det signerade svaret tillsammans med certifikatet under TLS-handshake. Webbläsaren behöver inte kontakta CA:n. Inget integritetsläckage, ingen extra latens. Aktivera det med
ssl_stapling on;i Nginx ellerSSLUseStapling Oni Apache.
Vår rekommendation: Aktivera OCSP Stapling. Det är den enda revocation-mekanism som verkligen fungerar för alla klienter utan integritetsproblem. Servern levererar beviset proaktivt, och klienten behöver inte göra externa uppslag.
Återkallelse är i praktiken bruten
Google Chrome kontrollerar varken CRL eller OCSP för vanliga certifikat. Googles argument är att OCSP-uppslag ger CA:er möjlighet att spåra användares besöksmönster, och att soft-fail (acceptera certifikatet om OCSP-servern inte svarar) gör mekanismen meningslös mot aktiva angripare.
Istället använder Chrome sin egen CRLite-lista, som bara täcker de största och mest kritiska sajterna. Resultatet är att återkallelse av ett certifikat för en vanlig domän i praktiken inte skyddar Chrome-användare. Certifikatet visas fortfarande som giltigt, även efter återkallelse. Firefox och andra webbläsare kontrollerar fortfarande OCSP/CRL, men med Chrome på över 65 % marknadsandel är det majoriteten av användarna som inte är skyddade.
Det har konkreta säkerhetskonsekvenser: om din privata nyckel komprometteras kan en angripare fortsätta använda certifikatet mot Chrome-användare, även efter att du har återkallat det hos CA:n. Certifikatet fungerar tills det löper ut.
Därför bör du:
- Undvik wildcard-certifikat på rotnivå för kritiska domäner. Om
*.ditt-doman.sekomprometteras kan du inte återkalla det effektivt, och angriparen kan utge sig för vilken subdomän som helst. - Se till att du kan byta FQDN i en nödsituation. Om du kan peka trafiken till ett nytt hostname kan du undvika en man-in-the-middle-attack med det komprometterade certifikatet.
- Använd korta certifikatlivstider, men lita inte enbart på dem. Googles argument är att korta livstider (47 dagar 2029) minskar skadans omfattning tillräckligt för att göra återkallelse överflödig. Det håller vi inte med om. 47 dagar är gott och väl för att orsaka allvarlig skada, och även några dagar med ett komprometterat certifikat kan vara katastrofalt om timingen är rätt. Korta livstider hjälper, men ersätter inte verklig återkallelse.
Let's Encrypt fasade ut OCSP helt 2025. Trenden är tydlig: branschen rör sig mot korta livstider som ersättning för återkallelse. Det gör ACME-automatisering ännu mer kritisk.
CAA records: Begränsa vem som kan utfärda
DNS CAA records (Certification Authority Authorization, RFC 8659) är en enkel mekanism som talar om för CA:er om de har rätt att utfärda certifikat för din domän. Alla CA:er är skyldiga att kontrollera CAA innan de utfärdar. Om din CAA record bara tillåter DigiCert kan varken Sectigo, Let's Encrypt eller någon annan CA utfärda till din domän.
iodef-recorden i exemplet är ett notifieringssystem: om en CA som inte finns i din CAA-lista tar emot en begäran om att utfärda ett certifikat för din domän, ska den skicka en rapport till angiven e-post eller URL. Det ger dig besked om obehöriga utfärdandeförsök, oavsett om de lyckas eller inte.
CAA är enkel att sätta upp och ger en stark säkerhetsgaranti. Använd FairSSLs CAA record-generator för att bygga din konfiguration.
HPKP (HTTP Public Key Pinning): Utgången och farlig
HPKP (RFC 7469) var en HTTP-header som pinnade specifika offentliga nycklar i webbläsaren. När en användare besökte din sajt kom webbläsaren ihåg vilka nycklar den hade sett, och avvisade framtida anslutningar med andra nycklar under hela pin-perioden (vanligtvis 60 dagar).
Tanken var att förhindra man-in-the-middle-attacker med falska certifikat: även om en angripare fick en CA att utfärda ett certifikat för din domän skulle webbläsaren avvisa det, eftersom nyckeln inte matchade den pinnade.
Varför HPKP togs bort
I praktiken visade sig HPKP vara farligare än de attacker den skulle skydda mot:
- Självlåsning. En felkonfiguration, ett förlorat nyckelpar eller ett CA-byte kunde permanent låsa ut alla användare från din sajt i veckor eller månader. Det fanns ingen möjlighet att ångra en aktiv pin.
- HPKP Suicide. Angripare kunde sätta en skadlig pin på en komprometterad sajt och sedan ta bort den riktiga nyckeln. Sajten blev permanent otillgänglig för alla användare som hade tagit emot pinnen.
- Ransomware-vektor. En angripare med tillfällig kontroll över en server kunde sätta en pin till sin egen nyckel och sedan kräva lösensumma för att frigöra domänen.
Alla webbläsare har tagit bort HPKP. Chrome tog bort det i version 72 (januari 2019), Firefox i version 72 (januari 2020). Mozilla har tagit bort HPKP från sina Web Security Guidelines. Om du fortfarande skickar HPKP-headrar gör de ingen skada, men de har ingen effekt.
Ersättningen är CAA records (se ovan). CAA ger liknande skydd mot obehörigt certifikatutfärdande, men utan risken att låsa ut dig själv. CAA upprätthålls av CA:erna (server-side), inte av webbläsarna (klient-side), så en felkonfiguration kan rättas utan att påverka användare.
HSTS och preloading
HTTP Strict Transport Security (RFC 6797) är en HTTP-header som instruerar webbläsare att alltid använda HTTPS:
När webbläsaren har tagit emot denna header kommer den aldrig att försöka en HTTP-anslutning under max-age-perioden (här 2 år). Det skyddar mot SSL-stripping-attacker (t.ex. Moxie Marlinspikes sslstrip), där en angripare nedgraderar anslutningen från HTTPS till HTTP.
HSTS Preloading går ett steg längre: din domän tas upp på en lista som är hårdkodad i webbläsarna. Så även det allra första besöket använder HTTPS (TOFU-problemet elimineras). Ansök via hstspreload.org.
Varning: Preloading är svårt att ta bort. Processen för att komma bort från listan tar månader och kräver att alla webbläsare ger ut en uppdatering. Se till att HTTPS fungerar korrekt på alla subdomäner (inkl. interna) innan du ansöker. includeSubDomains är ett krav för preloading.
Automatisering med ACME
ACME (Automatic Certificate Management Environment, RFC 8555) är ett protokoll för automatiskt utfärdande och förnyelse av certifikat. Let's Encrypt gjorde ACME populärt från 2016, men protokollet är öppet och används av kommersiella CA:er som DigiCert, GlobalSign och Sectigo. Via FairSSLs ACME-server får du DigiCert-familjen och GlobalSign.
ACME validerar domänägande automatiskt via tre challenge-typer:
- HTTP-01: CA:n kontrollerar en specifik fil under
/.well-known/acme-challenge/. Kräver port 80 öppen. Kan inte användas för wildcard. - DNS-01: CA:n kontrollerar en TXT record under
_acme-challenge.dittdoman.se. Kräver DNS API-åtkomst (eller CNAME-delegering). Kan användas för wildcard. - TLS-ALPN-01: CA:n ansluter till port 443 med en speciell ALPN extension. Används av Caddy och i situationer där port 80 är blockerad.
FairSSL erbjuder ACME med AutoDNS-validering: skapa en permanent CNAME-vidarebefordran från _dnsauth.dittdoman.se till FairSSLs valideringsinfrastruktur. Då hanteras DNS-validering automatiskt, utan att du behöver ge DNS API-nycklar till servrar.
ACME Renewal Information (ARI, RFC 9773) är den senaste utvidgningen: CA:n kan tala om för din ACME-klient exakt när den bör förnya, t.ex. för att ett certifikat återkallas eller ett intermediate byts ut. Med 47-dagars certifikat 2029 blir timing för förnyelse kritisk. Läs mer om SSL-automatisering med FairSSL.
Vanliga fel och felsökning
De vanligaste felen:
Servern skickar bara leaf-certifikatet. Fungerar i Chrome (som kan hitta intermediate via AIA), men misslyckas i curl, Python, mobilappar och CI/CD-pipelines. Lösning: installera hela kedjan.
Sidan använder HTTPS, men laddar bilder, scripts eller stylesheets över HTTP. Webbläsaren blockerar eller nedgraderar säkerheten. Lösning: alla resurser ska använda HTTPS eller protokollrelativa URL:er.
Certifikatet är utfärdat till www.ditt-doman.se, men servern svarar även på ditt-doman.se (utan www) som inte finns i SAN-fältet. Lösning: inkludera båda namnen i certifikatet, eller använd en redirect.
Servern tillåter föråldrade TLS-versioner. Dessa har kända sårbarheter (BEAST, CRIME) och är inte tillåtna under PCI DSS. Alla moderna webbläsare har tagit bort stödet. Lösning: avaktivera TLS 1.0 och 1.1, tillåt bara TLS 1.2 och 1.3.
Produktionssajter får vanligtvis uppmärksamhet, men interna system (adminpaneler, CI/CD, övervakning) glöms ofta bort. Ett utgånget certifikat på en intern tjänst kan bryta hela deployment-pipelinen. Lösning: ACME-automatisering på alla tjänster, inte bara de offentliga.
Vanliga frågor om SSL
Hitta svar på de vanligaste frågorna om SSL-certifikat och FairSSL.
Redo att skapa ett gratis konto?
Skapa ett gratis konto och utfärda ditt första certifikat på under 10 minuter.