{"id":88,"date":"2026-06-15T16:59:06","date_gmt":"2026-06-15T16:59:06","guid":{"rendered":"https:\/\/shattered.io\/no\/2026\/06\/15\/https-tls-13-nodejs\/"},"modified":"2026-06-16T08:45:08","modified_gmt":"2026-06-16T08:45:08","slug":"https-tls-13-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/no\/https-tls-13-nodejs\/","title":{"rendered":"HTTPS og TLS 1.3 i Node.js: 12 steg [2026]"},"content":{"rendered":"\n

HTTPS<\/strong> er ikke lenger valgfritt. Over 95 prosent av all sidelasting i Chrome skjer i dag over kryptert tilkobling, if\u00f8lge Googles Transparency Report, og nettlesere markerer rene HTTP-sider som \u00abikke sikre\u00bb. Samtidig kortes levetiden p\u00e5 sertifikater dramatisk ned: CA\/Browser Forum vedtok i 2025 (ballot SC-081) at maksimal gyldighet for offentlige TLS-sertifikater faller til 200 dager fra mars 2026, 100 dager fra mars 2027 og bare 47 dager fra mars 2029. Manuell fornyelse er d\u00f8d. Denne veiledningen viser deg steg for steg hvordan du setter opp en produksjonsklar HTTPS<\/strong>-server i Node.js med TLS<\/strong> 1.3, automatisk sertifikatfornyelse og riktige sikkerhetshoder.<\/p>\n\n\n\n

Du trenger ikke \u00e5 v\u00e6re kryptograf for \u00e5 f\u00f8lge med. Du trenger en Linux-server, Node.js og rundt 40 minutter. Vi bruker OpenSSL<\/strong> til lokale testsertifikater, https.createServer()<\/code> i Node.js til selve serveren, og Let’s Encrypt med certbot til ekte sertifikater i produksjon. Til slutt har du et komplett, fungerende prosjekt med karakteren A p\u00e5 SSL Labs.<\/p>\n\n\n\n

Hvorfor HTTPS og TLS 1.3 er standarden i 2026<\/h2>\n\n\n\n

HTTPS<\/strong> er HTTP pakket inn i TLS<\/strong> (Transport Layer Security). TLS s\u00f8rger for tre ting p\u00e5 \u00e9n gang: konfidensialitet (ingen kan lese trafikken), integritet (ingen kan endre den underveis) og autentisering (du snakker med riktig server). Uten TLS kan en angriper p\u00e5 samme nettverk lese passord, kapre sesjoner og injisere skadelig kode. Med TLS 1.3 er disse angrepene praktisk talt stengt ute, forutsatt at du konfigurerer serveren riktig.<\/p>\n\n\n\n

TLS 1.3 ble standardisert i RFC 8446 og er n\u00e5 den dominerende versjonen p\u00e5 nettet. Den fjernet alle de svake byggeklossene fra TLS 1.2: RSA-n\u00f8kkelutveksling, CBC-modus, RC4, SHA-1 og kompresjon. Resultatet er et protokollag som er b\u00e5de raskere og enklere \u00e5 sette opp riktig. I TLS 1.3 forhandles ikke n\u00f8kkelutveksling lenger gjennom navnet p\u00e5 chifferpakken, s\u00e5 du st\u00e5r igjen med bare tre godkjente pakker i stedet for dusinvis av risikable kombinasjoner.<\/p>\n\n\n\n

Den store driveren i 2026 er kortere sertifikatlevetid. Apple foreslo opprinnelig 47-dagers sertifikater, og CA\/Browser Forum vedtok en gradvis nedtrapping. Tabellen under viser tidslinjen du m\u00e5 planlegge for. Poenget er enkelt: alt m\u00e5 automatiseres. En server som er avhengig av at noen husker \u00e5 forny et sertifikat \u00e9n gang i \u00e5ret, kommer til \u00e5 g\u00e5 ned.<\/p>\n\n\n\n

Dato<\/th>Maks gyldighet<\/th>Maks gjenbruk av domenevalidering<\/th>Konsekvens<\/th><\/tr><\/thead>
F\u00f8r mars 2026<\/td>398 dager<\/td>398 dager<\/td>\u00c5rlig fornyelse mulig<\/td><\/tr>
15. mars 2026<\/td>200 dager<\/td>200 dager<\/td>Halv\u00e5rlig fornyelse<\/td><\/tr>
15. mars 2027<\/td>100 dager<\/td>100 dager<\/td>Kvartalsvis fornyelse<\/td><\/tr>
15. mars 2029<\/td>47 dager<\/td>10 dager<\/td>Full automatisering p\u00e5krevd<\/td><\/tr><\/tbody><\/table>
Kilde: CA\/Browser Forum ballot SC-081 (vedtatt 2025).<\/figcaption><\/figure>\n\n\n\n

Vil du forst\u00e5 de grunnleggende begrepene bak l\u00e5sen i adresselinjen, har vi en egen forklaring i HTTPS og TLS: slik beskyttes forbindelsen din p\u00e5 nett<\/a>. Denne artikkelen er den praktiske oppf\u00f8lgeren: vi bygger faktisk serveren.<\/p>\n\n\n\n

Slik fungerer TLS 1.3-h\u00e5ndtrykket<\/h2>\n\n\n\n

F\u00f8r koden er det verdt \u00e5 forst\u00e5 hvorfor TLS 1.3 er raskere. H\u00e5ndtrykket er prosessen der klient og server blir enige om n\u00f8kler. I TLS 1.2 tar et fullt h\u00e5ndtrykk to rundturer (2-RTT): klienten sier hei, serveren svarer, klienten sender n\u00f8kkelmateriale, serveren bekrefter. F\u00f8rst da kan applikasjonsdata flyte. P\u00e5 en forbindelse med 50 millisekunder rundturstid betyr det rundt 100 millisekunder forsinkelse f\u00f8r f\u00f8rste byte med innhold.<\/p>\n\n\n\n

TLS 1.3 kollapser dette til \u00e9n rundtur (1-RTT). Klienten gjetter hvilken n\u00f8kkelutvekslingsgruppe serveren st\u00f8tter og sender n\u00f8kkelmateriale allerede i f\u00f8rste melding. P\u00e5 samme 50 ms-forbindelse er h\u00e5ndtrykket nede i rundt 50 millisekunder. For gjenopptatte sesjoner kan TLS 1.3 til og med bruke 0-RTT, der de f\u00f8rste applikasjonsdataene sendes sammen med h\u00e5ndtrykket. Tabellen oppsummerer forskjellen.<\/p>\n\n\n\n

Egenskap<\/th>TLS 1.2<\/th>TLS 1.3<\/th><\/tr><\/thead>
Fullt h\u00e5ndtrykk<\/td>2-RTT<\/td>1-RTT<\/td><\/tr>
Gjenopptatt sesjon<\/td>1-RTT<\/td>0-RTT eller 1-RTT<\/td><\/tr>
H\u00e5ndtrykk ved 50 ms RTT<\/td>~100 ms<\/td>~50 ms<\/td><\/tr>
Godkjente chifferpakker<\/td>Dusinvis<\/td>3<\/td><\/tr>
RSA-n\u00f8kkelutveksling<\/td>Tillatt<\/td>Fjernet<\/td><\/tr>
Forward secrecy<\/td>Valgfritt<\/td>Obligatorisk<\/td><\/tr><\/tbody><\/table>
TLS 1.3 reduserer b\u00e5de forsinkelse og angrepsflate.<\/figcaption><\/figure>\n\n\n\n

\u00abForward secrecy\u00bb betyr at hver sesjon f\u00e5r en unik, midlertidig n\u00f8kkel. Selv om en angriper senere stjeler serverens private n\u00f8kkel, kan de ikke dekryptere gammel trafikk de har spilt inn. I TLS 1.3 er dette ikke valgfritt lenger, det er bakt inn i protokollen. Det er en av grunnene til at vi tvinger fram TLS 1.3 senere i veiledningen.<\/p>\n\n\n\n

Forutsetninger og versjoner<\/h2>\n\n\n\n

Versjoner betyr noe for TLS. Eldre Node.js- og OpenSSL-bygg mangler full TLS 1.3-st\u00f8tte og post-kvante-n\u00f8kkelutveksling. Bruk minst Node.js 24 LTS, som er den anbefalte produksjonsbasen midt i 2026 med sikkerhetsst\u00f8tte fram til 30. april 2028. Node.js 24 pakker en moderne OpenSSL 3.x-gren, som er det du trenger for b\u00e5de TLS 1.3 og hybrid post-kvante-utveksling.<\/p>\n\n\n\n

Komponent<\/th>Minimumsversjon<\/th>Sjekk med<\/th>Merknad<\/th><\/tr><\/thead>
Node.js<\/td>24 LTS (24.16.0+)<\/td>node -v<\/code><\/td>Unng\u00e5 \u00abCurrent\u00bb-linjer i produksjon<\/td><\/tr>
OpenSSL (i Node)<\/td>3.x<\/td>node -p process.versions.openssl<\/code><\/td>F\u00f8lger med Node.js<\/td><\/tr>
OpenSSL (CLI)<\/td>3.x<\/td>openssl version<\/code><\/td>Til testsertifikater<\/td><\/tr>
certbot<\/td>3.x<\/td>certbot --version<\/code><\/td>Til Let’s Encrypt<\/td><\/tr>
Operativsystem<\/td>Ubuntu 24.04 LTS<\/td>lsb_release -a<\/code><\/td>Eller tilsvarende Linux<\/td><\/tr><\/tbody><\/table>
Anbefalt programvarestabel for HTTPS-veiledningen.<\/figcaption><\/figure>\n\n\n\n

Du trenger ogs\u00e5 et domenenavn som peker mot serveren din (en A-post mot serverens IP) for \u00e5 hente et ekte Let’s Encrypt-sertifikat senere. Til de f\u00f8rste stegene holder det med localhost<\/code> og et selvsignert sertifikat. Sjekk versjonene dine f\u00f8r du g\u00e5r videre:<\/p>\n\n\n\n

$ node -v\nv24.16.0\n$ node -p process.versions.openssl\n3.5.1\n$ openssl version\nOpenSSL 3.5.1 1 Jul 2025\n$ certbot --version\ncertbot 3.2.0<\/code><\/pre>\n\n\n\n
Steg 1: Prosjektoppsett<\/h2>\n\n\n\n
Lag en ren prosjektmappe og initialiser et Node.js-prosjekt. Vi holder oss til Nodes innebygde https<\/code>– og tls<\/code>-moduler i kjernen, slik at du forst\u00e5r hva som faktisk skjer, men legger til Express for et realistisk applikasjonslag.<\/p>\n\n\n\n
$ mkdir https-tls-node && cd https-tls-node\n$ npm init -y\n$ npm install express helmet\n$ mkdir certs src\n$ touch src\/server.js<\/code><\/pre>\n\n\n\n
Mappen certs\/<\/code> holder n\u00f8kler og sertifikater. Legg den til i .gitignore<\/code> umiddelbart. Private n\u00f8kler skal aldri inn i versjonskontroll, og en lekket n\u00f8kkel er en av de vanligste \u00e5rsakene til kompromitterte servere.<\/p>\n\n\n\n
$ echo \"certs\/\" >> .gitignore\n$ echo \"node_modules\/\" >> .gitignore<\/code><\/pre>\n\n\n\n
Steg 2: Lag et selvsignert sertifikat med OpenSSL<\/h2>\n\n\n\n
For lokal utvikling lager vi et selvsignert sertifikat med OpenSSL<\/strong>. Et selvsignert sertifikat er ikke klarert av nettlesere (du f\u00e5r en advarsel), men det krypterer forbindelsen helt likt et ekte sertifikat, og det er perfekt til testing. Kommandoen under lager en privat n\u00f8kkel og et sertifikat som er gyldig i 365 dager, med moderne elliptisk kurve (P-256) i stedet for treg RSA.<\/p>\n\n\n\n
$ openssl req -x509 -newkey ec \\\n  -pkeyopt ec_paramgen_curve:prime256v1 \\\n  -keyout certs\/key.pem \\\n  -out certs\/cert.pem \\\n  -days 365 -nodes \\\n  -subj \"\/C=NO\/ST=Oslo\/L=Oslo\/O=Dev\/CN=localhost\" \\\n  -addext \"subjectAltName=DNS:localhost,IP:127.0.0.1\"<\/code><\/pre>\n\n\n\n
Flagget -nodes<\/code> betyr \u00abno DES\u00bb, alts\u00e5 at den private n\u00f8kkelen ikke krypteres med passord. Det er greit lokalt, men i produksjon henter vi n\u00f8kkelen fra Let’s Encrypt i stedet. subjectAltName<\/code> er kritisk: moderne nettlesere ignorerer feltet CN<\/code> og krever at vertsnavnet st\u00e5r i SAN. Glemmer du dette, f\u00e5r du feilen ERR_CERT_COMMON_NAME_INVALID<\/code>. Bekreft at sertifikatet ble laget riktig:<\/p>\n\n\n\n
$ openssl x509 -in certs\/cert.pem -noout -text | grep -A1 \"Subject Alternative Name\"\n            X509v3 Subject Alternative Name:\n                DNS:localhost, IP Address:127.0.0.1<\/code><\/pre>\n\n\n\n
Steg 3: Din f\u00f8rste HTTPS-server i Node.js<\/h2>\n\n\n\n
N\u00e5 bygger vi den enkleste mulige HTTPS<\/strong>-serveren. Vi leser n\u00f8kkel og sertifikat fra disk og sender dem inn i https.createServer()<\/code>. Legg merke til at vi bruker fs.readFileSync<\/code> ved oppstart, ikke ved hver foresp\u00f8rsel: filene leses \u00e9n gang og holdes i minnet.<\/p>\n\n\n\n
\/\/ src\/server.js\nimport https from 'node:https';\nimport fs from 'node:fs';\nimport express from 'express';\n\nconst app = express();\n\napp.get('\/', (req, res) => {\n  res.send('Hei fra en kryptert HTTPS-tilkobling.');\n});\n\nconst options = {\n  key: fs.readFileSync('certs\/key.pem'),\n  cert: fs.readFileSync('certs\/cert.pem'),\n};\n\nhttps.createServer(options, app).listen(8443, () => {\n  console.log('HTTPS-server kjorer pa https:\/\/localhost:8443');\n});<\/code><\/pre>\n\n\n\n
Sett \"type\": \"module\"<\/code> i package.json<\/code> for \u00e5 bruke import<\/code>. Start serveren med node src\/server.js<\/code> og \u00e5pne https:\/\/localhost:8443<\/code>. Nettleseren advarer om sertifikatet (fordi det er selvsignert), men forbindelsen er kryptert. Tester du med curl, ser du resultatet av h\u00e5ndtrykket:<\/p>\n\n\n\n
$ curl -k -v https:\/\/localhost:8443 2>&1 | grep -i \"SSL connection\"\n* SSL connection using TLSv1.3 \/ TLS_AES_256_GCM_SHA384<\/code><\/pre>\n\n\n\n
Flagget -k<\/code> ber curl godta det selvsignerte sertifikatet. Legg merke til at Node.js allerede forhandlet fram TLS 1.3 og en sterk chifferpakke uten at vi ba om det. Standardinnstillingene i Node.js 24 er gode, men i neste steg l\u00e5ser vi dem fast slik at ingen klient kan presse forbindelsen ned til en svakere protokoll.<\/p>\n\n\n\n
Steg 4: Tving fram TLS 1.3 og velg chifferpakker<\/h2>\n\n\n\n
Standardinnstillingen i Node.js tillater fortsatt TLS 1.2 for bakoverkompatibilitet. For en ny tjeneste i 2026 vil du som regel kreve TLS 1.3 og avvise alt eldre. Det gj\u00f8r du med minVersion<\/code>. Vil du beholde TLS 1.2 for noen f\u00e5 gamle klienter, setter du minVersion: 'TLSv1.2'<\/code> i stedet og definerer en streng chifferliste.<\/p>\n\n\n\n
const options = {\n  key: fs.readFileSync('certs\/key.pem'),\n  cert: fs.readFileSync('certs\/cert.pem'),\n  \/\/ Krev TLS 1.3, avvis alt eldre\n  minVersion: 'TLSv1.3',\n  maxVersion: 'TLSv1.3',\n  \/\/ De tre godkjente TLS 1.3-pakkene\n  ciphers: [\n    'TLS_AES_256_GCM_SHA384',\n    'TLS_CHACHA20_POLY1305_SHA256',\n    'TLS_AES_128_GCM_SHA256',\n  ].join(':'),\n  honorCipherOrder: true,\n};<\/code><\/pre>\n\n\n\n
De tre pakkene er de eneste TLS 1.3 definerer. TLS_AES_256_GCM_SHA384<\/code> er f\u00f8rstevalget p\u00e5 maskiner med AES-akselerasjon (nesten alle moderne CPU-er). TLS_CHACHA20_POLY1305_SHA256<\/code> er raskere p\u00e5 enheter uten slik akselerasjon, typisk eldre mobiler. honorCipherOrder: true<\/code> betyr at serveren bestemmer rekkef\u00f8lgen, ikke klienten. Vil du st\u00f8tte begge TLS-versjoner samtidig, kan du la Mozilla generere en trygg konfigurasjon for deg via deres SSL Configuration Generator. Verifiser at serveren n\u00e5 avviser TLS 1.2:<\/p>\n\n\n\n
$ curl -k --tlsv1.2 --tls-max 1.2 https:\/\/localhost:8443\ncurl: (35) error:0A00010B:SSL routines::wrong version number<\/code><\/pre>\n\n\n\n
Steg 5: Omdiriger all HTTP-trafikk til HTTPS<\/h2>\n\n\n\n
En HTTPS<\/strong>-server alene hjelper lite hvis brukerne fortsatt kan n\u00e5 deg over vanlig HTTP. Du m\u00e5 lytte p\u00e5 port 80 og omdirigere alt til port 443 med statuskode 301 (permanent flytting). Dette er ogs\u00e5 det Let’s Encrypt bruker til \u00e5 validere domenet ditt, s\u00e5 porten m\u00e5 v\u00e6re \u00e5pen.<\/p>\n\n\n\n
import http from 'node:http';\n\n\/\/ Egen liten server kun for omdirigering\nhttp.createServer((req, res) => {\n  const host = req.headers.host?.split(':')[0] ?? 'localhost';\n  res.writeHead(301, {\n    Location: `https:\/\/${host}${req.url}`,\n  });\n  res.end();\n}).listen(80, () => {\n  console.log('HTTP-omdirigering aktiv pa port 80');\n});<\/code><\/pre>\n\n\n\n
Bruk 301, ikke 302. En 302 (midlertidig) blir ikke bufret av nettlesere, s\u00e5 de pr\u00f8ver HTTP p\u00e5 nytt hver gang. En 301 forteller nettleseren at den alltid skal bruke HTTPS for dette domenet. Kombinert med HSTS i neste steg betyr det at brukeren nesten aldri sender en ukryptert foresp\u00f8rsel etter f\u00f8rste bes\u00f8k. Porter under 1024 krever rotrettigheter; i produksjon kj\u00f8rer du heller bak en reversproxy eller gir Node-prosessen CAP_NET_BIND_SERVICE<\/code>.<\/p>\n\n\n\n
Steg 6: HSTS og sikkerhetshoder med Helmet<\/h2>\n\n\n\n
HSTS (HTTP Strict Transport Security) er et svar-hode som ber nettleseren om \u00e5 alltid bruke HTTPS for domenet ditt, selv om brukeren skriver http:\/\/<\/code>. Det stenger en hel klasse angrep der en angriper avskj\u00e6rer den aller f\u00f8rste foresp\u00f8rselen. Vi bruker Helmet, som setter HSTS og en rekke andre sikkerhetshoder med fornuftige standardverdier.<\/p>\n\n\n\n
import helmet from 'helmet';\n\napp.use(helmet({\n  hsts: {\n    maxAge: 63072000,        \/\/ 2 ar i sekunder\n    includeSubDomains: true,\n    preload: true,\n  },\n  contentSecurityPolicy: {\n    directives: {\n      defaultSrc: [\"'self'\"],\n      scriptSrc: [\"'self'\"],\n      objectSrc: [\"'none'\"],\n      upgradeInsecureRequests: [],\n    },\n  },\n}));<\/code><\/pre>\n\n\n\n
Verdien maxAge: 63072000<\/code> er to \u00e5r, som er kravet for \u00e5 komme p\u00e5 HSTS-preloadlisten. Preloadlisten er bakt inn i nettleserne selv, slik at de bruker HTTPS for domenet ditt allerede f\u00f8r f\u00f8rste bes\u00f8k. N\u00e5r du er sikker p\u00e5 at hele domenet kj\u00f8rer HTTPS uten unntak, kan du sende det inn p\u00e5 hstspreload.org. V\u00e6r forsiktig: preload er vanskelig \u00e5 reversere raskt, s\u00e5 test grundig f\u00f8rst. Sjekk at hodet faktisk sendes:<\/p>\n\n\n\n
$ curl -kI https:\/\/localhost:8443 | grep -i strict\nstrict-transport-security: max-age=63072000; includeSubDomains; preload<\/code><\/pre>\n\n\n\n
Steg 7: Ekte sertifikat med Let’s Encrypt og certbot<\/h2>\n\n\n\n
Selvsignerte sertifikater duger til testing, men i produksjon trenger du et sertifikat fra en klarert myndighet. Let’s Encrypt er den dominerende gratis sertifikatmyndigheten, med flere hundre millioner aktive sertifikater, og utsteder dem helautomatisk via ACME-protokollen. Verkt\u00f8yet certbot snakker ACME for deg. Installer det og hent et sertifikat for domenet ditt:<\/p>\n\n\n\n
$ sudo apt update && sudo apt install certbot\n$ sudo certbot certonly --standalone \\\n  -d eksempel.no -d www.eksempel.no \\\n  --email admin@eksempel.no \\\n  --agree-tos --no-eff-email<\/code><\/pre>\n\n\n\n
Modusen --standalone<\/code> lar certbot starte sin egen lille webserver p\u00e5 port 80 for \u00e5 bevise at du kontrollerer domenet (HTTP-01-utfordringen). Derfor m\u00e5 du stoppe din egen server p\u00e5 port 80 mens dette kj\u00f8rer, eller bruke --webroot<\/code> i stedet. N\u00e5r det er ferdig, ligger filene her:<\/p>\n\n\n\n
\/etc\/letsencrypt\/live\/eksempel.no\/fullchain.pem   # sertifikat + mellomledd\n\/etc\/letsencrypt\/live\/eksempel.no\/privkey.pem     # privat nokkel<\/code><\/pre>\n\n\n\n
Bruk fullchain.pem<\/code>, ikke cert.pem<\/code>. Fullkjeden inneholder b\u00e5de ditt sertifikat og Let’s Encrypts mellomsertifikat, slik at klienter kan bygge hele tillitskjeden. Glemmer du mellomleddet, fungerer siden i Chrome (som bufrer mellomsertifikater) men feiler i mange andre klienter. Pek serveren mot de nye filene:<\/p>\n\n\n\n
const options = {\n  key: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/privkey.pem'),\n  cert: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/fullchain.pem'),\n  minVersion: 'TLSv1.3',\n};<\/code><\/pre>\n\n\n\n
Steg 8: Automatisk fornyelse (47-dagers kravet)<\/h2>\n\n\n\n
Med sertifikatlevetider p\u00e5 vei mot 47 dager er automatisk fornyelse ikke en luksus, men en forutsetning. Certbot installerer som regel en systemd-timer som fornyer automatisk. Sjekk at den er aktiv og test en t\u00f8rrkj\u00f8ring:<\/p>\n\n\n\n
$ sudo systemctl list-timers | grep certbot\n$ sudo certbot renew --dry-run<\/code><\/pre>\n\n\n\n
Et problem gjenst\u00e5r: n\u00e5r certbot fornyer sertifikatet, leser ikke Node.js de nye filene automatisk. Du har to valg. Det enkleste er en deploy-hook som restarter tjenesten etter fornyelse. Det mer elegante er \u00e5 laste sertifikatet p\u00e5 nytt uten nedetid med setSecureContext<\/code>. Her er deploy-hook-varianten:<\/p>\n\n\n\n
$ sudo certbot renew \\\n  --deploy-hook \"systemctl reload min-node-app\"<\/code><\/pre>\n\n\n\n
For null nedetid kan du i stedet overv\u00e5ke sertifikatfilen og bytte ut sikkerhetskonteksten i farten. Da slipper klientene som er midt i en foresp\u00f8rsel \u00e5 bli kastet ut:<\/p>\n\n\n\n
import tls from 'node:tls';\n\nconst server = https.createServer(options, app);\n\n\/\/ Bytt sertifikat uten omstart nar filen endres\nfs.watch('\/etc\/letsencrypt\/live\/eksempel.no\/', () => {\n  const ctx = tls.createSecureContext({\n    key: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/privkey.pem'),\n    cert: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/fullchain.pem'),\n  });\n  server.setSecureContext(ctx);\n  console.log('Sertifikat lastet pa nytt uten nedetid');\n});<\/code><\/pre>\n\n\n\n
Steg 9: Sesjonsgjenopptak og ytelse<\/h2>\n\n\n\n
Et fullt TLS-h\u00e5ndtrykk koster CPU og en rundtur. Sesjonsgjenopptak lar en klient som har v\u00e6rt innom f\u00f8r hoppe over deler av h\u00e5ndtrykket. I TLS 1.3 skjer dette med \u00absession tickets\u00bb. Node.js h\u00e5ndterer dette automatisk, men i en klynge med flere prosesser m\u00e5 alle dele samme n\u00f8kkel for tickets, ellers kan ikke en klient gjenoppta en sesjon p\u00e5 en annen prosess.<\/p>\n\n\n\n
import crypto from 'node:crypto';\n\n\/\/ Delt ticket-nokkel pa tvers av prosesser (48 byte)\nconst ticketKeys = crypto.randomBytes(48);\n\nconst options = {\n  key: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/privkey.pem'),\n  cert: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/fullchain.pem'),\n  minVersion: 'TLSv1.3',\n  ticketKeys,                 \/\/ samme nokkel i alle arbeidsprosesser\n  sessionTimeout: 300,        \/\/ gjenopptak gyldig i 5 minutter\n};<\/code><\/pre>\n\n\n\n
Pass p\u00e5 0-RTT. Det er fristende fordi det fjerner all h\u00e5ndtrykksforsinkelse, men 0-RTT-data er s\u00e5rbare for replay-angrep: en angriper kan spille av den samme foresp\u00f8rselen flere ganger. Bruk det aldri p\u00e5 foresp\u00f8rsler som endrer tilstand (POST, PUT, DELETE). Node.js har 0-RTT av som standard, og det b\u00f8r du la det v\u00e6re med mindre du vet n\u00f8yaktig hva du gj\u00f8r. OCSP-stapling, der serveren selv vedlegger et ferskt tilbakekallingssvar, var tidligere viktig, men med korte sertifikatlevetider er den operasjonelle verdien redusert. Fokuser heller energien p\u00e5 automatisk fornyelse.<\/p>\n\n\n\n
Steg 10: Post-kvante TLS med X25519MLKEM768<\/h2>\n\n\n\n
En kvantedatamaskin som er kraftig nok vil kunne knekke dagens n\u00f8kkelutveksling og dekryptere trafikk angripere lagrer i dag (\u00abharvest now, decrypt later\u00bb). Som svar ruller Chrome og Cloudflare i 2025 ut en hybrid n\u00f8kkelutveksling kalt X25519MLKEM768<\/code>, som kombinerer den klassiske X25519-kurven med den kvanteresistente ML-KEM-768 (tidligere Kyber). Knekker noen den ene, beskytter den andre fortsatt.<\/p>\n\n\n\n
Med en moderne OpenSSL 3.x-gren i Node.js 24 kan du be om denne gruppen via ecdhCurve<\/code>. Dette er fortsatt nytt interoperabilitetsarbeid, s\u00e5 ikke gj\u00f8r det til et hardt krav som avviser eldre klienter enn\u00e5. Tilby det som et alternativ:<\/p>\n\n\n\n
const options = {\n  key: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/privkey.pem'),\n  cert: fs.readFileSync('\/etc\/letsencrypt\/live\/eksempel.no\/fullchain.pem'),\n  minVersion: 'TLSv1.3',\n  \/\/ Hybrid post-kvante forst, deretter klassisk fallback\n  ecdhCurve: 'X25519MLKEM768:X25519:prime256v1',\n};<\/code><\/pre>\n\n\n\n
Klienter som forst\u00e5r hybrid-gruppen bruker den; resten faller pent tilbake til X25519. Du f\u00e5r framtidssikring uten \u00e5 bryte noe. Vil du dykke dypere i hvorfor dette haster, har vi en bredere gjennomgang av digitale signaturer og asymmetriske n\u00f8kler<\/a>.<\/p>\n\n\n\n
Steg 11: Komplett, fungerende prosjekt<\/h2>\n\n\n\n
Her er hele serveren satt sammen: HTTP-omdirigering, HTTPS med TLS 1.3, sikkerhetshoder, sesjonsgjenopptak, hybrid post-kvante-utveksling og varm omlasting av sertifikat. Dette er et realistisk utgangspunkt for produksjon.<\/p>\n\n\n\n
\/\/ src\/server.js  (komplett)\nimport https from 'node:https';\nimport http from 'node:http';\nimport tls from 'node:tls';\nimport fs from 'node:fs';\nimport crypto from 'node:crypto';\nimport express from 'express';\nimport helmet from 'helmet';\n\nconst DOMAIN = process.env.DOMAIN ?? 'eksempel.no';\nconst CERT_DIR = `\/etc\/letsencrypt\/live\/${DOMAIN}`;\nconst app = express();\n\napp.use(helmet({\n  hsts: { maxAge: 63072000, includeSubDomains: true, preload: true },\n}));\n\napp.get('\/', (req, res) => {\n  res.send('Sikker HTTPS-tilkobling med TLS 1.3.');\n});\n\napp.get('\/health', (req, res) => res.json({ status: 'ok' }));\n\nfunction loadCerts() {\n  return {\n    key: fs.readFileSync(`${CERT_DIR}\/privkey.pem`),\n    cert: fs.readFileSync(`${CERT_DIR}\/fullchain.pem`),\n  };\n}\n\nconst options = {\n  ...loadCerts(),\n  minVersion: 'TLSv1.3',\n  ciphers: [\n    'TLS_AES_256_GCM_SHA384',\n    'TLS_CHACHA20_POLY1305_SHA256',\n    'TLS_AES_128_GCM_SHA256',\n  ].join(':'),\n  honorCipherOrder: true,\n  ecdhCurve: 'X25519MLKEM768:X25519:prime256v1',\n  ticketKeys: crypto.randomBytes(48),\n  sessionTimeout: 300,\n};\n\nconst server = https.createServer(options, app);\n\n\/\/ Varm omlasting nar certbot fornyer\nfs.watch(CERT_DIR, () => {\n  try {\n    server.setSecureContext(tls.createSecureContext(loadCerts()));\n    console.log('Sertifikat lastet pa nytt');\n  } catch (err) {\n    console.error('Klarte ikke laste sertifikat:', err.message);\n  }\n});\n\nserver.listen(443, () => console.log(`HTTPS aktiv pa https:\/\/${DOMAIN}`));\n\n\/\/ Omdiriger HTTP til HTTPS\nhttp.createServer((req, res) => {\n  const host = req.headers.host?.split(':')[0] ?? DOMAIN;\n  res.writeHead(301, { Location: `https:\/\/${host}${req.url}` });\n  res.end();\n}).listen(80);<\/code><\/pre>\n\n\n\n
Kj\u00f8r serveren bak en prosessoverv\u00e5ker som systemd eller PM2, slik at den starter p\u00e5 nytt ved krasj og ved omstart av serveren. Sett DOMAIN<\/code> som milj\u00f8variabel, s\u00e5 kan samme kode kj\u00f8re i flere milj\u00f8er uten endring.<\/p>\n\n\n\n
Steg 12: Verifiser med SSL Labs og curl<\/h2>\n\n\n\n
Test alltid den ferdige serveren utenfra. Det enkleste er Qualys SSL Labs-test, som gir karakter fra A+ til F og p\u00e5peker svakheter. M\u00e5l er A eller A+. Lokalt verifiserer du protokoll og chiffer med curl:<\/p>\n\n\n\n
$ curl -vI https:\/\/eksempel.no 2>&1 | grep -iE \"SSL connection|HTTP\/\"\n* SSL connection using TLSv1.3 \/ TLS_AES_256_GCM_SHA384\nHTTP\/2 200\n\n$ echo | openssl s_client -connect eksempel.no:443 \\\n  -tls1_3 2>\/dev\/null | grep -E \"Protocol|Cipher\"\n    Protocol  : TLSv1.3\n    Cipher    : TLS_AES_256_GCM_SHA384<\/code><\/pre>\n\n\n\n
For en A+-karakter trenger du som regel TLS 1.3, HSTS med lang maxAge<\/code>, ingen st\u00f8tte for TLS 1.0\/1.1, et gyldig sertifikat med full kjede og forward secrecy. F\u00f8lger du stegene over, har du alt dette. Kj\u00f8r testen p\u00e5 nytt etter hver st\u00f8rre endring i TLS-konfigurasjonen.<\/p>\n\n\n\n
6 vanlige fallgruver<\/h2>\n\n\n\n