Teknisk SEO utgör grunden för alla andra optimeringsinsatser, och en webbplats med säkerhetsbrister kommer sannolikt inte att engagera besökare eller ta sig till toppen av SERP.
I vårt tidigare inlägg diskuterade vi vikten av flyttar till HTTPS. Låt oss nu fördjupa oss i SSL/TLS-certifikat och potentiella fel som kan äventyra informationen som lagras på din webbplats och påverka sökresultatet. Vi kommer att ta upp vad ett SSL/TLS-fel är och erbjuda lösningar för att åtgärda alla fel av sitt slag.
Vad är SSL/TLS?
En SSL (Secure Sockets Layer) säkerställer säker färd av information över nätverk, och TLS (Transport Layer Security) är en uppdaterad version av SSL. Båda representerar en standardkrypteringsteknik som säkrar information mellan en användares webbläsare och en webbplats. SSL introducerades 1995 och uppgraderades till TLS 1999, vilket tillgodoser den växande efterfrågan på känslig dataskydd.
SSL/TLS-villkoren är sammankopplade med HTTPS (Hypertext Transfer Protocol Secure): HTTPS-anslutningen innebär att webbplatsen överför data över SSL- eller TLS-teknik.
Protokoll uppdateras konsekvent, vilket gör att alla tidigare versioner är utfasade. Vi kommer att diskutera detta ytterligare när vi förklarar föråldrade SSL/TLS-problem. Det viktigaste är att det är bäst att använda den senaste versionen av TLS eftersom alla andra är sämre än den.
Hur SSL/TLS påverkar din webbplatsranking
Google sätter användarsäkerhet bland de högsta prioriteringarna och höjer kraven på SSL/TLS-certifikat. HTTPS har varit en rankingsignal sedan 2014. Andra sökmotorer har inte varit mycket högljudda om hur säkerheten påverkar deras ranking, och redan 2014, Bing till och med meddelade att den inte planerade att ranka HTTPS-webbplatser högre.
Du bör dock inte underskatta värdet av ett säkert protokoll och kryptering. Varje sårbarhet kan få användardata att exponeras, problem med SSL/TLS-certifikat kan leda till att en webbplats blir oåtkomlig och säkerhetsvarningar som visas av webbläsare kan skrämma bort potentiella besökare.
2017 startade Google Chrome visar varningen "Ej säker". på icke-HTTPS-sidor som frågade efter känslig information (kreditkortsuppgifter eller lösenord) och ett år senare började den flagga alla webbplatser som inte har bytt till ett säkert protokoll som "Inte säkra". Nu står HTTPS-sidor för mer än 90 % av surftiden på Chrome.
De flesta populära webbläsarna markerar osäkra webbsidor med hjälp av hänglåsikonen: i Safari skulle du bara se en om webbplatsen är säkert krypterad, och i Firefox signalerar det genomstrukna hänglåset om HTTP-sidor med inloggningsfunktion.
Även om fördelarna med SSL/TLS och riskerna med att inte anta det finns på ytan, är världen i verkligheten långt ifrån 100 % HTTPS. De 2018 rapport visar att över 32 % av amerikanska företags webbservrar har lägst betyg för sin SSL/TLS-kryptering och över 7 % använder ett sårbart och föråldrat protokoll.
Låt oss kryptera förklarar verkställande direktören låg SSL/TLS-adoptionshastighet med det faktum att protokollen är svåra att hantera. Men det finns lösningar som Let's Encrypt som hjälper webbplatsägare big time genom att automatisera SSL/TLS-certifikatförvärv och hantering. Med en mängd användbara verktyg till ditt förfogande är det inte så svårt att hålla säkerheten på din webbplats i harmoni.
Typer av SSL/TLS-fel och hur man åtgärdar dem
När du inser vikten av korrekt kryptering och har ett SSL/TLS-certifikat, garanterar det inte att du inte kommer att stöta på några problem med det. Skanna din webbplats regelbundet efter stora SSL/TLS-sårbarheter. Du kan göra detta snabbt genom att använda SE Ranking-verktyget för webbplats SEO-revision.
Öppna webbplatsgranskningen i det vänstra navigeringsfältet och gå till Webbsäkerhet avsnitt i Problemrapport flik:
För en mer detaljerad platsbesiktning, använd vår checklista för webbplatsrevision. Den innehåller alla grundläggande kontroller du behöver göra. Så du kommer inte att missa något.
Låt oss gå vidare till att analysera de olika SSL/TLS-problemen och undersöka möjliga lösningar för var och en av dem.
1. Utgått webbplatssäkerhetscertifikat
Alla SSL/TLS-certifikat har en begränsad livslängd och det fortsätter att krympa med åren på grund av ständigt ökande säkerhetsproblem. Giltighetstiden minskade till fem år 2011, till tre år 2015 och till två år 2018. Från och med september 2020 varar nya certifikat i endast 398 dagar (13 månader). Apple var först med att meddela att Safari inte skulle acceptera certifikat som har ett längre utgångsdatum; Google och Mozilla följde detta beslut inom kort.
Information om certifikatets utgångsdatum är öppen för alla i en webbläsare:
Vad händer när ditt SSL/TLS-certifikat går ut? Din webbplats kommer att bli otillgänglig och användare som försöker besöka den kommer att se ett varningsmeddelande i sin webbläsare. Detta skulle pressa besökarna att ta en helomvändning och ditt företag kan drabbas av trafik, intäkter och förlust av rykte.
Hur man fixar
För att undvika sådana situationer, se till att övervaka utgångsdatumet och uppdatera certifikatet i tid. Det finns automatiserade lösningar som Låt oss kryptera or AWS certifikathanterare som hjälper till att hålla reda på dina SSL/TLS-certifikat, samt övervakningsverktyg som sematext som skickar flera varningar innan certifikatet löper ut. Många certifikatutfärdare ger också möjlighet att ställa in automatiska förnyelser.
Men om du slutar med ett utgånget säkerhetscertifikat för webbplatsen, hur fixar du det? Du måste förnya ditt certifikat manuellt eller köpa ett nytt. Varje förnyelse eller köp validerar din webbplats identitet och den aktuella versionen av krypteringen. Processen går igenom flera steg:
- Att välja typ av certifikat. De flesta utfärdande myndigheter tillhandahåller flera alternativ för olika behov från ett internt nätverk till en storskalig webbplats. Det här steget gäller inte om du förnyar ditt certifikat och inte vill byta till en annan typ (det är till exempel vettigt att byta till en Wildcard-certifikat när du lägger till underdomäner till en webbplats). När du köper ett certifikat, tänk på att det finns bedrägliga certifikat som säljs online som kommer att utsätta din webbplats för säkerhetsrisker. Läs mer om utfärdaren innan köpet. Du kan ställa in CAA rekord för att undvika opålitliga certifikatmyndigheter. Vissa CA:er du kan lita på inkluderar Digicert, Globalsign, sektigo, Thawte.
- Generera en begäran om certifikatsignering (CSR). Du måste generera en CSR från din värdleverantör. Processen är ganska enkel men varierar beroende på webbhotell. Som ett resultat kommer du att ha ett CRS att ladda upp med din SSL/TLS-leverantör och en privat nyckelfil att hitta på det operativsystem du använder.
- Aktivering och validering av certifikatet. Du måste bekräfta ägandet av din domän via e-post, CNAME-post eller valideringsfil. Denna process beror också på leverantören så att du kan kolla upp detaljerna med ditt webbhotell.
- Verifiering. När du har installerat certifikatet, kör en SSL/TLS-kontroll för att se till att allt fungerar korrekt. Här är ett exempel på ett onlinekontrollverktyg:
Om du byter till HTTPS vid det här laget, och det är första gången certifikatet installeras, måste du omdirigera webbplatsens HTTP-trafik till dess HTTPS-version och lägga till den säkra versionen i verktyg för webbansvariga. Lär dig mer om dessa tekniker från vår inlägg om att flytta en webbplats till HTTPS.
För att undvika att certifikatet löper ut i framtiden, ignorera inte utgångsmeddelanden och för din bekvämlighet, hitta en lösning för certifikathantering.
2. Inaktivt certifikat
Detta SSL-anslutningsfel uppstår när en webbläsare tar emot ett SSL-certifikat som ännu inte har blivit giltigt. Nuförtiden är det vanligt att använda en certifikathanterare för att hantera servercertifikat. Chefen distribuerar automatiskt nya certifikat med en giltighetstid som börjar från tidpunkten för driftsättningen. Men om klientmaskinens klocka är inställd 5 minuter efter på grund av felkonfiguration eller andra faktorer, kommer klienten att avvisa certifikatet. Denna situation är särskilt vanlig med API-klienter när deras maskiners klockor är osynkroniserade. Detta SSL-fel hindrar dig från att upprätta en säker anslutning mellan din webbplats och användarnas webbläsare, vilket kan vara en besvikelse.
Hur man fixar
För att undvika att distribuera certifikat som ännu inte är aktiva, verifiera giltighetsstarttiden innan du distribuerar certifikatet på servern. När du använder en certifikathanterare för att hantera ditt certifikat, se till att du får meddelanden om certifikatändringen tillsammans med information om det nya certifikatet.
Se till att certifikatkedjan är verifierad genom att bekräfta att alla mellanliggande certifikat och rotcertifikat är korrekt installerade på servern. Om några mellanliggande certifikat saknas eller är felaktigt installerade kan detta resultera i ett inaktivt certifikatfel.
För att verifiera att ditt certifikat är korrekt installerat och aktivt, använd online SSL/TLS-certifikatvalideringsverktyg som SSL-kontroll or Digicert. Dessa verktyg hjälper till att identifiera eventuella problem med certifikatkedjan eller installationen.
3. Återkallat certifikat
Det här SSL-felet uppstår när SSL/TLS-certifikatet som är installerat på din webbplats har ogiltigförklarats av den utfärdande Certificate Authority innan dess utgångsdatum. Detta händer vanligtvis på grund av säkerhetsproblem eller en begäran från certifikatägaren.
Certifikatutfärdaren för en lista över återkallade certifikat. Ett certifikat återkallas när dess privata nyckel visar tecken på att vara intrång eller när domänen som det utfärdades för inte längre fungerar.
När en klient försöker initiera en anslutning till en server, letar den efter problem i certifikatet, och en del av denna kontroll är att säkerställa att certifikatet inte finns på Certifikatåterkallningslista (CRL). Om något av certifikaten i din kedja finns i CRL kommer webbläsaren att avvisa dem. Varje webbläsare har en annan mekanism för att verifiera återkallningsstatusen för varje certifikat.
Hur man fixar
Du kan kontrollera ett certifikats återkallelsestatus genom att granska dess detaljer manuellt.
Börja med att klicka på låset i webbläsarens adressfält. Gå till Detaljer avsnitt och välj CRL-distributionspunkter alternativ.
Ladda ner CA:s CRL:er. Sök sedan igenom CRL efter certifikatets serienummer för att verifiera att det inte har återkallats.
Istället för att ladda ner en potentiellt stor lista över återkallade certifikat i en CRL, kan du fråga den utfärdande CA:s OCSP server genom att använda certifikatets serienummer. Detta kommer att främja ett svar som anger om certifikatet har återkallats. Om du inte har använt den här metoden ännu, läs den här guiden om hur du implementerar en OCSP-svarare.
Sedan, om ditt certifikat har återkallats, måste du skaffa ett nytt. Kontakta din certifikatleverantör eller den utfärdande CA för att begära ett ersättningscertifikat. De hjälper dig att generera en ny Certificate Signing Request (CSR) och få ett nytt SSL/TLS-certifikat.
4. Otillförlitlig certifikatutfärdare
Detta specifika SSL-certifikatfel inträffar vanligtvis när CA inte är allmänt erkänd eller klientens förtroendelager saknar nödvändiga rot- eller mellancertifikat. Under etableringen av SSL Chain of Trust, om webbläsaren inte kan hitta några lokalt betrodda rotcertifikat, kommer den inte att lita på serverns certifikat. Detta problem kan också uppstå när du använder självsignerade certifikat, eftersom webbläsaren inte kan lita på dem.
Hur man fixar
För att undvika detta TLS-fel, börja med att se till att du köper dina certifikat från en pålitlig certifikatutfärdare. Ansedda certifikatutfärdare, som Let's Encrypt, DigiCert eller Comodo, är mer benägna att inkluderas i de betrodda certifikatutfärdarnas listor för de flesta webbläsare och enheter.
Se till att CA:s certifikat som används för att signera ditt SSL/TLS-certifikat är giltigt och inte har gått ut. Ett utgånget eller återkallat CA-certifikat kan leda till ett otillförlitligt CA-fel. Verifiera CA:s certifikat med CA själv för att bekräfta dess giltighet.
Testa din webbplats SSL/TLS-certifikat på flera enheter och olika webbläsare. Detta SSL-fel kan uppstå på specifika plattformar eller webbläsare som inte har de nödvändiga rot- eller mellancertifikaten i sina förtroendebutiker.
Om felet i icke-betrodd CA kvarstår, identifiera de saknade rot- eller mellancertifikat som krävs för ditt SSL/TLS-certifikat. Skaffa dessa certifikat från CA eller deras dokumentation och installera dem på din webbserver. Se till att certifikatkedjan är komplett och korrekt konfigurerad.
Om du vill använda ett självsignerat certifikat för din webbplats måste du manuellt lägga till certifikatet i webbläsarens förtroendebutik. Du kan hänvisa till Denna guide för att lära dig hur du lägger till CA-certifikaten som betrodda rotmyndigheter till till exempel Chrome och Firefox.
5. Föråldrat säkerhetsprotokoll
Krypteringstekniker utvecklas under åren, och det gör även säkerhetsrisker och potentiella hackerattacker. Detta är en av anledningarna till att SSL/TLS-certifikatets livscykel förkortas och även till varför versionerna uppdateras och de tidigare tillkännagavs utfasade och osäkra.
Eftersom TLS introducerades som en uppgradering till SSL (version 3.0 vid den tiden) är alla TLS-versioner säkrare än SSL. Den senaste versionen av protokollet är TLS 1.3, släppt 2018: det har en förbättrad kryptografisk algoritm och kräver endast en tur och retur för handskakningen (vilket innebär att webbläsaren ansluter till din webbplats server lättare).
Från och med 2020, alla större webbläsare visar varningar för webbplatser som använder TLS 1.0 eller 1.1 och hindrar användare från att komma åt. Med det sagt kanske du vill använda den nuvarande TLS-versionen och inaktivera de äldre.
Hur man fixar
Det finns flera sätt att kontrollera vilken protokollversion en webbplats använder:
- I Säkerhet fliken i Chrome DevTools:
- I en tredjepartscheckare. Några av dem ger information om vilka TLS- och SSL-versioner som är aktiverade:
För att aktivera den senaste versionen av TLS, se först till att din webbplats är konfigurerad för att använda den. Kör en SSL-servertest och kolla på konfiguration avsnitt i resultaten:
Kontrollera sedan med din värdleverantör och ta reda på vad du behöver göra för att aktivera den senaste protokollversionen. I allmänhet måste du ange rätt protokoll i serverns konfigurationsfil.
Till exempel, om din webbplats körs på en Nginx-server måste du redigera filen nginx.conf och ange vilken TLS-version du har installerat. Lägg till det uppgraderade protokollet och inaktivera alla föråldrade versioner. Konfigurationsraden kommer att se ut så här:
ssl_protocols TLSv1.2 TLSv1.3;
Om det visar sig att din webbplats inte stöder TLS 1.2 eller 1.3, måste du kontakta webbhotellet och eventuellt uppgradera till en annan plan.
6. Certifikatnamnet stämmer inte överens
Ett certifikatnamn som inte matchar uppstår vanligtvis när domännamnet i SSL/TLS-certifikatet inte stämmer överens med vad en användare har angett i webbläsaren. Användare kommer att se en varning:
Hur man fixar
Låt oss titta på orsakerna bakom dessa SSL-fel och hur man åtgärdar dem:
- Din webbplats nås via ett internt domännamn som inte är specificerat i certifikatet (du anger till exempel dinwebbplats.localhost, men ditt certifikat har bara din webbplats). För att åtgärda detta SSL-fel, skaffa ett SAN-certifikat (Subject Alternate Name) som låter dig inkludera flera värdnamn under ett enda certifikat. Observera att SAM kanske inte är tillgängligt i alla planer med olika certifikatutfärdare.
- Din webbplats kan bedömas med och utan "www" men certifikatet har bara ett domännamn angivet. Det är viktigt att bestämma om du ska använda "www" med en domän namn, vidarebefordra all trafik till en vald version och få ett SSL/TLS-certifikat enligt vald version (med eller utan "www"). Vi ger mer information om hur detta påverkar din SEO i vår artikel på www- och icke-www-domännamn. Ett certifikat med SAN är också en lösning här.
- Din webbplats delar IP-adressen med andra och har inte ett separat protokoll. De flesta resurser behöver inte en dedikerad IP (om de inte skickar många e-postmeddelanden) och ett delat kommer med ett lägre pris. Om du har en delad IP, måste du ange ditt domännamn i protokollets anknytning som kallas SNI (Server Name Indication). Med SNI kommer servern att välja ett TLS-certifikat som är unikt för ett givet värdnamn och en motsvarande privat nyckel istället för att välja ett standardcertifikat som delas mellan flera webbplatser.
- Webbplatsens värdleverantör har förkonfigurerade inställningar som tvingar sin SSL/TLS på ditt domännamn. För att lösa detta måste du kontakta leverantören och låta dem ersätta sitt certifikat med ditt, eller överväga att byta till en annan leverantör.
Du kan verifiera vilka domännamn som är skyddade under ditt SSL/TLS-certifikat i ett onlinekontrollverktyg. Till exempel:
7. Föråldrad krypteringsalgoritm
När en användare går in på en webbplats, autentiserar deras webbläsare TLS-certifikatet genom en process som kallas handskakning. Chiffersviter, som är algoritmer som krypterar varje anslutning, spelar en avgörande roll i början av denna process: webbläsaren kommunicerar vilka chiffersviter den stöder och servern svarar med den säkraste. Om chiffersviten som konfigurerats på servern inte är tillräckligt säker, kommer webbläsaren att utfärda en "föråldrad kryptografi"-varning.
En chiffersvit innehåller flera chiffer, som var och en representerar en viss kryptografisk funktion. Före TLS 1.3 bestod den bästa rekommenderade kombinationen av fyra chiffer:
- En algoritm för nyckelutbyte mellan servern och webbläsaren (ECDHE)
- A digital signatur som hjälper till att autentisera certifikatet (ECDSA)
- Ett chiffer för säker dataöverföring (AES-256-GCM)
- En algoritm för meddelandeautentisering (SHA384)
TLS 1.3-chiffersviten består endast av de två sistnämnda chiffrarna – den här versionen stöder inte föråldrade nyckelutbytes- och autentiseringsalgoritmer som standard. Även om TLS 1.2 fortfarande kan användas för en säker anslutning, varierar de chiffer som accepteras av den här versionen i kvalitet, vilket kan leda till sårbarhet för cyberattacker. Med den senaste versionen av TLS får du mindre variation i chiffer och hela handskakningsprocessen blir snabbare, enklare och säkrare.
Hur man fixar
Du måste se till att du inte använder föråldrade kryptografiska algoritmer. För att lära dig vilka chiffersviter som är aktiverade på din server kan du köra ett SSL/TLS-servertest online:
Om du upptäcker att svaga chiffer fortfarande stöds av din TLS, måste du inaktivera dem i serverkonfigurationen. Det är också vettigt att ställa in en chifferordningspreferens för att indikera vilka chiffer webbläsare kommer att prioritera när de ansluter till din webbplats. För att göra det, kontrollera först säkerhetsklassificeringar av chiffer och chiffersträngar.
8. Generiskt SSL/TLS-protokollfel
Det här felet indikerar vanligtvis ett problem med SSL/TLS-handskakningsprocessen mellan klienten och servern. Det betyder i huvudsak att en klient eller server inte kan upprätta en säker konvention. Detta kan inträffa av olika anledningar, såsom felkonfigurerade SSL/TLS-inställningar, föråldrad programvara, webbläsarrelaterade problem, fel datum eller tid på en enhet, problem med Content Delivery Network (CDN), bland annat.
Detta TLS-fel kan vara frustrerande för användare i alla fall eftersom det hindrar dem från att komma åt webbplatsen.
Hur man fixar
Här är några steg som kan vidtas för att felsöka och lösa dessa TLS-fel:
Börja med att verifiera om din krypteringsalgoritm har uppdaterats. Till exempel har den kryptografiska standarden SHA-1, som ursprungligen utvecklats av NSA, ansetts föråldrad sedan 2005. Även om den används allmänt för SSL-certifikatkryptering anses den nu vara osäker. Det är därför din webbläsare kanske inte litar på SSL-certifikat som använder denna kryptering. Överväg att uppdatera ditt certifikat eller skaffa ett nytt för att lösa problemet. I föregående avsnitt har vi gett instruktioner om hur du gör detta.
Bekräfta sedan att din server och klient är konfigurerade för att använda kompatibla kryptografiska algoritmer. Föråldrade eller svaga algoritmer kan orsaka TLS-handskakningsfelet. Se till exempel till att din server stöder moderna chiffersviter och har inaktiverat föråldrade och osäkra protokoll som SSL 2.0 och SSL 3.0. Vi behandlade detta i detalj i föregående avsnitt.
Vänligen notera: Det här felet uppstår ofta på klientsidan, till exempel när systemdatum och tid på användarens enhet är felaktiga, webbläsartillägg eller tillägg stör SSL/TLS-anslutningar eller användaren har föråldrade webbläsarinställningar.
Uppgradera säkerheten på din webbplats
Den enkla sanningen är att du inte kan gå utan solida säkerhetsåtgärder för webbplatsen, och en av de viktigaste aspekterna av att skydda din webbplats från cyberattacker och dataexponering är korrekt SSL/TLS-konfiguration och hantering. Vi rekommenderar att du uppdaterar till den senaste TLS-versionen, ställer in varningar om certifikatets utgångsdatum, aktiverar den säkraste kryptografin och regelbundet skannar ditt protokoll efter sårbarheter. Cyberhot fortsätter att utvecklas så se till att du har koll på hur säkert användare ansluter till din webbplats.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Fordon / elbilar, Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- BlockOffsets. Modernisera miljökompensation ägande. Tillgång här.
- Källa: https://seranking.com/blog/ssl-tls-errors/
