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 betyder hänglåset?) via tekniken bakom (handskakning, certifikatkedjor, nyckeltyper) till fördjupning för IT-proffs (chiffersviter, Certificate Transparency, certifikatlager, ACME). Hoppa direkt till den nivå som passar dig.
Ska du bara köpa ett certifikat? Gå direkt till SSL-certifikat och jämför typer och priser.
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 med 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 trafiken
Din webbläsare och servern upprättar en krypterad anslutning sinsemellan. Certifikatet krypterar inte själva trafiken, men när anslutningen sätts upp bekräftar det att du förhandlar med rätt server och inte med en angripare som sitter 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 hindrar angripare från att föra in falsk information eller skadlig kod i dataströmmen mellan dig och servern.
SSL och 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. Osäker i grunden.
Bättre, men knäckt av POODLE-attacken (2014). Föråldrad.
IETF tog över utvecklingen och döpte om protokollet. Webbläsarna tog bort stödet 2020.
Marginella förbättringar. Webbläsarna tog bort stödet 2020.
Fortfarande utbredd. Säker med rätt konfiguration (endast ECDHE + AEAD).
Aktuell standard (RFC 8446). Tog bort alla osäkra algoritmer. Snabbare handskakning. Forward secrecy som standard.
HTTP och HTTPS
HTTP skickar data i klartext. Alla som befinner sig mellan dig och servern kan avlyssna trafiken: internetleverantören, den som driver ett publikt wifi, varje router på vägen. HTTPS lägger till TLS-kryptering, så att innehållet blir oläsbart för alla utom avsändaren och mottagaren.
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 fortsätta med HTTP.
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-validering. Utfärdas automatiskt, vanligtvis inom 2 minuter med ACME. Den billigaste typen i vårt sortiment. Inga företagsuppgifter i certifikatet.
Kontrollerar dessutom att ditt företag finns i offentliga register. Företagsnamnet står i certifikatets Organization-fält. FairSSL utför OV-validering på svenska för GlobalSign, vanligtvis inom en timme.
Den strängaste kontrollen, med verifiering av företagets juridiska, operativa och fysiska existens. Företagsnamn och land står i certifikatet. Krävs för kodsigneringscertifikat och i vissa branscher.
Alla tre typerna ger samma krypteringsstyrka. Webbläsare visar inte längre någon grön adressrad för EV (Chrome tog bort den 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: en domän, wildcard och SAN
- En domän: Täcker ett specifikt domännamn, t.ex.
www.ditt-doman.se. De flesta DV-certifikat tar automatiskt med bådewwwoch huvuddomä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 själva huvuddomänenditt-doman.se, om den inte har lagts till som extra SAN. Täcker inte heller djupare nivåer, somsub.api.ditt-doman.se. - Multidomän (SAN): Täcker en lista med specifika namn, som kan höra till helt olika domäner:
ditt-doman.se,ditt-doman.com,din-webshop.se. Hur många SAN som ingår varierar mellan produkterna (vanligtvis 25-250).
Valet beror på din infrastruktur. Wildcard är enklare att administrera, men alla servrar som använder certifikatet delar samma privata nyckel. Om en server komprometteras kan nyckeln användas för att utge sig för att vara vilken subdomän som helst. SAN-certifikat ger mer kontroll och kan blanda domäner fritt. Se våra sidor om wildcard-SSL och multidomän-SSL för en utförligare jämförelse.
Nivå 2: Så fungerar det tekniskt
TLS-handskakningen: Vad händer när du öppnar en HTTPS-sida?
När din webbläsare ansluter till en HTTPS-server genomförs en TLS-handskakning. I TLS 1.3 krävs bara en tur och retur (vanligtvis 50-100 ms). Syftet är att webbläsaren och servern ska komma överens om en krypteringsnyckel utan att nyckeln någonsin skickas över nätet:
- 1 Client Hello. Webbläsaren skickar en lista över de TLS-versioner och chiffersviter den stöder, samt parametrar för nyckelutbytet (key shares). I TLS 1.3 skickar webbläsaren sin nyckelandel redan i första meddelandet, så att servern kan svara direkt.
- 2 Server Hello + certifikat. Servern väljer chiffersvit och skickar sin nyckelandel. Sedan skickar servern sitt certifikat (med den offentliga nyckeln och hela certifikatkedjan) i ett meddelande som redan är krypterat med den nyss framförhandlade nyckeln.
- 3 Certifikatverifiering. Webbläsaren kontrollerar: Är certifikatet utfärdat av en betrodd CA? Är det fortfarande giltigt? Matchar domännamnet (i SAN-fältet)? Är det loggat i Certificate Transparency? Är det återkallat? Går kedjan att följa hela vägen upp till en betrodd rot?
- 4 Sessionsnycklar. Redan i steg 1-2 utbytte webbläsaren och servern nyckelandelar med Elliptic Curve Diffie-Hellman (ECDHE). Andelarna kombineras till en delad hemlighet som sessionsnycklarna härleds ur. Den privata nyckeln skickas aldrig över nätet. Även den som fångar upp hela handskakningen kan inte räkna fram sessionsnyckeln.
- 5 Krypterad kommunikation. All efterföljande trafik krypteras med sessionsnyckeln (symmetrisk kryptering, vanligtvis AES-256-GCM eller ChaCha20-Poly1305). Symmetrisk kryptering är flera storleksordningar snabbare än asymmetrisk.
TLS 1.3 jämfört med 1.2: TLS 1.2 kräver två turer fram och tillbaka (dubbel latens). Den tillåter också RSA-nyckelutbyte (utan forward secrecy), chiffer i CBC-läge (sårbara för padding oracle-attacker) och en lång rad osäkra konfigurationer. TLS 1.3 tog bort allt detta. Om din server fortfarande erbjuder TLS 1.0 eller 1.1 bör de inaktiveras. Alla moderna webbläsare har tagit bort stödet för dem.
Vad innehåller ett certifikat? (X.509 i detalj)
Ett SSL-certifikat är ett X.509v3-certifikat kodat i ASN.1 DER-format (oftast Base64-kodat 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ändes tidigare för detta, men moderna webbläsare ignorerar CN och läser bara SAN. Ett certifikat utan SAN avvisas.
Certifikatkedjan: rot, mellanliggande certifikat och slutcertifikat
Ditt SSL-certifikat (slutcertifikatet, på engelska leaf) ingår i en förtroendekedja. Webbläsaren verifierar kedjan från ditt certifikat hela vägen upp till en betrodd rot:
Rotcertifikat är förinstallerade i certifikatlager som förvaltas av fyra stora rotprogram: Microsoft (Windows/Edge), Apple (macOS/iOS/Safari), Mozilla (Firefox) och Google (Chrome Root Store, lanserat 2023). För att tas upp måste CA:n klara en WebTrust- eller ETSI-revision och följa CA/Browser Forums Baseline Requirements.
Din server måste skicka hela kedjan (slutcertifikat + mellanliggande certifikat), men inte rotcertifikatet (webbläsaren har det redan). Ordningen spelar roll: slutcertifikatet först, sedan de mellanliggande certifikaten i ordning upp mot roten.
Vanligt fel: Om servern bara skickar slutcertifikatet utan mellanliggande certifikat kan webbläsare på vissa plattformar inte verifiera kedjan. Chrome på datorn hittar ofta det saknade mellanliggande certifikatet själv (via Authority Information Access), men mobila webbläsare och curl/Python misslyckas. Kontrollera alltid kedjan med vår SSL Scanner.
Korssignering i praktiken: När en CA har en ny rot som ännu inte finns i alla certifikatlager kan den låta sitt mellanliggande certifikat korssigneras av en äldre, allmänt betrodd rot. Let's Encrypt gjorde så: ISRG Root X1 var korssignerad av IdenTrust DST Root CA X3 för att fungera på äldre enheter. När DST Root CA X3 löpte ut den 30 september 2021 slutade certifikatverifieringen att fungera på äldre Android-enheter, i OpenSSL 1.0.x och på många IoT-enheter världen över.
Nyckeltyper: RSA och 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) |
|---|---|---|
| Nyckellängd | 2048 eller 4096 bitar | 384 bitar |
| Säkerhetsnivå | RSA 2048 ≈ 112 bitar, RSA 4096 ≈ 140 bitar | P-384 ≈ 192 bitar |
| Hastighet i handskakningen | Långsam (stor nyckel, tung beräkning) | Snabb (liten nyckel, effektiv) |
| Datamängd | Större certifikat (256-512 byte för nyckeln) | Mindre certifikat (96 byte för nyckeln) |
| 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 handskakning än RSA, kräver mindre data och har en säkerhetsnivå som motsvarar RSA med 7680 bitar. P-384 är så snabb att den lilla hastighetsvinsten med P-256 inte motiverar den lägre säkerhetsnivån. Behöver du RSA av kompatibilitetsskäl är RSA 3072 det naturliga valet. Undvik RSA 2048, eftersom det blir den första nyckellängden som spärras när kraven skärps.
Nyckeltypen i certifikatet är oberoende av vilken chiffersvit TLS-anslutningen använder. Du kan ha ett RSA-certifikat och ändå använda ECDHE för nyckelutbytet (och därmed få forward secrecy). TLS 1.3 kräver alltid ECDHE, oavsett certifikattyp.
Certifikatets livstid och förnyelse
Certifikat har en begränsad giltighetstid. CA/Browser Forum, det internationella organ som fastställer reglerna för SSL-branschen, har beslutat att den maximala livstiden ska kortas kraftigt i flera steg:
Kortare livstider begränsar skadan om en nyckel komprometteras och tvingar fram automatiserad certifikathantering. Med certifikat på 47 dagar från 15 mars 2029 är manuell förnyelse inte realistisk i någon miljö av nämnvärd storlek.
Lösningen är automatisering med ACME-protokollet. Läs mer om SSL-automatisering och se hela tidslinjen för certifikatens livslängd.
Nivå 3: För IT-proffs
Chiffersviter och forward secrecy
En chiffersvit (cipher suite) är den kombination av algoritmer som en TLS-anslutning använder: nyckelutbyte, signaturalgoritm, symmetrisk kryptering och hashfunktion. TLS 1.3 rensade kraftigt. Där TLS 1.2 hade hundratals möjliga kombinationer, många av dem osäkra, har TLS 1.3 bara fem:
Nyckelutbytet ingår inte i chiffersvitens namn i TLS 1.3, eftersom det alltid är tillfälligt (ephemeral) Diffie-Hellman (ECDHE med X25519 eller P-256, eller DHE med ffdhe2048+). RSA-nyckelutbyte är helt borttaget. Därmed får du forward secrecy som standard: varje session använder unika, tillfälliga nycklar. Även om serverns privata nyckel komprometteras i framtiden går uppfångad trafik inte att dekryptera i efterhand. Underrättelsetjänster är kända för att samla in krypterad trafik för att kunna dekryptera den senare ("collect now, decrypt later").
Om du fortfarande kör TLS 1.2 (t.ex. för kompatibilitet med äldre system) bör du uttryckligen bara tillåta säkra chiffersviter och kräva forward secrecy. En bra TLS 1.2-konfiguration tillåter bara ECDHE-baserade chiffersviter med AEAD-chiffer (AES-GCM, ChaCha20-Poly1305). Undvik CBC-läge (sårbart för padding oracle) och RSA-nyckelutbyte (ingen forward secrecy).
Chiffersviter: Vad du bör använda och vad du bör undvika
| Chiffersvit | 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-nyckelutbyte. Ingen forward secrecy. Uppfångad trafik kan dekrypteras om nyckeln läcker. |
| ECDHE-RSA-AES128-SHA | Undvik | CBC-läge. Sårbar för padding oracle-attacker (BEAST, Lucky13). |
| DES-CBC3-SHA | Farlig | 3DES. Knäckt (Sweet32-attacken). Aldrig acceptabel. |
| RC4-SHA | Farlig | RC4 är knäckt i grunden. Förbjuden i RFC 7465. |
Fallgropen med den "perfekta" A+-konfigurationen
Det är frestande att härda TLS-konfigurationen så att den bara tillåter de nyaste och starkaste chiffersviterna. I praktiken kan en alltför strikt konfiguration ställa till verkliga problem:
- Äldre e-postservrar (Exchange 2010/2013, äldre SMTP-relän) stöder ofta bara TLS 1.0/1.1 med CBC-chiffer. Om din e-postserver avvisar dem faller avsändarna tillbaka på okrypterad SMTP, och e-posten skickas i klartext.
- Äldre mobiltelefoner (Android 4.x, äldre IoT-enheter) saknar stöd för TLS 1.2 och AEAD-chiffer. Användarna får en felsida utan förklaring.
- Betalningslösningar och API-integrationer använder ofta äldre TLS-stackar. En strikt konfiguration kan stoppa affärsprocesser som företaget är beroende av.
- Interna system (skrivare, skannrar, övervakningskameror) har sällan uppdaterad firmware och klarar ibland bara äldre chiffer.
Vår rekommendation: Börja med Mozillas "Intermediate"-profil från SSL Configuration Generator. Den väger säkerhet mot kompatibilitet på ett rimligt sätt. Härda sedan stegvis, utifrån vad dina klienter faktiskt stöder. Använd loggning för att se vilka chiffersviter som faktiskt används innan du tar bort några.
Ett A+-betyg på SSL Labs är värdelöst om hälften av dina användare eller integrationer inte kan ansluta. Målet är skyddad kommunikation för dem som faktiskt ansluter, inte ett högt testbetyg.
Använd vår SSL Scanner för att kontrollera din konfiguration. Mozillas SSL Configuration Generator skapar säkra konfigurationer för Apache, Nginx, HAProxy med flera. På Windows är IIS Crypto det enklaste verktyget för att härda TLS-konfigurationen för IIS och Remote Desktop. Se även vår guide till Mozilla SSL Configuration Generator.
Certifikatlager och rotprogram
Förtroendet i hela PKI-systemet utgår från rotcertifikat som är förinstallerade på din dator eller enhet. Rötterna förvaltas av fyra stora program, vart och ett med egna regler och revisionskrav:
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 med operativsystemet. Strikta krav på CT-loggning.
Används av Firefox och många projekt med öppen källkod. Har den mest öppna processen. Många Linux-distributioner använder Mozillas rötter.
Lanserades 2023. Chrome använde tidigare operativsystemets certifikatlager men har nu ett eget. Kräver Certificate Transparency och ACME-stöd av CA:er som ansöker om att tas upp. Delar infrastrukturen CCADB (Common CA Database) med Mozilla.
Valet av CA (certifikatutfärdare) har betydelse. Alla CA:er har inte rötter i alla certifikatlager, och samma rot har inte samma täckning på alla plattformar. En rot med dålig täckning kan göra att ditt certifikat inte fungerar på äldre Android-enheter eller i vissa företagsmiljöer. FairSSL säljer certifikat från DigiCert, GlobalSign och Sectigo, eftersom deras rötter har bred och stabil täckning.
Certificate Transparency (CT)
Certificate Transparency (RFC 6962) är ett offentligt loggsystem där poster bara kan läggas till, aldrig ändras (append-only), och där alla utfärdade SSL-certifikat registreras. Google föreslog systemet 2013, främst efter DigiNotar-skandalen 2011, då en komprometterad CA utfärdade falska certifikat för bland annat google.com. CT bidrog senare till att avslöja obehörigt utfärdade certifikat hos Symantec (2015-2017), vilket ledde till att Symantecs rötter togs bort ur alla webbläsare.
Alla offentliga CA:er är skyldiga att logga certifikaten i minst två till tre oberoende CT-loggar innan certifikatet är giltigt. Varje logg ger CA:n en Signed Certificate Timestamp (SCT), som bäddas in i certifikatet (eller levereras via OCSP-häftning eller ett TLS-tillägg). 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 söka i CT-loggarna efter din domän på crt.sh eller i Googles Transparency Report. Det är gratis och visar alla certifikat som har utfärdats för domänen. Sätt upp löpande övervakning av din domän.
OCSP, CRL och återkallelse
När ett certifikat behöver återkallas (komprometterad nyckel, felaktigt utfärdande, domänen har bytt ägare) måste webbläsare och klienter få veta det. Det finns tre mekanismer för det:
- CRL (spärrlista, Certificate Revocation List): En fullständig lista över de certifikat som CA:n har återkallat. Webbläsaren laddar ner listan och letar efter certifikatets serienummer. Listorna kan bli stora (flera MB) och uppdateras vanligtvis med 1-24 timmars mellanrum. Skalar 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"). Kontrollen sker i realtid, men ger ett integritetsproblem (CA:n kan se vilka sidor du besöker) och ett tillgänglighetsproblem (vad händer om OCSP-servern ligger nere?). Många webbläsare tillämpar "soft-fail": om OCSP-servern inte svarar accepterar de certifikatet ändå.
- OCSP-häftning (OCSP stapling): Servern hämtar själv OCSP-svaret från CA:n med jämna mellanrum (t.ex. var fjärde timme) och skickar det signerade svaret tillsammans med certifikatet under TLS-handskakningen. Webbläsaren behöver inte kontakta CA:n. Inget integritetsläckage och ingen extra latens. Aktivera det med
ssl_stapling on;i Nginx ellerSSLUseStapling Oni Apache.
Vår rekommendation: Aktivera OCSP-häftning. Det är den enda återkallelsemekanism som fungerar för alla klienter utan integritetsproblem. Servern levererar beviset själv, och klienten behöver inte göra några externa uppslag.
Återkallelse fungerar inte i praktiken
Google Chrome kontrollerar varken CRL eller OCSP för vanliga certifikat. Google motiverar det med att OCSP-uppslag låter CA:er spåra användarnas surfvanor, och att soft-fail (certifikatet accepteras om OCSP-servern inte svarar) gör mekanismen meningslös mot aktiva angripare.
I stället använder Chrome sin egen CRLite-lista, som bara täcker de största och mest kritiska sajterna. Återkallar du ett certifikat för en vanlig domän skyddar det alltså inte Chrome-användare i praktiken. Certifikatet visas som giltigt även efter återkallelsen. Firefox och andra webbläsare kontrollerar fortfarande OCSP/CRL, men eftersom Chrome har över 65 % marknadsandel är majoriteten av användarna oskyddade.
Om din privata nyckel komprometteras kan en angripare alltså 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.
Gör därför så här:
- Undvik wildcardcertifikat direkt under huvuddomänen för affärskritiska domäner. Om
*.ditt-doman.sekomprometteras kan du inte återkalla det så att det får effekt, och angriparen kan utge sig för att vara vilken subdomän som helst. - Se till att du kan byta FQDN i en nödsituation. Om du kan styra om trafiken till ett nytt värdnamn kan du undgå en man-in-the-middle-attack med det komprometterade certifikatet.
- Använd korta livstider, men förlita dig inte bara på dem. Google hävdar att korta livstider (47 dagar från 2029) begränsar skadan så mycket att återkallelse blir överflödig. Det håller vi inte med om. På 47 dagar hinner en angripare göra allvarlig skada, och redan några dagar med ett komprometterat certifikat kan få förödande följder om tidpunkten är rätt vald. Korta livstider hjälper, men ersätter inte en återkallelse som fungerar.
Let's Encrypt avvecklade OCSP helt 2025. Branschen går mot korta livstider i stället för återkallelse, och det gör automatiserad förnyelse med ACME ännu viktigare.
CAA-poster: Begränsa vem som får utfärda
CAA-poster i DNS (Certification Authority Authorization, RFC 8659) anger vilka CA:er som 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-post bara tillåter DigiCert kan varken Sectigo, Let's Encrypt eller någon annan CA utfärda certifikat för domänen.
iodef-posten i exemplet anger vart rapporter ska skickas: om en CA som inte står i dina CAA-poster får en begäran om att utfärda ett certifikat för din domän, ska den skicka en rapport till angiven e-postadress eller URL. Då får du veta om obehöriga försök att utfärda certifikat, oavsett om de lyckas eller inte.
CAA är lätt att sätta upp och ger ett starkt skydd. Använd FairSSL:s CAA-generator för att ta fram dina poster.
HPKP (HTTP Public Key Pinning): Avvecklad och farlig
HPKP (RFC 7469) var en HTTP-header som låste (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. Ett konfigurationsfel, ett förlorat nyckelpar eller ett byte av CA kunde låsa ute alla användare från din sajt i veckor eller månader. En aktiv pin gick inte att ångra.
- HPKP Suicide. Angripare kunde sätta en skadlig pin på en komprometterad sajt och sedan radera den riktiga nyckeln. Sajten blev då 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 på sin egen nyckel och sedan kräva lösensumma för att släppa 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. Skickar du fortfarande HPKP-headrar gör de ingen skada, men de har heller ingen effekt.
CAA-poster har ersatt HPKP (se ovan). CAA ger ett liknande skydd mot obehörigt utfärdade certifikat, men utan risken att du låser ute dig själv. CAA kontrolleras av CA:erna när de utfärdar, inte av webbläsarna hos användaren, så ett konfigurationsfel kan rättas utan att användarna påverkas.
HSTS och preloading
HTTP Strict Transport Security (RFC 6797) är en HTTP-header som talar om för webbläsare att alltid använda HTTPS:
När webbläsaren har tagit emot headern gör den inga HTTP-anslutningar till domänen 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-preload går ett steg längre: din domän tas upp på en lista som är hårdkodad i webbläsarna. Då använder även det allra första besöket HTTPS, och problemet med förtroende vid första besöket (TOFU) försvinner. Ansök via hstspreload.org.
Varning: En preload är svår att ångra. Det tar månader att bli borttagen från listan, och alla webbläsare måste släppa en uppdatering. Se till att HTTPS fungerar på alla subdomäner (även interna) innan du ansöker. includeSubDomains krävs för preload.
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 känt från 2016, men protokollet är öppet och används också av kommersiella CA:er som DigiCert, GlobalSign och Sectigo. Via FairSSL:s ACME-server får du certifikat från DigiCert-familjen och GlobalSign.
ACME validerar automatiskt att du kontrollerar domänen, med tre typer av utmaningar (challenges):
- HTTP-01: CA:n kontrollerar en specifik fil under
/.well-known/acme-challenge/. Kräver att port 80 är öppen. Kan inte användas för wildcard. - DNS-01: CA:n kontrollerar en TXT-post under
_acme-challenge.dittdoman.se. Kräver åtkomst till DNS-leverantörens API (eller CNAME-vidarebefordran). Kan användas för wildcard. - TLS-ALPN-01: CA:n ansluter till port 443 med ett särskilt ALPN-tillägg. Används av Caddy och när port 80 är blockerad.
FairSSL erbjuder SSL-automatisering med AutoDNS-validering: du skapar en permanent CNAME-vidarebefordran från _dnsauth.dittdoman.se till FairSSL:s valideringsinfrastruktur. Sedan sköts DNS-valideringen automatiskt, utan att dina servrar behöver API-nycklar till DNS.
ACME Renewal Information (ARI, RFC 9773) är ett nyare tillägg som låter CA:n tala om för din ACME-klient exakt när den ska förnya, till exempel när ett certifikat ska återkallas eller ett mellanliggande certifikat byts ut. Med certifikat på 47 dagar från 2029 blir det viktigt att förnya vid rätt tidpunkt. Läs mer om SSL-automatisering med FairSSL.
Vanliga fel och felsökning
De vanligaste felen:
Servern skickar bara slutcertifikatet. Fungerar i Chrome (som kan hämta det mellanliggande certifikatet via AIA), men misslyckas i curl, Python, mobilappar och CI/CD-pipelines. Lösning: installera hela kedjan.
Sidan använder HTTPS men laddar bilder, skript eller stilmallar över HTTP. Webbläsaren blockerar resurserna eller sänker säkerhetsnivån. Lösning: alla resurser ska använda HTTPS eller protokollrelativa URL:er.
Certifikatet är utfärdat för www.ditt-doman.se, men servern svarar även på ditt-doman.se (utan www), som inte finns i SAN-fältet. Lösning: ta med båda namnen i certifikatet eller använd en omdirigering.
Servern tillåter föråldrade TLS-versioner. De har kända sårbarheter (BEAST, CRIME) och är inte tillåtna enligt PCI DSS. Alla moderna webbläsare har tagit bort stödet. Lösning: inaktivera TLS 1.0 och 1.1 och tillåt bara TLS 1.2 och 1.3.
Publika sajter brukar få uppmärksamhet, men interna system (adminpaneler, CI/CD, övervakning) glöms ofta bort. Ett utgånget certifikat på en intern tjänst kan stoppa hela pipelinen för driftsättning. Lösning: automatisera förnyelsen med ACME på alla tjänster, inte bara de publika.
Populära DV-certifikat
RapidSSL
DV-certifikat från DigiCert. Passar enkla webbplatser och tjänster.
Thawte SSL123 SAN DV
SAN-certifikat med DV. Upp till 250 domännamn i samma certifikat.
Thawte SSL123 Wildcard
Wildcardcertifikat med DV. Täcker alla subdomäner under en domän.
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 beställ ditt första certifikat. Ett DV-certifikat utfärdas på under 2 minuter.