Varför borde alla organisationer känna till de viktigaste skillnaderna mellan HTTP och HTTPS?

Key Takeaways

• HTTPS är HTTP-säkrat med TLS/SSL-kryptering; HTTP skickar varje begäran och svar som vanlig, läsbar text.
• Webbläsare har flaggat vanliga HTTP-sidor som "Inte säkra" sedan Chrome 68 i juli 2018, och trycket på okrypterade webbplatser har bara ökat sedan dess.
• TLS 1.3 (RFC 8446, publicerad augusti 2018) är den nuvarande versionen av protokollet; TLS 1.0 och 1.1 avskrivs formellt genom RFC 8996 i mars 2021.
• CA/Browser Forums omröstning SC081v3 minskar den maximala giltighetstiden för offentliga certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, i stegvisa minskningar som börjar den 15 mars 2026.
• Att köra produktionstrafik över HTTP skapar verkliga affärsrisker: dataavlyssning, straff för SEO-rankning, webbläsarvarningar vid utcheckning och inloggning samt efterlevnadsbrister.
• Det är automatisering av certifikatlivscykeln, inte en engångsmigrering, som håller en organisation säker i takt med att giltighetsfönstren krymper.

Publicerad: mars 2022. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och säkerhetsteam.

Vad är skillnaden mellan HTTP och HTTPS?

HTTP (Hypertext Transfer Protocol) är den uppsättning regler som webbläsare och servrar använder för att begära och leverera webbsidor, och skickar dessa data som vanlig text. HTTPS (Hypertext Transfer Protocol Secure) är HTTP som transporteras inuti en TLS-anslutning (Transport Layer Security), den moderna efterföljaren till SSL (Secure Sockets Layer), så samma förfrågningar och svar krypteras under överföring. Den synliga skillnaden är URL:en och hänglåset: HTTP-adresser börjar med http:// och visa ett olåst eller saknat hänglås, medan HTTPS-adresser börjar med https:// och visa ett låst hänglås bredvid URL:en.

En certifikatutfärdare (CA) , såsom DigiCert, Sectigo eller Let's Encrypt, är den betrodda tredje part som verifierar en domänägares identitet och utfärdar SSL/TLS-certifikatet som binder en offentlig nyckel till den domänen. Under TLS-handskakningen presenterar servern certifikatet, klienten verifierar det mot en betrodd CA-kedja och de två sidorna upprättar en symmetrisk sessionsnyckel med asymmetrisk kryptering. Allt som skickas efteråt krypteras med den sessionsnyckeln, vilket är anledningen till att en HTTPS-anslutning motstår Man-in-the-Middle-attacker som skulle lyckas mot vanlig HTTP. För en djupare genomgång av handskakningsmekanismerna, se vår dedikerade TLS-handskakningsguide ; för certifikatgrunderna, se vad HTTPS är och hur det skiljer sig från HTTP i vårt utbildningscenter.

När blev HTTPS webbstandard?

HTTPS blev inte standard i en enda händelse. Det är resultatet av ett decennium långt arbete från webbläsarleverantörer, IETF och CA/Browser Forum, och det arbetet är fortfarande aktivt idag genom certifikatgiltighetsschemat som beskrivs nedan.

• 2012: HTTP Strict Transport Security (HSTS) publicerades som RFC 6797, vilket gav webbplatser ett sätt att instruera webbläsare att bara ansluta via HTTPS.
• 2014: Google presenterade HTTPS som en lättviktig rankningssignal i sökmotorer, vilket ger krypterade webbplatser en liten SEO-fördel.
• Juli 2018: Chrome 68 började markera varje vanlig HTTP-sida som "Inte säker" i adressfältet, den milstolpe som fick de flesta återstående offentliga webbplatser att migrera.
• Augusti 2018: TLS 1.3 publicerades som RFC 8446, den version av protokollet som används idag.
• Mars 2021: RFC 8996 avskaffade formellt TLS 1.0 och TLS 1.1, förbjöd deras användning i nya implementeringar och flaggade alla servrar som fortfarande erbjuder dem som icke-kompatibla.
• 2025 till 2029: CA/Browser Forums omröstning SC081v3 sänker den maximala giltighetstiden för offentliga certifikat från 398 dagar till 47 dagar senast den 15 mars 2029, med mellanliggande sänkningar till 200 dagar (mars 2026) och 100 dagar (mars 2027).

Vilka tekniker och system påverkar övergången från HTTP till HTTPS?

Varje system som avslutar eller vidarebefordrar webbtrafik behöver ett giltigt certifikat och TLS-stöd, inte bara den publika marknadsföringssajten. Det inkluderar webbservrar och omvända proxyservrar, lastbalanserare och CDN:er, interna API:er och mikrotjänster (ofta säkrade med gemensam TLS), IoT- och enhetshanteringsslutpunkter, interna administratörspaneler och dashboards som team antar är "säkra" eftersom de inte är offentliga, mobilapp-backends och e-postgateways som förlitar sig på STARTTLS. En migrering från HTTP till HTTPS som bara täcker huvudwebbplatsen medan interna tjänster, API:er eller IoT-slutpunkter lämnas på HTTP lämnar fortfarande organisationen exponerad.

Vad händer med din organisation om du inte använder HTTPS?

Att fortsätta använda vanlig HTTP skapar en mätbar affärskostnad, inte bara ett teoretiskt säkerhetsgap.

• SEO-påverkan: HTTPS har varit en rankningssignal för Google sedan 2014, och webbläsarvarningen "Inte säker" som vanliga HTTP-sidor nu har minskar klickfrekvensen och uppehållstiden även när en sida fortfarande rankas.
• Varningar för webbläsare: Chrome, Firefox och Edge märker alla HTTP-sidor och formulär med "Inte säker", vilket minskar besökarnas förtroende i det exakta ögonblicket för en inloggning, utcheckning eller ett inskick av ett leadformulär.
• Dataavlyssning: Alla HTTP-sessioner är läsbara och ändras under överföring, så inloggningsuppgifter, betalningsuppgifter och annan personligt identifierbar information (PII) som skickas via HTTP kan fångas upp av en Man-in-the-Middle-attack.
• Efterlevnadsexponering: PCI DSS kräver stark kryptografi för kortinnehavardata under överföring, och ramverk som GDPR förväntar sig kryptering som ett grundläggande skydd för personuppgifter. Vanlig HTTP på ett formulär som samlar in endera är en direkt efterlevnadsbrist.

Hur granskar du din webbplats HTTP/HTTPS-status och certifikathälsa?

Att granska HTTPS-täckning innebär att kontrollera alla nåbara värdnamn, inte bara hemsidan.

1. Genomsök hela domänen och alla kända underdomäner för att hitta alla URL:er som fortfarande visas över http://.
2. Kontrollera certifikatets giltighet, utfärdande certifikatutfärdare, nyckelstyrka (RSA 2048 bit minimum eller ECC) och utgångsdatum för varje upptäckt certifikat.
3. Bekräfta att HSTS är aktiverat och, där så är lämpligt, inkluderar underdomäner och skickas till HSTS-förladdningslistan.
4. Testa för blandat innehåll, det vill säga HTTPS-sidor som fortfarande laddar HTTP-bilder, skript eller iframes.
5. Verifiera att omdirigeringar från HTTP till HTTPS använder en enda 301-omdirigering snarare än en omdirigeringskedja med flera hopp.
6. Granska hur certifikat utfärdas och förnyas för närvarande. Manuellt spårade certifikat är den främsta orsaken till oplanerade avbrott, och den risken ökar kraftigt i takt med att giltighetsfönstren krymper mot 47 dagar.

Hur migrerar man från HTTP till HTTPS?

1. Inventera alla domäner, underdomäner och interna tjänster som för närvarande är nåbara via HTTP.
2. Skaffa ett giltigt SSL/TLS-certifikat från en betrodd CA för var och en; en gratis CSR-generator kan producera den certifikatsigneringsbegäran som behövs för att starta den processen.
3. Installera och konfigurera TLS 1.3, behåll TLS 1.2 som reserv och inaktivera TLS 1.0 och TLS 1.1.
4. Omdirigera alla HTTP-förfrågningar till HTTPS med 301-omdirigeringar.
5. Aktivera HSTS för att förhindra försök till nedgradering av protokollet.
6. Hitta och åtgärda referenser till blandat innehåll så att ingen HTTPS-sida laddar en HTTP-underresurs.
7. Uppdatera interna länkar, webbplatskartor och kanoniska taggar så att de pekar på HTTPS-versionerna av varje sida.
8. Automatisera identifiering, utfärdande och förnyelse av certifikat istället för att spåra utgångsdatum manuellt. Med en giltighetstid på 47 dagar är manuell spårning inte operativt realistiskt i någon meningsfull skala.

Uppdateringslogg

• Augusti 2026: Uppdaterad med CA/Browser Forums 47-dagars giltighetsschema för certifikat, aktuell status för TLS 1.3 och RFC 8996, en checklista för detektering, en migreringschecklista, en jämförelsetabell, ett avsnitt om begränsningar och en FAQ.
• Mars 2022: Originalpublikation.

HTTP vs. HTTPS: Jämförelse sida vid sida

Attribut	HTTP	HTTPS
kryptering	Ingen; data skickas som vanlig text	TLS-kryptering (TLS 1.3 aktuell), verifierad med ett SSL/TLS-certifikat
Standardport	port 80	port 443
Certifikat krävs	Nej	Ja, utfärdat av en betrodd certifikatutfärdare
SEO-effekt	Ingen rankningsfördel; varningar om "Inte säker" kan minska klickfrekvensen	Rankningssignal sedan 2014; ingen säkerhetsvarning för webbläsaren
Webbläsarbehandling	Etiketten ”Inte säker” i Chrome, Firefox och Edge	Låst hänglåsikon, betrodd som standard
Dataintegritet	Sårbar för avlyssning och ändringar under transport	Krypterad och autentiserad från början till slut

Begränsningar

• HTTPS krypterar data under överföring. Det gör ingenting för att skydda data som lagras på servern, i en databas eller i en säkerhetskopia.
• Ett giltigt certifikat är inte ett bevis på legitimitet. Nätfiskewebbplatser får rutinmässigt ett giltigt, gratis SSL/TLS-certifikat, så en hänglåsikon bekräftar att anslutningen är krypterad, inte att webbplatsen är pålitlig.
• Felkonfigurerade TLS, såsom svaga krypteringssviter eller ett utgånget certifikat som en webbläsare tyst accepterat genom en åsidosättning, kan skapa falskt förtroende som är värre än ingen kryptering alls.
• Certifikatets giltighetsfönster fortsätter att krympa (47 dagar i mars 2029), vilket gör certifikathantering från en tillfällig manuell uppgift till ett automatiseringskrav.
• HTTPS uppfyller en kontroll bland många. Det uppfyller inte i sig självt helt kraven för PCI DSS, GDPR eller liknande efterlevnadsramverk, vilka alla kräver ytterligare skyddsåtgärder utöver transportkryptering.

Vad skulle krypteringskonsulter rekommendera?

Betrakta övergången till HTTPS som startpunkten, inte mållinjen. Den verkliga risken som de flesta organisationer bär idag är inte "vi har en sida kvar om HTTP", utan "vi har inte en tillförlitlig inventering av alla certifikat vi är beroende av, och vi står inför ett giltighetsfönster som krymper till 47 dagar". CertSecure Manager automatiserar identifiering, utfärdande, förnyelse och återkallelse av certifikat i hela din miljö, så certifikat roteras enligt schema istället för att spåras i ett kalkylblad. För organisationer som behöver hanterad, molnlevererad PKI istället för att driva sin egen certifikatutfärdare hanterar PKI as a Service utfärdande och livscykelhantering direkt. Om du precis har börjat skapar vårt kostnadsfria CSR Generator- verktyg en korrekt formaterad certifikatsigneringsförfrågan på några minuter. Encryption Consulting är ISO/IEC 27001:2022- och SOC 2-certifierad, så samma kontroller som vi rekommenderar för din certifikatlivscykel är de vi själva driver.

Slutsats

HTTP och HTTPS ser ut som en bokstavs skillnad, men den bokstaven representerar hela förtroendelagret i den moderna webben: kryptering, autentisering och integritet för varje begäran och svar. Varje organisation, oavsett storlek, har ett direkt incitament att köra HTTPS överallt och att behandla certifikathantering som en löpande operativ disciplin snarare än en engångsuppgift för installation, särskilt eftersom CA/Browser Forums giltighetsschema pressar ner maximal livslängd för certifikat till 47 dagar år 2029. Att använda kryptering och digitala certifikat är viktigt för anslutningar över internet och inom en organisations interna nätverk. Säkerhetssystem som Public Key Infrastructure (PKI) ger användare och enheter i en organisation de certifikat de behöver för att identifieras och kommunicera säkert. För att lära dig hur Encryption Consulting kan hjälpa dig att konfigurera och automatisera PKI inom din organisation, besök www.encryptionconsulting.com.

Vanliga frågor om partihandel med mat och dryck

Är HTTPS bara HTTP med ett installerat certifikat? Inte exakt. HTTPS är HTTP som körs inuti en TLS-krypterad anslutning. Certifikatet är det som låter webbläsaren verifiera serverns identitet och upprätta den krypterade anslutningen från första början, men krypteringen, handskakningen och utbytet av sessionsnyckeln är det som faktiskt gör trafiken säker, inte bara certifikatfilen.

Saktar HTTPS ner en webbplats? TLS-handskakningen lägger till en liten latens till den första anslutningen, vanligtvis några millisekunder med TLS 1.3 och modern hårdvara, och den kostnaden återanvänds för efterföljande förfrågningar genom återupptagande av sessionen. I praktiken uppväger SEO- och förtroendefördelarna med HTTPS denna försumbara omkostnad, och HTTP/2, som de flesta webbläsare kräver HTTPS för, gör ofta en HTTPS-webbplats snabbare totalt sett än dess HTTP-motsvarighet.

Kan en nätfiskesajt också använda HTTPS? Ja. En certifikatutfärdare verifierar att certifikatansökaren kontrollerar domänen, inte att själva domänen är pålitlig eller att organisationen bakom den är legitim. Ett låst hänglås bekräftar att anslutningen är krypterad; det säger ingenting om vem som är i andra änden, vilket är anledningen till att HTTPS aldrig bör behandlas som en fristående förtroendesignal.

Vad händer om ett certifikat går ut? Webbläsare blockerar åtkomst med en hård mellanliggande varning, anslutna API:er och tjänster slutar fungera helt och avbrottet varar tills ett nytt certifikat utfärdas och driftsätts. I takt med att certifikatens livslängd krymper mot 47 dagar enligt CA/Browser Forums schema blir manuell förnyelsespårning en ledande orsak till förebyggbara avbrott, vilket är anledningen till att automatiserad hantering av certifikatens livscykel blir viktigare för varje år.

Behöver interna, icke-publika system också HTTPS? Ja. Interna administratörspaneler, API:er och tjänst-till-tjänst-trafik är vanliga mål när en angripare väl har fått fotfäste i nätverket, och vanlig HTTP där innebär att inloggningsuppgifter och sessionstokens färdas okrypterade över det interna nätverket. Behandla interna system med samma certifikat- och TLS-krav som allt som är riktat mot offentliga system.

Referensprojekt

• CA/Webbläsarforum. Omröstning SC081v3: Inför schema för att minska giltigheten och återanvändningsperioder för data (11 april 2025). cabforum.org
• IETF. RFC 8446: Transport Layer Security (TLS)-protokollet version 1.3 (augusti 2018). datatracker.ietf.org
• IETF. RFC 8996: TLS 1.0 och TLS 1.1 utfasas (mars 2021). ietf.org
• IETF. RFC 6797: HTTP Strict Transport Security (HSTS) (november 2012). datatracker.ietf.org
• Google. En milstolpe för Chrome-säkerhet: markering av HTTP som "inte säker" (2018). blog.google