Ett grönt hänglås betyder inte att din SSL fungerar för alla besökare
En kund lägger en beställning i din webbshop. Swish-appen bekräftar betalningen och pengarna dras, men ordern dyker aldrig upp i ditt system. Kunden mejlar och undrar var varan är. Du loggar in på din egen sajt, tittar på adressfältet, och hänglåset är grönt som alltid. Allt ser ut att fungera.
Det gröna hänglåset i din webbläsare bevisar bara att din webbläsare var snäll nog att laga din server åt dig. Betaltjänstens server, som skulle skicka en bekräftelse (en så kallad webhook) till din sajt för att registrera ordern, fick ingen sådan hjälp. Den gav upp tyst, utan att någon i din webbläsare någonsin fick se ett felmeddelande.
Så tystnar en betalning som ingen i din webbläsare ser
Scenariot är enklare än det låter. Kunden betalar via Swish, Klarna eller Stripe. Betaltjänsten skickar därefter en POST-förfrågan, en webhook, direkt till din server för att bekräfta att pengarna faktiskt kommit in och att ordern kan markeras som betald. Den förfrågan görs inte av en person i en webbläsare. Den görs av en maskin, ofta från ett helt annat land, som kopplar upp sig mot din server och försöker upprätta en TLS-anslutning precis som vilken annan klient som helst.
Om servern då bara skickar sitt eget certifikat (leaf-certet) utan mellanledet i kedjan, underkänner maskinklienten handskakningen. Webhooken misslyckas. Ordern registreras aldrig i ditt system, trots att pengarna redan dragits hos kunden.
Det är just tystnaden som gör felet farligt. Det finns ingen krasch, ingen synlig varning, inget som triggar en supportbiljett hos dig. Bara en missnöjd kund och en betalning som hamnar i limbo mellan bankens system och din orderhantering.
Samma mekanism slår mot fler klienter än betalningsflöden. Länkförhandsvisningar hos Facebook, LinkedIn och Slack går tyst fel när någon delar en länk till din sajt, vilket gör att bild och beskrivning uteblir. Övervakningsrobotar som ska larma vid driftstopp kan själva rapportera falska larm för att de inte kommer förbi TLS-kedjan. Skript byggda med curl, Python requests, Node.js eller Java beter sig likadant.
| Klient | Vad som händer vid ofullständig kedja |
|---|---|
| Betaltjänstens webhook (Swish, Klarna, Stripe) | Anslutningen underkänns, ordern registreras aldrig |
| Drifttids-/övervakningsrobot | Falskt driftlarm trots att sajten faktiskt är uppe |
| curl, wget, Python requests, Node.js https | TLS-fel eller trasig certifikatverifiering |
| Länkförhandsvisning (Facebook, LinkedIn, Slack) | Ingen bild eller beskrivning genereras vid delning |
Missförståndet bakom nästan alla dessa incidenter är lätt att sätta ord på. "Det funkar i min webbläsare, så det funkar överallt." Det stämmer inte.
Varför just din webbläsare inte märker något
Förklaringen handlar om en mekanism som heter AIA, Authority Information Access. Det är ett fält i själva certifikatet som pekar ut en webbadress där mellancertifikatet (intermediate) går att hämta. Ditt eget certifikat säger i praktiken "om du saknar mitt mellanled, hämta det här".
Chrome, Edge och Safari läser det fältet och hämtar mellancertifikatet automatiskt i bakgrunden om servern glömt skicka det. Det sker tyst, utan varning, och de flesta som testar sin sajt i en av dessa webbläsare ser aldrig att något var fel från början.
Firefox gör det inte. Det är den skarpaste detaljen i hela problemet, och den som oftast försvinner när "moderna webbläsare" beskrivs som en enda grupp. Kör du Firefox på exakt samma dator, med exakt samma nätverk, ser du samma varning som en betaltjänsts server skulle se. Skillnaden ligger inte i enheten eller operativsystemet, utan i vilken TLS-motor webbläsaren bygger på.
| Klient | Hämtar mellancertifikat via AIA? |
|---|---|
| Chrome / Edge | Ja, automatiskt och tyst |
| Safari | Ja, automatiskt och tyst |
| Firefox | Nej |
| curl, script, betalnings-webhook | I praktiken nästan aldrig som standard |
Det andra missförståndet att göra sig av med är föreställningen att mobilen krånglar och datorn läker. Så fungerar det inte. En iPhone med Safari läker felet lika tyst som en dator med Safari, medan samma dator med Firefox installerat visar felet rakt upp och ner. Det är TLS-motorn som avgör, inte formfaktorn.
Grunden för hur AIA-tillägget definieras finns i RFC 5280, avsnitt 4.2.2.1. Att Firefox medvetet valt att inte implementera automatisk AIA-hämtning går att följa i Mozillas Bugzilla-ärende 399324, där hållningen länge varit att servern ska skicka en komplett kedja själv snarare än att webbläsaren ska laga misstaget.
Rotorsaken, kort
Ett TLS-certifikat kommer sällan ensamt. Filen cert.pem innehåller bara ditt eget certifikat (leaf), medan fullchain.pem innehåller leaf-certet plus mellanledet som knyter det till en betrodd rot. Roten själv skickas aldrig av servern, den finns redan inbyggd i klientens förråd av betrodda rotcertifikat (trust store).
Pekar webbserverns konfiguration mot fel fil, mot cert.pem istället för fullchain.pem, blir kedjan precis så ofullständig som beskrivits ovan. Certbot-installationer är kända för att generera båda filerna sida vid sida i samma mapp, vilket gör felet lätt att göra av misstag om man kopierar sökvägen från fel rad. Mer om hur kedjan är uppbyggd går att läsa hos Let's Encrypt. Vill du börja från grunden med vad ett certifikat faktiskt är finns det i vår FAQ om SSL-certifikat.
Var risken faktiskt sitter
Problemet uppstår inte överallt. Paneldrivna gratis-SSL-lösningar, AutoSSL i cPanel, motsvarande i DirectAdmin eller en hosts egen kontrollpanel, installerar normalt en komplett kedja automatiskt. Det är inte huvudriskzonen.
Risken uppstår i stället i två situationer.
- Du köper ett certifikat externt och laddar upp det manuellt i din kontrollpanel.
- Du kör egen certbot eller acme.sh på en VPS och pekar konfigurationen mot fel fil.
Den vanligaste fällan i det manuella flödet är i grunden ett hederligt misstag snarare än en försummelse. Många uppladdningsformulär ber dig klistra in ditt eget certifikat och mellancertifikatet efter varandra i samma textfält. Glömmer du mellanledet, eller klistrar in det i fel ordning, blir kedjan bruten trots att du gjort precis det formuläret bad om. Det är ett normalt driftmoment som går fel, inte ett tecken på slarv.
Så ser du det i praktiken med vår SSL-kollare
Vi byggde SSL-kollaren för att kunna svara på precis den här frågan utan att gissa. Verktyget kopplar upp sig mot din domän som en extern klient, precis som en betaltjänsts webhook skulle göra, och visar den råa kedjan servern faktiskt skickar innan någon webbläsare hunnit laga något.
Det du ska titta på är kedjelängden. Visar den 1, skickar servern bara sitt eget certifikat och inget mellanled. En sund kedja är längre än så. Poängen med att testa externt snarare än att lita på sin egen webbläsare är just att din egen Chrome redan bevisat att den kan gissa fram vad som saknas, vilket gör den till ett dåligt vittne i den här specifika frågan.
Ett vanligt missförstånd är att stanna vid att SSL-kollaren visar en grön status och dra slutsatsen att allt är i sin ordning. Titta alltid på själva kedjelängden, inte bara på om testet i sig gick att genomföra.
Fixen, och hur du verifierar att den tog
- Peka om webbserverns konfiguration till fullchain-filen, eller till motsvarande CA-bundle, inte enbart till leaf-certifikatet.
- Har du inte själv tillgång till serverkonfigurationen, vilket gäller de flesta på delad hosting, kontakta värdens support och be dem specifikt verifiera att kedjan skickas komplett.
- Verifiera med en klient som inte AIA-hämtar, till exempel
curl -v https://dindomän.seeller ett externt kontrolltest. Att bara ladda om sidan i din egen webbläsare bevisar ingenting, den lagade felet tyst redan innan fixen också.
Stöter du på fler oklarheter kring domän och server i drift har vi samlat en bredare genomgång i vår guide till att felsöka domän och server själv.