OpenSSL 3.5: Nycklar & Certifikat i 12 Steg [2026]

OpenSSL driver i tysthet det mesta av krypteringen på internet, från HTTPS-sidor till krypterad e-post och signerade programuppdateringar. Verktyget finns redan installerat på i stort sett varje Linux-server och Mac, men de flesta använder bara en bråkdel av det. Den här guiden tar dig genom 12 praktiska steg, från att skapa din första privatnyckel till att bygga en egen certifikatutfärdare (CA) och förbereda dig för postkvantkryptografi. Allt bygger på OpenSSL 3.5 LTS, den långtidsstödda versionen som släpptes 8 april 2025 och får säkerhetsuppdateringar ända till 8 april 2030.

Räkna med runt 40 minuter för hela genomgången. Du behöver bara en terminal och grundläggande vana vid kommandoraden. Varje kommando är testat och kommer med exempel på utdata så att du ser exakt vad som ska hända. I slutet finns ett komplett, körbart skript som automatiserar hela kedjan, plus felsökning för de åtta vanligaste problemen.

Vad är OpenSSL och varför 3.5 LTS spelar roll 2026

OpenSSL är ett kryptografiskt bibliotek och ett kommandoradsverktyg som implementerar TLS-protokollet samt en uppsjö av algoritmer för kryptering, hashning och digitala signaturer. När din webbläsare visar ett hänglås är det med stor sannolikhet OpenSSL eller en avknoppning av kodbasen som hanterar handskakningen i bakgrunden. Kommandoradsverktyget openssl ger dig direkt tillgång till samma funktioner, vilket gör det oumbärligt för systemadministratörer, utvecklare och säkerhetsanalytiker.

Version 3.5 är den aktuella LTS-grenen (Long Term Support). Den fick stor uppmärksamhet eftersom den var den första OpenSSL-versionen med inbyggt stöd för de postkvantsäkra algoritmerna ML-KEM, ML-DSA och SLH-DSA, samt serversidig QUIC. För dig som bygger system som ska leva länge är valet av version inte en detalj. Kör du på OpenSSL 3.0 upphörde det fulla stödet 7 september 2025, och rena säkerhetsfixar släpps bara till 7 september 2026. Att ligga kvar på en gren utan stöd betyder att kända sårbarheter aldrig lagas.

Det finns också en nyare gren, OpenSSL 3.6, släppt 1 oktober 2025. Den är dock inte LTS och får stöd bara till 1 november 2026. För produktionsservrar är 3.5 LTS det självklara valet i 2026, just för att supportfönstret sträcker sig hela vägen till 2030. Vill du läsa mer om hur certifikat och TLS hänger ihop med hänglåset i webbläsaren rekommenderas vår genomgång av HTTPS och TLS.

OpenSSL-gren	Typ	Släpptes	Stöd till	Senaste utgåva (juni 2026)
3.0	LTS (utgående)	sep 2021	7 sep 2026 (endast säkerhet)	3.0-serien
3.5	LTS	8 apr 2025	8 apr 2030	3.5.7
3.6	Standard (ej LTS)	1 okt 2025	1 nov 2026	3.6.3

Källa: OpenSSL Library, nedladdningssidan och projektets release-strategi.

Förkunskaper och versioner du behöver

Innan du börjar bör miljön vara på plats. Den här guiden förutsätter en Unix-liknande terminal. Allt fungerar identiskt på Linux och macOS, och på Windows via WSL2 eller Git Bash. Du behöver inga betaltjänster och ingen internetuppkoppling utöver installationen.

OpenSSL 3.5 LTS (minst 3.5.0, helst 3.5.7 eller senare). Äldre 1.1.1 saknar provider-arkitekturen och flera kommandon nedan.
Ett Unix-skal: bash eller zsh på Linux/macOS, eller WSL2 (Ubuntu 24.04 LTS) på Windows.
Skrivrättigheter i en arbetskatalog, exempelvis ~/openssl-lab.
Grundläggande terminalvana: navigera mellan kataloger, redigera filer med nano eller vim.
Cirka 40 minuter och tålamod att läsa varje utdata noga.

En sista sak innan vi börjar: skilj alltid på privata och publika nycklar. Privatnyckeln är hemligheten som aldrig får lämna din maskin okrypterad. Den publika nyckeln och certifikatet får spridas fritt. Förväxlar du de två har du antingen ett system som inte fungerar eller, värre, en läckt hemlighet. Samma princip gäller i vår guide om SSH-nycklar i Linux, där nyckelhantering är hela poängen.

Steg 1: Installera och verifiera OpenSSL 3.5

Kontrollera först vilken version du redan har. Många distributioner levererar fortfarande 3.0 som standard, så det här steget avgör om du behöver uppgradera.

openssl version -a

Förväntad utdata på ett uppdaterat system:

OpenSSL 3.5.7 9 Jun 2026 (Library: OpenSSL 3.5.7 9 Jun 2026)
built on: Mon Jun  9 11:02:14 2026 UTC
platform: debian-amd64
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"

Ser du OpenSSL 3.0.x eller, ännu äldre, 1.1.1, bör du uppgradera. På Ubuntu 24.04 LTS och senare finns 3.x i standardförråden:

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade openssl

# macOS med Homebrew (ger ofta nyaste 3.5/3.6)
brew install openssl@3
echo 'export PATH="/opt/homebrew/opt/openssl@3/bin:$PATH"' >> ~/.zshrc

Skapa sedan en ren arbetskatalog. Allt vi gör hädanefter sker här, så att din hemkatalog inte fylls med nyckel- och certifikatfiler.

mkdir -p ~/openssl-lab && cd ~/openssl-lab
umask 077   # nya filer blir läsbara bara för dig

Kommandot umask 077 är ingen formalitet. Det gör att privatnycklar du skapar automatiskt får rättigheterna 600 (bara ägaren kan läsa). Glömmer du detta riskerar du att en nyckel hamnar med 644, läsbar för alla användare på systemet. Det är en av de vanligaste och mest underskattade felkällorna.

Steg 2: Skapa en RSA-4096-privatnyckel

Vi börjar med RSA eftersom det är den mest kompatibla algoritmen och den du oftast möter i kompatibilitetskrav. I OpenSSL 3.x är genpkey det moderna, rekommenderade kommandot. Det äldre genrsa fungerar fortfarande men bör undvikas i ny dokumentation. Alla flaggor finns dokumenterade i den officiella OpenSSL 3.5-manualen.

openssl genpkey -algorithm RSA \
  -pkeyopt rsa_keygen_bits:4096 \
  -out rsa4096.key

Generering av en 4096-bitars nyckel tar ett par sekunder eftersom OpenSSL letar efter stora primtal. Verifiera att nyckeln ser rätt ut:

openssl pkey -in rsa4096.key -text -noout | head -5

Förväntad utdata:

Private-Key: (4096 bit, 2 primes)
modulus:
    00:c4:1a:9f:7e:2b:8d:3a:6f:...
publicExponent: 65537 (0x10001)
privateExponent:

Vill du sedan ta fram den publika nyckeln separat, exempelvis för att dela med en motpart, extraherar du den ur privatnyckeln. Den publika nyckeln kan inte härledas baklänges till den privata, så den är trygg att skicka vidare.

openssl pkey -in rsa4096.key -pubout -out rsa4096.pub
cat rsa4096.pub

Notera filrättigheterna. Kör ls -l rsa4096.key och bekräfta att raden börjar med -rw-------. Tack vare umask 077 från steg 1 ska detta redan stämma. RSA-4096 ger en bred säkerhetsmarginal men är märkbart långsammare än de elliptiska alternativen vi tar i nästa steg. För många moderna system är 4096 faktiskt överdrivet, men det krävs ibland av regelverk och compliance.

Steg 3: Generera Ed25519- och ECDSA-nycklar

Elliptisk kurvkryptografi ger samma säkerhet som RSA med dramatiskt mindre nycklar och högre prestanda. En Ed25519-nyckel på 256 bitar motsvarar grovt sett RSA-3072 i styrka, men är några storleksordningar snabbare att signera med. För nya system är Ed25519 förstahandsvalet när båda ändarna stöder det.

# Ed25519: bästa standard för nya system
openssl genpkey -algorithm Ed25519 -out ed25519.key

# ECDSA P-256: bredast kompatibilitet i TLS-stackar
openssl genpkey -algorithm EC \
  -pkeyopt ec_paramgen_curve:P-256 \
  -pkeyopt ec_param_enc:named_curve \
  -out ecdsa-p256.key

Lägg märke till hur snabbt detta går jämfört med RSA-4096. Genereringen är i princip omedelbar. Inspektera Ed25519-nyckeln:

openssl pkey -in ed25519.key -text -noout

ED25519 Private-Key:
priv:
    9a:1c:5f:...:2e
pub:
    4b:88:d0:...:7a

Valet mellan algoritmerna handlar om en avvägning mellan kompatibilitet och prestanda. Behöver du nå äldre klienter och hårdvara väljer du ECDSA P-256 eller RSA. Bygger du ett internt system där du styr båda ändarna är Ed25519 både snabbare och enklare. Vi återkommer till en fullständig jämförelsetabell längre ner. Asymmetriska nyckelpar är också grunden för digitala signaturer, ett koncept väl värt att förstå parallellt.

Steg 4: Skydda privatnyckeln med en lösenfras

En privatnyckel i klartext på disk är en risk. Stjäl någon filen äger de din identitet. Lösningen är att kryptera nyckeln med en lösenfras, så att den krävs varje gång nyckeln används. OpenSSL stöder moderna chiffer som AES-256 för detta.

# Kryptera en befintlig nyckel med AES-256
openssl pkey -in rsa4096.key -aes256 -out rsa4096-enc.key

OpenSSL frågar efter en lösenfras och ber dig bekräfta den. Öppnar du sedan den krypterade filen ser du ett tydligt huvud som visar att innehållet är skyddat:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIJrTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI...
-----END ENCRYPTED PRIVATE KEY-----

Du kan också skapa en krypterad nyckel direkt vid genereringen genom att lägga till -aes256 i genpkey-kommandot. Vill du ta bort krypteringen senare (för att en tjänst behöver starta utan att fråga om lösenord) gör du tvärtom:

# Ta bort lösenfras (gör bara detta i en kontrollerad miljö)
openssl pkey -in rsa4096-enc.key -out rsa4096-plain.key

En varning: nyckelfiler utan lösenfras är vanliga på servrar, eftersom en webbserver som nginx eller Apache annars skulle blockera vid omstart och vänta på inmatning. Det är en medveten avvägning. Skyddar du sådana nycklar förlitar du dig i stället på filrättigheter och hårddiskkryptering. Vill du kryptera hela disken där nycklarna ligger är vår guide om VeraCrypt en bra utgångspunkt.

Steg 5: Skapa en CSR (certifikatbegäran)

En Certificate Signing Request (CSR) är det du skickar till en certifikatutfärdare när du vill ha ett betrott certifikat. CSR:en innehåller din publika nyckel och uppgifter om vem du är, signerat med din privatnyckel som bevis på att du äger nyckeln.

openssl req -new -key rsa4096.key -out request.csr

OpenSSL ställer en rad frågor. Det viktigaste fältet är Common Name (CN), som ska vara domännamnet, exempelvis www.example.se. Ett exempel på dialogen:

Country Name (2 letter code) [AU]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) []:Stockholm
Organization Name (eg, company) []:Example AB
Organizational Unit Name (eg, section) []:IT
Common Name (e.g. server FQDN) []:www.example.se
Email Address []:[email protected]

Moderna webbläsare ignorerar dock CN för värdnamnsvalidering och kräver i stället fältet subjectAltName (SAN). Det är den i särklass vanligaste fallgropen med CSR:er. För att slippa den interaktiva dialogen och få med SAN direkt använder du en enradare med konfiguration inbyggd:

openssl req -new -key rsa4096.key -out request.csr \
  -subj "/C=SE/ST=Stockholm/O=Example AB/CN=www.example.se" \
  -addext "subjectAltName=DNS:www.example.se,DNS:example.se"

Verifiera alltid innehållet i CSR:en innan du skickar in den. Ett enda felstavat domännamn betyder att certifikatet blir oanvändbart.

openssl req -in request.csr -noout -text | grep -A1 "Subject Alternative"

Steg 6: Självsignerat certifikat med SAN

För utveckling, interna tjänster och testmiljöer behöver du sällan en extern utfärdare. Ett självsignerat certifikat räcker. Skillnaden är att ingen utomstående litar på det automatiskt, så webbläsare visar en varning tills du lägger till det manuellt som betrott.

Det enklaste fungerande exemplet skapar nyckel och certifikat i ett enda kommando, med 365 dagars giltighet och korrekt SAN:

openssl req -x509 -newkey rsa:4096 \
  -keyout server.key -out server.crt \
  -days 365 -sha256 -nodes \
  -subj "/C=SE/O=Example AB/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Flaggan -nodes betyder “no DES”, det vill säga att privatnyckeln sparas utan lösenfras. Det är praktiskt för testservrar men ska aldrig användas i produktion utan kompletterande skydd. Verifiera resultatet:

openssl x509 -in server.crt -noout -subject -dates -ext subjectAltName

subject=C=SE, O=Example AB, CN=localhost
notBefore=Jun 16 09:00:00 2026 GMT
notAfter=Jun 16 09:00:00 2027 GMT
X509v3 Subject Alternative Name:
    DNS:localhost, IP Address:127.0.0.1

Lägg märke till att notAfter ligger exakt 365 dagar fram i tiden. Saknas raden med Subject Alternative Name kommer moderna klienter att avvisa certifikatet, oavsett att CN är korrekt. Det här är samma princip som gör hänglåset i webbläsaren giltigt eller inte, vilket vi går djupare in på i artikeln om HTTPS och TLS.

Steg 7: Bygg en egen mini-CA och signera certifikat

För labbmiljöer, interna nätverk och utveckling är en egen certifikatutfärdare guld värd. Du skapar ett rot-certifikat en gång, lägger till det som betrott på dina enheter, och kan sedan signera hur många servercertifikat du vill utan webbläsarvarningar. Det här är fundamentet i hur den riktiga certifikatinfrastrukturen på internet fungerar.

Skapa först en rotnyckel och ett rotcertifikat med lång giltighet (här tio år). Använd gärna Ed25519 eller ECDSA för CA:n eftersom den signerar ofta.

# 1. Rotnyckel + rotcertifikat (CA)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key
openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/C=SE/O=Example Lab CA/CN=Example Root CA" \
  -out ca.crt

Skapa sedan en servernyckel och en CSR, precis som i steg 5. Nu kommer det avgörande: vi signerar CSR:en med vår CA i stället för att självsigna. SAN måste anges via en extensionsfil.

# 2. Servernyckel och CSR
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out site.key
openssl req -new -key site.key -subj "/C=SE/O=Example AB/CN=app.example.se" -out site.csr

# 3. Extensionsfil med SAN
cat > site.ext <<EOF
subjectAltName = DNS:app.example.se,DNS:www.app.example.se
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
EOF

# 4. CA signerar certifikatet (giltigt 825 dagar)
openssl x509 -req -in site.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 825 -sha256 \
  -extfile site.ext -out site.crt

Gränsen på 825 dagar är ingen slump. De flesta webbläsare avvisar servercertifikat med längre giltighet än så. Verifiera att kedjan stämmer:

openssl verify -CAfile ca.crt site.crt

site.crt: OK

Får du OK är certifikatkedjan korrekt. Lägger du nu till ca.crt i operativsystemets eller webbläsarens lista över betrodda rötter, slutar alla certifikat du signerar med den att ge varningar. Det är exakt så företag rullar ut interna HTTPS-tjänster.

Steg 8: Inspektera och verifiera certifikat

Att kunna läsa ett certifikat är en daglig syssla för alla som driftar tjänster. OpenSSL ger dig fullständig insyn. Det vanligaste kommandot visar hela certifikatet i läsbar form:

openssl x509 -in site.crt -text -noout

Ofta vill du bara ha specifika delar. Här är de mest användbara varianterna i vardagen:

# Bara utgångsdatum
openssl x509 -in site.crt -noout -enddate

# Utfärdare, ämne och serienummer
openssl x509 -in site.crt -noout -issuer -subject -serial

# Fingeravtryck (SHA-256)
openssl x509 -in site.crt -noout -fingerprint -sha256

En särskilt nyttig kontroll är att bekräfta att en privatnyckel och ett certifikat verkligen hör ihop. Den vanliga felkällan vid driftsättning är att man av misstag blandar nycklar och certifikat från olika omgångar. Jämför deras publika nycklar via en hash:

# Hashar som måste vara identiska om nyckel och cert hör ihop
openssl pkey -in site.key -pubout -outform DER | openssl sha256
openssl x509 -in site.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl sha256

Är de två hash-värdena identiska matchar nyckeln certifikatet. Skiljer de sig har du fel par, och servern kommer att vägra starta TLS. Fingeravtryck bygger på SHA-256, samma hashfunktion som säkrar otaliga andra delar av modern kryptografi.

Steg 9: Konvertera mellan PEM, DER och PKCS#12

Olika system vill ha certifikat i olika format. PEM är textbaserat (med -----BEGIN------rader) och dominerar i Linux-världen. DER är binärt och vanligt i Java och Windows. PKCS#12 (filändelse .p12 eller .pfx) packar nyckel och certifikat i en enda lösenordsskyddad fil, vilket Windows och många importguider föredrar.

Format	Filändelse	Innehåll	Typiskt användningsområde
PEM	.pem .crt .key	Base64-text	Linux, nginx, Apache
DER	.der .cer	Binärt	Java, Windows-verktyg
PKCS#12	.p12 .pfx	Nyckel + cert + kedja	Windows, IIS, import
PKCS#8	.key	Privatnyckel	Modern nyckelstandard

De fyra format du oftast stöter på vid certifikathantering.

Konverteringarna är raka. PEM till DER och tillbaka:

# PEM -> DER
openssl x509 -in site.crt -outform DER -out site.der

# DER -> PEM
openssl x509 -in site.der -inform DER -out site-from-der.crt

Packa ihop nyckel, certifikat och CA-kedja till en PKCS#12-fil för import i Windows eller en mobil enhet:

openssl pkcs12 -export \
  -inkey site.key -in site.crt -certfile ca.crt \
  -out bundle.p12 -name "app.example.se"

Du ombeds sätta ett exportlösenord som krävs vid importen. För att packa upp en befintlig .pfx-fil du fått från någon annan vänder du på det:

openssl pkcs12 -in bundle.p12 -nodes -out unpacked.pem

Steg 10: Testa en TLS-anslutning med s_client och s_server

OpenSSL kan agera både server och klient, vilket är ovärderligt för felsökning. Starta en testserver i ett terminalfönster med certifikatet från steg 6:

openssl s_server -accept 4433 -cert server.crt -key server.key -www

Öppna ett andra terminalfönster och anslut som klient. Det här visar exakt vad en webbläsare ser under handskakningen:

openssl s_client -connect localhost:4433 -servername localhost

I utdatan ser du protokollversion, valt chiffer och certifikatkedjan. Ett utdrag från en lyckad TLS 1.3-anslutning:

SSL handshake has read 1394 bytes and written 389 bytes
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server certificate
subject=C=SE, O=Example AB, CN=localhost
Verify return code: 18 (self signed certificate)

Returkod 18 betyder “självsignerat certifikat”, vilket förväntas i en testmiljö. Mot en riktig server vill du se Verify return code: 0 (ok). Du kan också kontrollera utgångsdatum för vilken publik server som helst, vilket är perfekt för övervakning:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

För en fullständig extern analys av en publik servers TLS-konfiguration kompletterar du gärna OpenSSL med SSL Labs Server Test, som betygsätter chiffer, protokollstöd och kända sårbarheter.

Steg 11: Kontrollera utgångsdatum och automatisera

Utgångna certifikat är en av de absolut vanligaste orsakerna till driftstopp. Stora tjänster har gått ner på grund av ett glömt certifikat. OpenSSL låter dig bygga enkel övervakning. Kommandot nedan returnerar sant om certifikatet går ut inom 30 dagar (2592000 sekunder):

if openssl x509 -checkend 2592000 -noout -in site.crt; then
  echo "Certifikatet är giltigt i minst 30 dagar till."
else
  echo "VARNING: certifikatet går ut inom 30 dagar!"
fi

Det här går utmärkt att lägga i ett cron-jobb som mejlar dig i tid. Ett litet skript som kontrollerar en lista med domäner:

#!/bin/bash
for host in example.se app.example.se shop.example.se; do
  slut=$(echo | openssl s_client -connect "$host":443 -servername "$host" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)
  echo "$host går ut: $slut"
done

För riktiga, publikt betrodda certifikat är dock det smartaste att inte hantera dem manuellt alls. Använd Let’s Encrypt med en ACME-klient som certbot, som förnyar automatiskt var 60:e dag. OpenSSL blir då ditt verktyg för felsökning och inspektion, medan förnyelsen sköts av sig själv. Korta giltighetstider är en säkerhetsförbättring, inte ett problem, så länge förnyelsen är automatiserad.

Steg 12: Förbered för postkvantkryptografi (ML-KEM och ML-DSA)

Det här är skälet till att OpenSSL 3.5 är en viktig version. Den är den första LTS-utgåvan med inbyggt stöd för de algoritmer som NIST standardiserade för att motstå kvantdatorer. När en tillräckligt kraftfull kvantdator existerar kan den knäcka dagens RSA och ECDSA, och därför pågår en bred övergång redan nu.

De tre nya algoritmerna i OpenSSL 3.5 är ML-KEM (nyckelinkapsling, tidigare Kyber), ML-DSA (signaturer, tidigare Dilithium) och SLH-DSA (hashbaserade signaturer, tidigare SPHINCS+). Kontrollera att din installation känner igen dem:

openssl list -signature-algorithms | grep -i -E "ML-DSA|SLH-DSA"
openssl list -kem-algorithms | grep -i "ML-KEM"

Du kan redan nu generera ett postkvantsäkert signaturnyckelpar och prova flödet, även om ekosystemet av betrodda CA:er ännu inte stöder dem fullt ut:

# Generera en ML-DSA-65-nyckel (postkvant)
openssl genpkey -algorithm ML-DSA-65 -out mldsa.key
openssl pkey -in mldsa.key -text -noout | head -3

I praktiken handlar 2026 om hybridlösningar, där en klassisk algoritm kombineras med en postkvantsäker för att täcka båda hoten samtidigt. Övergångsplanen är väl beskriven av NIST:s projekt för postkvantkryptografi. För en bredare överblick över var tekniken står just nu, se vår genomgång i kryptografi-navet.

Algoritmval 2026: RSA, ECDSA eller Ed25519

Vilken algoritm du väljer påverkar prestanda, kompatibilitet och framtidssäkerhet. Den korta versionen: välj Ed25519 när du styr båda ändarna, ECDSA P-256 för bred TLS-kompatibilitet och RSA bara när ett regelverk eller en gammal klient kräver det. Här är en konkret jämförelse.

Algoritm	Nyckelstorlek	Ungefärlig styrka	Prestanda	Kompatibilitet	Bäst för
RSA 2048	2048 bit	112-bitars	Långsam	Mycket bred	Äldre system, miniminivå
RSA 3072	3072 bit	128-bitars	Långsammare	Bred	Säkrare RSA-baslinje
RSA 4096	4096 bit	~140-bitars	Långsammast	Bred	Compliance som kräver RSA
ECDSA P-256	256 bit	128-bitars	Snabb	Mycket bred	Standard för TLS-certifikat
Ed25519	256 bit	~128-bitars	Snabbast	God (nyare system)	Nya interna system, SSH

Jämförelse av algoritmer för nyckelgenerering i OpenSSL 3.5, 2026.

Lägg märke till att RSA-4096 inte ger dubbelt så mycket säkerhet som RSA-2048 trots dubbel nyckelstorlek. Säkerheten växer långsamt med nyckellängden hos RSA, medan kostnaden i prestanda växer snabbt. En ECDSA P-256-nyckel på 256 bitar matchar RSA-3072 i styrka men är många gånger snabbare. Det är därför hela branschen rört sig mot elliptiska kurvor. För signering specifikt är Ed25519 både snabbast och enklast att använda korrekt, eftersom den inte kräver en slumpkälla av hög kvalitet vid varje signatur, en historisk felkälla i ECDSA.

Fem vanliga fallgropar att undvika

Efter att ha gått igenom stegen är det värt att samla de misstag som oftast ställer till det. Att känna igen dem i förväg sparar timmar av felsökning.

Glömt subjectAltName. Det överlägset vanligaste felet. Ett certifikat utan SAN avvisas av alla moderna webbläsare, oavsett hur korrekt Common Name är. Ange alltid -addext "subjectAltName=DNS:..." eller en extensionsfil.
Förväxlat PEM och DER. Får du “unable to load certificate” är filen ofta i binärt DER-format medan kommandot förväntar sig PEM. Lägg till -inform DER.
Felaktiga filrättigheter på privatnyckeln. En nyckel med rättigheterna 644 är läsbar för alla på systemet. Sätt umask 077 innan du börjar, eller chmod 600 efteråt.
Nyckel och certifikat hör inte ihop. Servern vägrar starta TLS om paret inte matchar. Verifiera alltid med hashen av den publika nyckeln, som i steg 8, innan driftsättning.
För lång giltighetstid. Servercertifikat med över 825 dagars giltighet avvisas av webbläsare. Använd korta tider och automatisk förnyelse i stället.

En sjätte fälla värd att nämna är att köra gamla kommandon från internet som förutsätter OpenSSL 1.1.1. Provider-arkitekturen i 3.x ändrade hur vissa äldre algoritmer (som RC4 eller MD5-baserade flöden) nås, och de ligger nu i en separat “legacy”-provider. Det är medvetet: de är osäkra och ska inte användas i nya system.

Felsökning: åtta vanliga problem och lösningar

Den här tabellen samlar de felmeddelanden du sannolikt stöter på, med en konkret lösning för varje.

Felmeddelande / symptom	Trolig orsak	Lösning
unable to load certificate	Fel format (DER i stället för PEM)	Lägg till `-inform DER` eller konvertera filen
unable to load Private Key	Krypterad nyckel utan lösenord, eller fel filtyp	Ange lösenfras, kontrollera att det är en nyckel och inte ett cert
NET::ERR_CERT_COMMON_NAME_INVALID	SAN saknas i certifikatet	Återskapa med `subjectAltName`
key values mismatch	Nyckel och certifikat hör inte ihop	Verifiera publik nyckel-hash, använd rätt par
self signed certificate (kod 18)	CA inte betrodd av klienten	Förväntat i test, lägg till CA som betrodd i produktion
certificate has expired (kod 10)	Utgånget certifikat	Förnya certifikatet, automatisera med ACME
error:0308010C:digital envelope routines	Äldre algoritm i legacy-providern	Lägg till `-provider legacy` eller byt algoritm
verify error: unable to get local issuer	Mellanliggande CA saknas i kedjan	Inkludera hela kedjan med `-CAfile` eller `-untrusted`

De åtta vanligaste OpenSSL-felen och hur du löser dem.

Ett extra tips för svårare fall: lägg till -msg och -debug på s_client för att se hela handskakningen byte för byte. Och kom ihåg att openssl errstr översätter en hexadecimal felkod till läsbar text, vilket sparar mycket gissande.

Avancerade tips för OpenSSL i produktion

När grunderna sitter finns det några tekniker som lyfter din användning till en proffsnivå. De är värda att känna till även om du inte använder alla varje dag.

Generera säkra slumptal och lösenord

OpenSSL är en utmärkt källa till kryptografiskt säker slump. Behöver du ett starkt lösenord eller en API-nyckel:

# 32 byte slump som base64 (bra lösenord)
openssl rand -base64 32

# 16 byte som hex (bra för tokens)
openssl rand -hex 16

Hasha och signera filer

Du kan signera en fil med din privatnyckel och låta andra verifiera med din publika nyckel, samma princip som digitala signaturer på programuppdateringar:

# Signera
openssl dgst -sha256 -sign ed25519.key -out fil.sig fil.txt
# Verifiera
openssl dgst -sha256 -verify ed25519.pub -signature fil.sig fil.txt

Hantera flera SAN och jokertecken

Ett certifikat kan täcka flera domäner, inklusive jokertecken. I extensionsfilen anger du helt enkelt fler rader: subjectAltName = DNS:example.se,DNS:*.example.se,DNS:api.example.se. Var dock medveten om att ett jokertecken bara matchar en nivå, så *.example.se täcker api.example.se men inte v1.api.example.se. Det här är en vanlig källa till förvirring vid driftsättning av flera subdomäner.

Komplett projekt: hela kedjan i ett skript

Här knyter vi ihop allt. Skriptet nedan bygger en komplett miljö från noll: en egen CA, en servernyckel, ett signerat certifikat med SAN, och en verifiering att allt hänger ihop. Spara det som bygg-ca.sh, gör det körbart med chmod +x bygg-ca.sh och kör det i en tom katalog.

#!/bin/bash
set -euo pipefail
umask 077

DOMAIN="app.example.se"
echo "==> Bygger en komplett CA och certifikat för $DOMAIN"

# 1. Skapa CA (rotnyckel + rotcertifikat, 10 år)
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ca.key
openssl req -x509 -new -key ca.key -sha256 -days 3650 \
  -subj "/C=SE/O=Example Lab CA/CN=Example Root CA" -out ca.crt
echo "==> CA skapad: ca.crt"

# 2. Servernyckel + CSR
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out site.key
openssl req -new -key site.key -subj "/C=SE/O=Example AB/CN=$DOMAIN" -out site.csr

# 3. Extensionsfil med SAN och rätt användning
cat > site.ext <<EOF
subjectAltName = DNS:$DOMAIN,DNS:www.$DOMAIN
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
EOF

# 4. CA signerar servercertifikatet (825 dagar)
openssl x509 -req -in site.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -days 825 -sha256 -extfile site.ext -out site.crt
echo "==> Servercertifikat signerat: site.crt"

# 5. Verifiera kedjan
echo "==> Verifierar..."
openssl verify -CAfile ca.crt site.crt

# 6. Bekräfta att nyckel och cert matchar
K=$(openssl pkey -in site.key -pubout -outform DER | openssl sha256)
C=$(openssl x509 -in site.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl sha256)
if [ "$K" = "$C" ]; then
  echo "==> OK: nyckel och certifikat matchar."
else
  echo "==> FEL: nyckel och certifikat matchar INTE!" >&2
  exit 1
fi

echo "==> Klart. Filer: ca.crt, ca.key, site.crt, site.key"

Förväntad utdata när allt fungerar:

==> Bygger en komplett CA och certifikat för app.example.se
==> CA skapad: ca.crt
==> Servercertifikat signerat: site.crt
==> Verifierar...
site.crt: OK
==> OK: nyckel och certifikat matchar.
==> Klart. Filer: ca.crt, ca.key, site.crt, site.key

Med set -euo pipefail avbryts skriptet vid första fel, vilket gör det säkert att köra i automation. Du har nu en återanvändbar mall som du kan anpassa för vilken domän som helst genom att bara ändra variabeln DOMAIN högst upp.

Sammanfattning och nästa steg

Du har gått från att kontrollera din OpenSSL-version till att bygga en komplett certifikatinfrastruktur och förbereda för postkvantkryptografi. De viktigaste lärdomarna: använd genpkey i stället för äldre kommandon, glöm aldrig subjectAltName, skydda dina privatnycklar med rätt rättigheter, och automatisera förnyelsen av riktiga certifikat. OpenSSL 3.5 LTS ger dig stöd ända till 2030 och en färdig väg in i den postkvantsäkra eran.

Nästa naturliga steg är att koppla dina certifikat till en riktig webbserver, sätta upp automatisk förnyelse med en ACME-klient, och läsa in dig på hur TLS-handskakningen faktiskt fungerar. OpenSSL är fönstret in i hela den moderna kryptografin, och med stegen ovan har du verktygen för att felsöka i stort sett vilket certifikatproblem som helst.

Relaterad läsning

Vanliga frågor om OpenSSL

Vilken OpenSSL-version ska jag använda 2026?

OpenSSL 3.5 LTS är rätt val för produktion. Den släpptes 8 april 2025 och får stöd till 8 april 2030. Den senaste utgåvan i grenen var 3.5.7 i juni 2026. Undvik att stanna på 3.0, vars fulla stöd upphörde i september 2025, och välj 3.5 framför 3.6 eftersom 3.6 inte är en LTS-version.

Vad är skillnaden mellan genpkey och genrsa?

genpkey är det moderna, generella kommandot i OpenSSL 3.x och hanterar alla algoritmer, inklusive RSA, EC, Ed25519 och de nya postkvantalgoritmerna. genrsa är äldre och bara för RSA. Använd alltid genpkey i ny dokumentation och nya skript.

Varför avvisar webbläsaren mitt certifikat trots rätt Common Name?

För att moderna webbläsare ignorerar Common Name vid värdnamnsvalidering och kräver fältet subjectAltName (SAN). Lägg till -addext "subjectAltName=DNS:dindomän.se" när du skapar CSR eller certifikat. Det här är den vanligaste enskilda orsaken till certifikatfel.

Ska jag välja RSA, ECDSA eller Ed25519?

Välj Ed25519 för nya interna system där du styr båda ändarna, ECDSA P-256 för bred TLS-kompatibilitet, och RSA (minst 2048, helst 3072) bara när äldre klienter eller regelverk kräver det. Elliptiska kurvor ger samma säkerhet som RSA med mindre nycklar och högre prestanda.

Stöder OpenSSL postkvantkryptografi?

Ja. OpenSSL 3.5 LTS var den första utgåvan med inbyggt stöd för de NIST-standardiserade algoritmerna ML-KEM (nyckelinkapsling), ML-DSA och SLH-DSA (signaturer). I praktiken används de 2026 oftast i hybridläge tillsammans med en klassisk algoritm under övergångsperioden.

Hur kontrollerar jag när ett certifikat går ut?

Kör openssl x509 -in cert.crt -noout -enddate för en lokal fil, eller openssl s_client -connect domän.se:443 | openssl x509 -noout -dates för en publik server. För automatisk övervakning använder du openssl x509 -checkend 2592000, som returnerar fel om certifikatet går ut inom 30 dagar.

Är ett självsignerat certifikat säkert?

Krypteringen är lika stark som hos ett betrott certifikat, men ingen utomstående litar på det automatiskt. Det passar för utveckling, interna tjänster och testmiljöer. För publika webbplatser bör du använda ett certifikat från en betrodd utfärdare, exempelvis gratis via Let’s Encrypt, så att besökarna slipper varningar.

OpenSSL 3.5: nycklar och certifikat i 12 steg [2026]