SSL-certifikat A+ betyg i SSL Labs: Komplett guide 2026

Varför A+ betyget spelar roll – och hur du uppnår det

SSL Labs (ssllabs.com/ssltest) är det verktyg som säkerhetsexperter, penetrationstestare och IT-chefer världen över använder för att bedöma hur säker en webbservers HTTPS-konfiguration faktiskt är. Skalan går från F (aktivt osäker) till A+ (optimal konfiguration), och skillnaden handlar inte bara om prestige – den speglar direkt hur väl din webbplats skyddar besökarna mot avlyssning, man-in-the-middle-attacker och sessionkapning.

I den här guiden går vi igenom precis vad som krävs för att nå A+, steg för steg. Alla konfigurationsexempel är testade och fungerar på moderna Linux-servrar med Nginx eller Apache. Vi börjar med det grundläggande och arbetar oss upp till de finjusteringar som separerar A från A+.

---

Innehållsförteckning

1. Hur SSL Labs betygsätter din server
2. Vad krävs specifikt för A+?
3. TLS-versioner: inaktivera det gamla, aktivera det nya
4. Cipher suites: välj rätt algoritmer
5. HSTS: tvinga HTTPS på riktigt
6. OCSP Stapling: snabbare och säkrare
7. Certifikatkedjan: en förbisedd fälla
8. Mixed content: den dolda boven
9. Fullständiga konfigurationsexempel
10. Verifikation och felsökning
11. Automatisk förnyelse med Certbot
12. Vanliga frågor

---

1. Hur SSL Labs betygsätter din server {#hur-ssl-labs-betygsätter}

SSL Labs-betyget bygger på fyra huvudkategorier, viktade mot varandra:

• Certifikat (30%) – giltighet, kedja, nyckelstyrka, signaturalgoritm
• Protokollstöd (30%) – vilka TLS/SSL-versioner som är aktiva
• Nyckelutbyte (30%) – vilka metoder som används för att etablera sessionsnyckeln
• Chifferstryrka (10%) – styrkan på de algoritmer som används för kryptering

Slutbetyget baseras på den sämsta av dessa fyra. Det räcker alltså inte att ha ett perfekt certifikat om du fortfarande stöder TLS 1.0 – du blir automatiskt begränsad till B, oavsett hur bra allt annat är.

Viktigt: A+ är inte standardinställningen på någon webbserver. Nginx och Apache skickas med konfigurationer som är utformade för maximal kompatibilitet, inte maximal säkerhet. Du måste aktivt konfigurera för A+.

---

2. Vad krävs specifikt för A+? {#vad-krävs-för-a-plus}

För att SSL Labs ska ge A+ (inte bara A) krävs följande:

1. HSTS-headern måste vara aktiv med max-age på minst 6 månader (15 768 000 sekunder)
2. Inga kritiska sårbarheter (POODLE, BEAST, HEARTBLEED, DROWN, ROBOT, etc.)
3. Minst stöd för TLS 1.2 – helst med TLS 1.3 aktiverat
4. Inga svaga cipher suites (RC4, 3DES, exportchiffer)
5. Giltig och fullständig certifikatkedja
6. Inget mixed content

A (utan plus) kan du få med en korrekt men inte optimal konfiguration. A+ kräver att HSTS är korrekt implementerat och att det inte finns några nedsättande noteringar i rapporten.

---

3. TLS-versioner: inaktivera det gamla, aktivera det nya {#tls-versioner}

Detta är det viktigaste steget. SSL 2.0, SSL 3.0, TLS 1.0 och TLS 1.1 innehåller kända säkerhetsproblem som inte kan åtgärdas utan att lämna protokollet. De måste bort.

Protokollhistorik och status:

Nginx – ssl_protocols:

# /etc/nginx/nginx.conf eller din server-block
ssl_protocols TLSv1.2 TLSv1.3;

Apache – SSLProtocol:

# /etc/apache2/sites-available/dittdomän-ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3

Efter att du ändrat, ladda om servern (sudo nginx -t && sudo systemctl reload nginx resp. sudo apache2ctl configtest && sudo systemctl reload apache2) och kör SSL Labs-testet igen. Enbart den här ändringen kan höja dig från C till A.

---

4. Cipher suites: välj rätt algoritmer {#cipher-suites}

En cipher suite är kombinationen av fyra algoritmer: nyckelutbyte, autentisering, kryptering och MAC (meddelandeintegritet). Skillnaden mellan en säker och osäker konfiguration handlar ofta om vilka suites du tillåter.

Det du vill ha:

• ECDHE för nyckelutbyte (ger Perfect Forward Secrecy)
• AES-GCM eller ChaCha20-Poly1305 för symmetrisk kryptering
• SHA256 eller SHA384 för MAC

Det du vill undvika:

• RC4 – trasig sedan 2015 (RFC 7465)
• 3DES – sårbar för SWEET32-attacken
• MD5 – kollisionsattacker dokumenterade sedan 2004
• DES och exportchiffer – historiskt svaga nyckelstorlekar
• NULL-chiffer – ingen kryptering alls

Nginx – ssl_ciphers (modern konfiguration):

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

Apache – SSLCipherSuite:

SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4:!DES:!EXPORT
SSLHonorCipherOrder on

Notera för TLS 1.3: TLS 1.3 har sina egna, separata cipher suites som du inte kan konfigurera bort. Det är en funktion – alla TLS 1.3-suites är starka per definition.

---

5. HSTS: tvinga HTTPS på riktigt {#hsts}

HTTP Strict Transport Security (HSTS) är en säkerhetsmekanism som instruerar webbläsaren att aldrig försöka nå din sajt via HTTP, inte ens om användaren skriver http:// manuellt eller klickar på en gammal okrypterad länk. Det eliminerar den kategori av attacker som kallas SSL stripping.

Vad händer utan HSTS?

Utan HSTS kan en angripare på samma nätverk (café-wifi, hotell, flygplats) utföra en man-in-the-middle-attack: de intercepterar det första HTTP-anropet (innan redirect till HTTPS), sitter i mitten och ser all trafik i klartext – trots att du har ett giltigt SSL-certifikat.

HSTS-headerns anatomi

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age=31536000 – webbläsaren ska komma ihåg HSTS-policyn i 365 dagar (ett år). Minimum för A+ är 15 768 000 sekunder (6 månader).
• includeSubDomains – policyn gäller även alla underdomäner. Viktigt för att skydda t.ex. mail.dittdomän.se.
• preload – din domän kan läggas till i HSTS Preload-listan som är inbyggd i Chrome, Firefox, Safari och Edge. Innebär att det allra första besöket är skyddat, innan webbläsaren ens fått HSTS-headern.

⚠️ Varning: Lägg inte till preload förrän du är helt säker på att hela sajten och alla underdomäner fungerar korrekt via HTTPS. En felkonfigurering med preload kan göra din sajt otillgänglig och ta månader att ta bort från preload-listan. Börja med max-age=300 under testning och öka gradvis.

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Anmäl till HSTS Preload-listan: Gå till hstspreload.org och ansök efter att ha kört sajten med preload-flaggan i minst 30 dagar.

---

6. OCSP Stapling: snabbare och säkrare {#ocsp-stapling}

När en webbläsare ansluter till din sajt måste den verifiera att ditt SSL-certifikat inte har återkallats av certifikatutfärdaren (CA). Utan OCSP Stapling gör webbläsaren en separat förfrågan till CA:ns OCSP-server – en extra nätverksrunda som lägger till 50–200ms fördröjning och dessutom avslöjar för CA vilka sajter dina besökare besöker.

Med OCSP Stapling hämtar din server ett signerat svar från CA (ett "OCSP-response"), cachar det och bifogar det direkt i TLS-handskaket. Webbläsaren behöver inte fråga CA – den litar på det signerade svaret din server redan hämtat.

Nginx:

ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;  # Google DNS eller din DNS-resolver
resolver_timeout 5s;

Apache (mod_ssl krävs):

SSLUseStapling on
SSLStaplingCache shmcb:/var/run/ocsp(128000)

Kontrollera att OCSP Stapling fungerar med:

openssl s_client -connect dittdomän.se:443 -status -tls1_2 2>&1 | grep -A 10 'OCSP Response'

Om du ser OCSP Response Status: successful är allt korrekt.

---

7. Certifikatkedjan: en förbisedd fälla {#certifikatkedjan}

Den vanligaste anledningen till att sajter får varningar i SSL Labs – trots att certifikatet i sig är giltigt – är en ofullständig certifikatkedja.

Ditt SSL-certifikat är inte signerat direkt av en rot-CA (root certificate authority) som webbläsare litar på. Det är signerat av ett mellancertifikat (intermediate certificate), som i sin tur är signerat av rot-CA. Webbläsaren måste se hela kedjan för att kunna verifiera förtroendet.

Felet: Din server skickar bara ditt certifikat, inte mellancertifikaten. Moderna webbläsare hämtar ofta mellancertifikat automatiskt via AIA (Authority Information Access), men äldre klienter, API-konsumenter och serverless-tjänster gör inte det. SSL Labs nedgraderar betyget.

Lösningen: Skapa en bundle-fil som innehåller ditt certifikat följt av mellancertifikaten i ordning:

cat dittdomän.crt mellancertifikat.crt > chain.crt

Nginx – peka på bundle:

ssl_certificate /etc/ssl/certs/chain.crt;
ssl_certificate_key /etc/ssl/private/dittdomän.key;

Apache – använd SSLCertificateChainFile:

SSLCertificateFile /etc/ssl/certs/dittdomän.crt
SSLCertificateKeyFile /etc/ssl/private/dittdomän.key
SSLCertificateChainFile /etc/ssl/certs/mellancertifikat.crt

Let's Encrypt Certbot löser detta automatiskt – fullchain.pem innehåller redan korrekt kedjad fil.

---

8. Mixed content: den dolda boven {#mixed-content}

Du kan ha ett perfekt SSL-certifikat med A+ konfiguration och ändå visa "Inte säker" i adressfältet. Orsaken är nästan alltid mixed content – en HTTPS-sida laddar en eller flera resurser via HTTP.

Exempel på mixed content:

• <img src="http://example.com/bild.jpg">
• <script src="http://cdn.example.com/script.js">
• CSS-filer med url('http://...') för bakgrundsbilder
• Inbäddade iframes som pekar på HTTP-adresser

Hitta mixed content:

Öppna webbläsarens utvecklarkonsol (F12 → Console) och leta efter röda eller gula varningsmeddelanden om mixed content. Alternativt, använd Chrome-tillägget HTTPS Everywhere eller verktyg som Why No Padlock.

Åtgärda mixed content:

1. Ändra alla http://-resurser till https:// eller protokollrelativa // (utan scheme)
2. Aktivera Content Security Policy med upgrade-insecure-requests:

add_header Content-Security-Policy "upgrade-insecure-requests;" always;

Denna CSP-direktiv gör att webbläsaren automatiskt uppgraderar alla HTTP-anrop till HTTPS, vilket kan täcka upp för hårda att hitta mixed content-problem i äldre CMS.

---

9. Fullständiga konfigurationsexempel {#konfigurationsexempel}

Nginx – komplett SSL-server-block

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name dittdomän.se www.dittdomän.se;

    # Certifikat (Let's Encrypt fullchain)
    ssl_certificate /etc/letsencrypt/live/dittdomän.se/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dittdomän.se/privkey.pem;

    # Protokoll
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers on;

    # Sessionscache (förbättrar prestanda)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;  # Inaktivera för bättre forward secrecy

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/letsencrypt/live/dittdomän.se/chain.pem;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # DH-parametrar (generera med: openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048)
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    # Säkerhetsheaders
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "upgrade-insecure-requests;" always;

    # Din webbrot
    root /var/www/dittdomän.se/html;
    index index.html index.php;
}

# Redirect HTTP -> HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name dittdomän.se www.dittdomän.se;
    return 301 https://$host$request_uri;
}

Apache – komplett VirtualHost

<VirtualHost *:443>
    ServerName dittdomän.se
    ServerAlias www.dittdomän.se
    DocumentRoot /var/www/dittdomän.se/html

    # Certifikat
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/dittdomän.se/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/dittdomän.se/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/dittdomän.se/chain.pem

    # Protokoll
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Cipher suites
    SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4:!DES:!EXPORT
    SSLHonorCipherOrder on

    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache shmcb:/var/run/ocsp(128000)

    # Headers
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</VirtualHost>

<VirtualHost *:80>
    ServerName dittdomän.se
    ServerAlias www.dittdomän.se
    Redirect permanent / https://dittdomän.se/
</VirtualHost>

---

10. Verifikation och felsökning {#verifikation}

Efter att du uppdaterat konfigurationen och laddat om servern, kör dessa kontroller:

Kör SSL Labs-testet

Gå till ssllabs.com/ssltest och ange din domän. Resultatet är klart på 1–2 minuter. Sikta på A+. Om du har A utan plus, kontrollera:

• Är HSTS-headern aktiv? (visas under "HSTS" i rapporten)
• Har du några "warnings" eller "weaknesses" under Protocol Details?

Kontrollera HSTS via curl

curl -I https://dittdomän.se | grep -i strict

Förväntad output: strict-transport-security: max-age=31536000; includeSubDomains; preload

Kontrollera vilka TLS-versioner som är aktiva

# Kontrollera att TLS 1.0 INTE fungerar (förväntat svar: ssl handshake failure)
openssl s_client -connect dittdomän.se:443 -tls1 2>&1 | grep -E 'SSL|TLS|handshake'

# Kontrollera att TLS 1.3 fungerar
openssl s_client -connect dittdomän.se:443 -tls1_3 2>&1 | grep 'Protocol'

Snabbkontroll med FortifyNet

FortifyNets SSL/TLS-analys kör automatiskt SSL Labs API:et och ger dig ett samlat betyg utan att du behöver besöka flera olika verktyg. Aktivera kontinuerlig övervakning för att få notis direkt om konfigurationen försämras.

---

11. Automatisk förnyelse med Certbot {#certbot}

Ett utgånget SSL-certifikat visar omedelbart en blockerande varningssida för alla besökare – det är ett av de mest undvikbara misstagen. Let's Encrypt Certbot löser detta med automatisk förnyelse.

Installera Certbot (Debian/Ubuntu):

sudo apt update
sudo apt install certbot python3-certbot-nginx  # eller python3-certbot-apache

Hämta certifikat och konfigurera automatiskt:

sudo certbot --nginx -d dittdomän.se -d www.dittdomän.se

Certbot modifierar din Nginx-konfiguration, hämtar certifikatet och sätter upp ett cronjob för automatisk förnyelse.

Testa att automatisk förnyelse fungerar:

sudo certbot renew --dry-run

Ett framgångsrikt dry-run innebär att förnyelse fungerar. Let's Encrypt-certifikat är giltiga i 90 dagar; Certbot förnyar automatiskt när det är 30 dagar kvar.

FortifyNets övervakningsfunktion skickar e-postaviseringar 30 och 7 dagar innan certifikatet löper ut – ett extra skyddsnät om Certbot av någon anledning inte fungerar.

---

Vanliga frågor {#vanliga-fragor}

Vad är skillnaden mellan SSL och TLS? TLS är den moderna, säkra efterföljaren till SSL. SSL 2.0 och 3.0 är formellt förbjudna sedan 2011 respektive 2015. I vardagsprat säger de flesta fortfarande "SSL" men alla säkra anslutningar sedan tidigt 2000-tal använder faktiskt TLS. Nuvarande standard är TLS 1.2 (minimum) och TLS 1.3 (rekommenderat).

Kan ett gratis Let's Encrypt-certifikat nå A+? Ja, absolut. SSL Labs-betyget bedömer serverkonfigurationen, inte certifikattypen eller priset. Ett korrekt konfigurerat Let's Encrypt-certifikat ger exakt samma A+ som ett certifikat som kostar tusentals kronor per år.

Hur lång tid tar det att gå från C till A+? Med tillgång till servern brukar det ta 30–60 minuter att implementera alla förändringar. Det komplexa är att förstå vad som ska ändras – den här guiden täcker det. Konfigurationsändringarna i sig är minimala.

Varför visar min sajt "Inte säker" trots giltigt certifikat? Vanligaste orsakerna i ordning: (1) Mixed content – HTTPS-sidan laddar resurser via HTTP. Öppna browser devtools → Console för att identifiera källan. (2) Certifikatkedjan är ofullständig – saknade mellancertifikat. (3) Certifikatet matchar inte domännamnet, t.ex. www-versionen saknar SANs.

Måste jag generera DH-parametrar? För TLS 1.3 är det inte nödvändigt – TLS 1.3 använder inte DHE. Men för TLS 1.2 med DHE-cipher suites rekommenderas 2048-bitars parametrar: openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048. Det tar 1–5 minuter att generera.

Hur ofta bör jag kontrollera SSL-betyget? SSL Labs-betyget kan förändras utan att du ändrar något – när nya sårbarheter publiceras uppdaterar SSL Labs sina kriterier. FortifyNets kontinuerliga övervakning testar din konfiguration regelbundet och varnar om något förändras.

Påverkar A+ betyget SEO? Direkt: HTTPS som signalstyrka har bekräftats av Google sedan 2014. Indirekt: Säkerhetsproblem (expired cert, mixed content) kan ge dig säkerhetsvarningar i Chrome som dramatiskt ökar bounce rate och sänker sökmotorsynlighet. A+ innebär inga sådana varningar.