OpenSSL 3.x: Sikkerhedsforbedringer til hostingsystemer

Placering af OpenSSL 3.x i hostingmiljøet

OpenSSL er et bibliotek til kryptografiske funktioner og TLS. Det stiller blandt andet metoder til kryptering, signaturer, certifikatvalidering og oprettelse af sikre forbindelser til rådighed for applikationer. En opgradering til OpenSSL 3.x forbedrer derfor i første omgang det kryptografiske grundlag for et hostingsystem, men ikke automatisk alle indstillinger for de tjenester, der kører på det.

Om en webserver, mailserver, reverse proxy eller databasetjeneste rent faktisk bruger TLS, og hvilke regler der gælder i den forbindelse, afhænger af dens egen konfiguration. NGINX, Apache, HAProxy, Postfix, Dovecot eller en database-klient vælger for eksempel protokolversioner, certifikater, nøgler og tilladte metoder. Det installerede bibliotek leverer funktioner til dette formål; det erstatter ikke en omhyggelig TLS-politik for den enkelte tjeneste.

Sikkerhedsgevinsten skyldes først og fremmest en understøttet biblioteksversion, moderniserede programmeringsgrænseflader og en klarere afgrænsning af ældre kryptografi. Dette mindsker risikoen for, at applikationer ubevidst fortsætter med at anvende forældede mekanismer. Sikkerhedsopdateringer skal dog stadig installeres rettidigt, og certifikatkæder, private nøgler samt adgangsrettigheder forbliver selvstændige driftsopgaver.

I praksis gælder dette både offentlige og interne forbindelser. På et websted beskytter TLS forbindelsen mellem browseren og reverse-proxyen; i baggrunden kan der være yderligere TLS-forbindelser fra proxyen til applikationsserveren eller fra applikationen til databasen. Hver forbindelse har sine egne modparter og kompatibilitetskrav. Et moderne bibliotek er et vigtigt grundlag herfor, men det er ikke et bevis på, at alle forbindelser er sikret på en ensartet måde.

Applikationer med egen kryptografi-integration kræver særlig opmærksomhed. OpenSSL 3 bruger udbydere og foretrækker abstrakte EVP-grænseflader, mens mange ældre lavniveau-API’er og ENGINE-mekanismer betragtes som forældede. Ved en opgradering kan det derfor ikke kun være en tjenestekonfiguration, men også et plugin, en sprogbinding eller en proprietær udvidelse, der er relevant.

Vælg de rigtige understøttede 3.x-grene

Udsagnet „opdatere til OpenSSL 3“ er for upræcist til driftsplanlægning. Den 19. oktober 2026 vil den officielle downloadside kun angive 3.4, 3.5 og 3.6 som regulært tilgængelige 3.x-grene. Versioner, der ikke er opført, modtager ingen offentlig upstream-support og bør ifølge OpenSSL ikke længere anvendes i produktionsmiljøer. OpenSSL 3.0 og 3.3 er derfor ikke et egnet upstream-grundlag for nye produktionsplaner.

Ved nye projekter inden for 3.x-serien er OpenSSL 3.5 LTS den relevante gren. Supporten herfor er planlagt til at vare indtil den 8. april 2030. OpenSSL 3.4 når sin supportafslutning allerede den 22. oktober 2026, mens OpenSSL 3.6 som en ikke-LTS-gren når sin den 1. november 2026. Hvis man selv administrerer upstream-pakker, skal man derfor tage højde for den konkrete gren og dens udløbsdato.

Når det drejer sig om pakker fra en Linux-distribution, må upstream-versionsstrengen ikke vurderes isoleret. Kontroller i stedet i de officielle oplysninger om pakker, sikkerhed og livscyklus fra den pågældende distributionsudbyder, om den konkrete pakkeversion stadig vedligeholdes. Med de foreliggende OpenSSL-kilder er det ikke muligt at komme med en generel udtalelse om opdaterings- eller backport-procedurer for de enkelte distributioner.

Inden for hovedgrenen 3 forbliver API og ABI uændrede i mindre udgivelser i henhold til versionspolitikken; patch-udgivelser indeholder fejl- og sikkerhedsrettelser. Alligevel er det nødvendigt at teste applikationerne, især i tilfælde af forældede grænseflader, egne udbydere, hardwaremoduler eller medfølgende runtime-miljøer. Containere og statisk linkede applikationer kan desuden anvende et andet bibliotek end værtsystemet.

Målet er derfor ikke at opnå en så høj versionsstreng som muligt, men derimod en version af hver enkelt komponent, der faktisk anvendes, og som det kan dokumenteres, at den understøttes og kan opdateres. En selvbygget løsning baseret på upstream-kilder øger ansvaret: Opdateringer, biblioteks- og udbyderstier, links samt kompatibilitetstests skal derefter kontrolleres af operatøren.

TLS er ikke datamedie-kryptering

TLS beskytter data under overførslen mellem definerede endepunkter. Når man åbner en hjemmeside, gælder det f.eks. forbindelsen fra browseren til webserveren; ved SMTP kan det sikre overførslen mellem mailservere eller hentningen af en mailboks. OpenSSL stiller kryptografiske komponenter til rådighed for applikationer til dette formål, men den konkrete anvendelse af TLS styres af den pågældende tjeneste.

Også interne forbindelser kræver den samme adskillelse. Et program kan bruge TLS til at forbinde til en database, en reverse proxy til backend-systemet eller en mailserver til et relæ. Her er certifikatvalidering, kontrol af værtsnavne og administration af pålidelige certifikater lige så vigtige som ved offentligt tilgængelige tjenester. Kryptering på netværksvejen beskytter dog ikke automatisk data, der behandles eller gemmes på slutpunktet.

Kryptering af data i hvile hører til et andet lag. Kryptering i Linux kan f.eks. omfatte LUKS-krypterede diskenheder; databaser kan anvende egne krypteringsfunktioner, og sikkerhedskopier kræver en særskilt procedure. Disse foranstaltninger afgør, hvad der er beskyttet i tilfælde af tab af et datamedie, uautoriseret adgang til sikkerhedskopifiler eller adgang til lagrede data. En OpenSSL-opgradering konfigurerer ikke automatisk nogen af disse niveauer.

En robust krypteringsstrategi kombinerer derfor beskyttelse under overførsel og lagring, uden at sætte dem på lige fod. For TLS kræves der gyldige certifikater, beskyttede private nøgler og en protokolpolitik, der passer til tjenesten. For lagrede data kommer derudover nøgleadministration, adgangsrettigheder, gendannelsesprocedurer og beskyttelse af sikkerhedskopier. Hvis nøgler opbevares ubeskyttet ved siden af krypterede sikkerhedskopier, forbliver den praktiske beskyttelse begrænset.

Det rigtige spørgsmål er derfor for hver datastrøm: Hvor opstår dataene, hvilken rute følger de, hvor opbevares de permanent, og hvem kan bruge de tilhørende nøgler? OpenSSL kan indgå i TLS og andre kryptografiske operationer. Det er dog hverken en erstatning for volumenkryptering, en komplet nøgleadministration eller en garanti for sikre sikkerhedskopier.

Forstå udbydermodellen og sikkerhedsniveauerne

Med OpenSSL 3 implementeres kryptografiske funktioner via Udbyder stillet til rådighed og udvalgt efter egenskaber. Dette adskiller spørgsmålet om, hvilken algoritme der er behov for, fra den konkrete implementering. Dette er relevant for hostingsystemer, fordi applikationen, bibliotekskonteksten og OpenSSL-konfigurationen tilsammen bestemmer, hvilke metoder der er tilgængelige og kan vælges.

Legacy-udbyderen indlæses ikke automatisk. Hvis et ældre program har brug for en algoritme, der udelukkende er tilgængelig der, kan det pågældende opkald mislykkes efter opgraderingen. Som en midlertidig undtagelse skal aktiveringen begrænses til den berørte tjeneste, dokumenteres og knyttes til en frist for udfasning.

Hvis udbydere udtrykkeligt aktiveres, er standardudbyderen ikke længere automatisk tilgængelig. Den skal indlæses separat, hvis applikationen har brug for dens implementeringer. Det faktum, at Legacy-udbyderen indlæses, betyder dog ikke, at en netværkstjeneste automatisk anvender Legacy-procedurer; det afgørende er de anmodede algoritmer, egenskabsforespørgsler og den pågældende bibliotekskontekst.

FIPS-udbyderen er ikke et generelt sikkerhedsmærke. Egenskaber som fips=yes De er retningsgivende for valget af egnede implementeringer, men er ikke i sig selv tilstrækkeligt til at sikre overholdelse af reglerne. Det afgørende er et konkret valideret modul og dets sikkerhedspolitik. På OpenSSL’s downloadside angives OpenSSL 3.1.2 på tidspunktet for denne undersøgelse som den FIPS 140-3-validerede version.

Die Sikkerhedsniveau er adskilt fra dette. Den påvirker ikke blot krypteringssuiter, men også signaturer, nøglestørrelser og parametre. En global indstilling som @SECLEVEL=2 kan derfor udelukke certifikater eller modparter. Test en ændring med de berørte tjenester og klienter, i stedet for blot at konkludere, at en kortere krypteringsliste giver højere sikkerhed.

Konfigurer TLS-politik pr. tjeneste

OpenSSL leverer regler og kryptografiske funktioner, men den effektive TLS-politik gennemføres af hver enkelt tjeneste i dens egen konfiguration. Dette gælder både for offentlige webtjenester, reverse proxyer og e-mailtjenester og omfatter blandt andet minimumsprotokoller, certifikater, nøgler og håndteringen af forskellige modparter. For interne forbindelser, f.eks. mellem proxy, applikation og database, gælder de samme grundlæggende spørgsmål, dog ofte med en klientbase, der er lettere at kontrollere.

Først og fremmest bør en tjeneste kun tillade de protokolversioner, som dens tilsigtede modparter understøtter. Derefter følger en komplet certifikatkæde og en nøgletype, der passer til anvendelsen. Disse beslutninger kan ikke med fordel behandles som en enkelt global OpenSSL-indstilling: En offentlig webserver, SMTP-transport og et internt drevet database-backend har forskellige kompatibilitets- og tillidsgrænser.

Ved konfiguration af krypteringsalgoritmer er protokolgrænsen afgørende. Krypteringsstrenge fra OpenSSL styrer TLS 1.2 og ældre TLS-versioner; TLS 1.3-krypteringssuiter konfigureres separat. Valget af krypteringsmetoder afslører desuden ikke, hvilken TLS-protokolversion en server forhandler sig frem til. Hvis man blot ændrer en liste over krypteringsmetoder, har man derfor hverken automatisk deaktiveret gamle protokoller eller fuldt ud udnyttet TLS 1.3.

Udgivelsen af openssl ciphers er ikke et bevis på den aktive serverpolitik. Den beskriver blot, hvad det anvendte CLI-bibliotek generelt kender til blandt sine parametre; certifikat, DH-parametre og tjenestekonfiguration kan yderligere begrænse de suiter, der reelt kan forhandles. Først en test mod den konkrete tjeneste med det forudbestemte servernavn, certifikat og klientprofil er pålidelig.

For e-mail-tjenester bør en nødvendig undtagelse ikke svække sikkerhedspolitikken for alle virtuelle værter eller alle udgående forbindelser. Det er bedre at indføre en dokumenteret, tidsbegrænset undtagelse for den kendte modpart, kombineret med en migrationsopgave til dennes operatør. TLS-ændringer i højtilgængelige proxy- og sessionsarkitekturer kræver desuden en planlagt overgang og en dokumenteret fallback-løsning. Hvis platformen bruger Redis til sessioner eller køer, bør også Redis-failover-strategier til produktive hostingsystemer skal der tages højde for, så en TLS-relateret genstart ikke forværres af en uforberedt skift til backend.

Kontrolleret forberedelse og kontrol af migrationen

En kontrolleret migration begynder med en Inventar. Registrer web-, e-mail-, proxy-, database- og applikationsprocesser samt TLS-modparter og særlige kryptografiske afhængigheder. Skel mellem operativsystemets pakke og biblioteker, der følger med containere, hostingpaneler eller medfølgende runtime-miljøer.

Implementer først ændringen i et testmiljø med realistiske certifikatkæder, navne og klientprofiler. Pakkestatus, konfiguration, udbyderfiler og genstartsrækkefølge skal være fastlagt inden vedligeholdelsesvinduet. Vær især opmærksom på eksterne e-mail-partnere, ældre apparater og interne tjenester, hvis certifikater eller protokoller ikke administreres centralt.

Følgende diagnosekommando ændrer ikke serverkonfigurationen og må kun udføres på et godkendt testdomæne. Den aktiverer SNI og værtsnavnsvalidering; -verify_return_error afbryder opkaldet ved en valideringsfejl i stedet for at fortsætte forbindelsen bagefter.

openssl s_client -connect <hostname>:443 -servername <hostname> -verify_hostname <hostname> -verify_return_error -brief

Funktionen kontrollerer en konkret TLS-forhandling for det angivne værtsnavn. Den erstatter ikke test af andre porte, virtuelle værter, interne forbindelser eller klientklasser. For at sikre en pålidelig godkendelse skal alle relevante tjenesteforbindelser derfor testes med repræsentative modparter.

Efter overgangen skal du holde øje med servicelogfiler, certifikatfejl og mislykkede handshakes. Inddel først nedbrud efter, om de skyldes certifikatet, protokollen, valg af krypteringsalgoritme eller applikationsafhængighed. En generel sænkning af sikkerhedsniveauet eller permanent aktivering af Legacy Provider kan skjule årsagen og er ikke en passende standard-fallback-løsning.

Målrettet analyse af kompatibilitetsproblemer

Efter en OpenSSL-opgradering viser et kompatibilitetsproblem sig ofte først, når der oprettes forbindelse: En browser, en e-mail-partner eller en intern klient får en TLS-fejl, selvom tjenesten selv er startet. Du bør derfor ikke straks ændre krypteringslister eller sikkerhedsniveauer. Inddel først fejlen i et af fire niveauer: certifikat, protokol, krypteringsforhandling eller applikation. Det begrænser undtagelserne til den egentlige årsag.

Når det gælder certifikater, er det især vigtigt at bemærke, at SHA-1-signerede leaf-certifikater ikke accepteres fra sikkerhedsniveau 1 og opefter. Også for små nøgleparametre eller en ufuldstændig certifikatkæde kan forhindre håndtrykket. Kontroller derfor det faktisk leverede certifikat, herunder kæden og signaturalgoritmen, i stedet for blot at se på den certifikatfil, der er gemt på serveren.

Hvis forbindelsen til en gammel modpart mislykkes, kan årsagen være dennes maksimale protokolversion. OpenSSL 3 betragter ikke længere SSL 3.0, TLS 1.0, TLS 1.1 og DTLS 1.0 som brugbare ved det forudindstillede sikkerhedsniveau 1. En fejl af denne art kræver en beslutning om udskiftning, opdatering eller en meget begrænset overgangskompatibilitet – ikke automatisk en generel sænkning af sikkerhedskravene.

Hvis der mangler et digest eller en krypteringsmetode, er årsagen ofte en forventet Legacy-algoritme. Legacy-udbyderen indlæses ikke automatisk og indeholder procedurer, der ikke længere er almindeligt anvendte eller er klassificeret som usikre. En midlertidig aktivering heraf kan sikre, at en ældre applikation forbliver tilgængelig i forbindelse med en dokumenteret migrering; det er dog ikke en fast sikkerhedsforanstaltning og skal have en udløbsdato.

Når det drejer sig om egenudviklet eller proprietær software, skal du desuden kontrollere dens kryptografiske integration. ENGINE’er samt adskillige lavniveau-kald til RSA, EC og andre algoritmer betragtes som forældede i OpenSSL 3; applikationer bør migreres til abstrakte EVP-grænseflader. Dette er vigtigere end at skjule en fejlmeddelelse ved hjælp af udbyderkonfiguration, da gamle opkald kan omgå det ønskede valg af udbyder.

En Udbyderkonfiguration skal være fuldstændig. Så snart en konfiguration udtrykkeligt aktiverer andre udbydere, indlæses standardudbyderen ikke længere automatisk. Hvis der f.eks. kun konfigureres »Legacy«, kan moderne standardimplementeringer mangle, og en tjeneste kan uventet gå ned. Indlæs derfor de nødvendige udbydere bevidst, test den konkrete tjenesteproces efter en genstart, og fjern overgangsregler, så snart den afhængige komponent er opdateret.

Korrekt vurdering af FIPS og særlige tilfælde

Der FIPS-udbyder er er kun en meningsfuld komponent i hostingsystemer, hvis et konkret kontraktmæssigt, myndighedsmæssigt eller internt krav forudsætter FIPS-valideret kryptografi. Det er ikke et generelt kvalitetsstempel for TLS-sikkerhed. OpenSSL tilbyder et FIPS-udbyderkoncept; implementeringer kan via egenskaber som fips=yes vælges. Det i sig selv gør dog hverken en installation eller OpenSSL-3.5-grenen til et valideret FIPS-modul.

For at sikre en pålidelig compliance-vurdering skal du kontrollere krav og teknik hver for sig: ordlyden af kravet, den konkret validerede modulversion inklusive certifikat og sikkerhedspolitik, den foreskrevne build- og installationsproces, distributionspakken samt understøttelsen fra hver enkelt berørt tjeneste. Den 19. oktober 2026 angiver OpenSSL-downloadssiden OpenSSL 3.1.2 som en FIPS 140-3-valideret version og kræver, at man følger anvisningerne i den tilhørende sikkerhedspolitik vedrørende download, kompilering og installation.

Selv når et valideret modul anvendes korrekt, afhænger overholdelsen af den faktiske drift. Dokumentationen påpeger, at med fips=yes hente algoritmer kan under visse omstændigheder alligevel ikke betragtes som godkendte. Anvendelsen, egenskabsforespørgsler, de anvendte algoritmer og den konkrete forbindelsesvej skal derfor stemme overens med specifikationerne; det er ikke tilstrækkeligt blot at indlæse en udbyder eller et konfigurationsfragment.

Man skal være særlig forsigtig med en global aktivering. En webserver kan nemlig starte, mens en e-mail-tjeneste, en agent eller et program fejler, når den forsøger at få adgang til en algoritme, der ligger uden for FIPS-udbyderen. Derudover indlæser ikke alle applikationer nødvendigvis den samme OpenSSL-konfiguration. Test derfor tilstanden for hver tjeneste og for hver faktisk forbindelsesvej i et passende testmiljø, inden du implementerer den som standard i produktionsmiljøet.

Almindelig TLS-hærdning Dette skal holdes adskilt: understøttede bibliotekspakker, opdaterede certifikater, passende minimumsprotokoller og en tjenestespecifik TLS-politik er også nødvendige uden FIPS. Omvendt erstatter en FIPS-tilstand hverken certifikatstyring eller patch-styring. Planlæg det derfor som et selvstændigt compliance-projekt med ansvarsfordeling, dokumentation og genopretningsprocedurer – ikke som en knap, der giver en generelt mere sikker installation.

Fastlægge driftsmodel for OpenSSL

Das Driftsmodel fastlægger, hvem der overvåger opdateringer, og hvilket bibliotek en tjeneste rent faktisk bruger. Når det drejer sig om en distributionspakke, kontrollerer du den konkrete pakkeversion ved hjælp af udbyderens officielle oplysninger om sikkerhed, pakker og livscyklus. De tilgængelige OpenSSL-kilder dokumenterer ikke, hvordan en bestemt Linux-distribution leverer rettelser, eller hvor længe den vedligeholder en pakke.

En overgang til OpenSSL 3.5 LTS Det er hensigtsmæssigt, hvis der er behov for en defineret upstream-gren, og operatøren har ansvaret for vedligeholdelsen heraf. OpenSSL understøtter version 3.5 indtil den 8. april 2030. Om en distributionspakke eller en egen upstream-version passer bedre, afhænger derimod af de dokumenterede ansvarsområder og systemkrav.

Containere kan indeholde en anden libcrypto-version end værtsystemet; en opdatering af værtsystemet ændrer ikke nødvendigvis denne kørselstid. Ved selvbygning kommer der udbyderstier, tjenesteenheder og dynamiske links til. API- og ABI-garantierne inden for hovedgrenen erstatter ikke test af applikationer, forældede ENGINE-tilkoblinger eller eksterne kryptografikomponenter.

Inden beslutningen træffes, skal alle processer med eksterne og interne TLS-forbindelser kortlægges. De skal opdateres til en understøttet version via den respektive udbyder, og de faktiske serviceforløb skal testes i et testmiljø. Uundgåelige undtagelser begrænses til den pågældende tjeneste og dokumenteres med angivelse af risiko, ansvarlig person og udløbsdato.

Overvåg ikke blot TLS-fejl, men også processtatus, svartider og hukommelsesforbrug under produktive ændringer. Genstarter og fejlbehæftede genopkoblinger kan medføre midlertidige belastningsspidser. Artiklen om Hukommelsespres i Linux-kernen hjælper med at skelne mellem kryptografiske fejl og samtidig ressourcebelastning.