OpenSSL 3.x: beveiligingsverbeteringen voor hostingsystemen

OpenSSL 3.x in de hostingomgeving integreren

OpenSSL is een bibliotheek voor cryptografische functies en TLS. Het biedt applicaties onder andere methoden voor versleuteling, handtekeningen, certificaatcontrole en het tot stand brengen van beveiligde verbindingen. Een upgrade naar OpenSSL 3.x verbetert daarom in eerste instantie de cryptografische basis van een hostingsysteem, en niet automatisch elke instelling van de diensten die daarop draaien.

Of een webserver, mailserver, reverse proxy of databaseservice daadwerkelijk TLS gebruikt en welke regels daarbij gelden, wordt bepaald door de eigen configuratie ervan. NGINX, Apache, HAProxy, Postfix, Dovecot of een databaseclient kiezen bijvoorbeeld protocolversies, certificaten, sleutels en toegestane methoden. De geïnstalleerde bibliotheek biedt hiervoor functies; deze vormt geen vervanging voor een zorgvuldig opgesteld TLS-beleid van de afzonderlijke dienst.

De verbetering van de beveiliging is vooral te danken aan een ondersteunde bibliotheekversie, gemoderniseerde programmeerinterfaces en een duidelijkere afbakening van verouderde cryptografie. Dit vermindert het risico dat applicaties onbedoeld verouderde mechanismen blijven gebruiken. Beveiligingsupdates moeten niettemin tijdig worden geïnstalleerd, en certificaatketens, privésleutels en toegangsrechten blijven afzonderlijke beheertaken.

In de praktijk geldt dit zowel voor openbare als voor interne verbindingen. Bij een website beveiligt TLS de verbinding tussen de browser en de reverse proxy; op de achtergrond kunnen er nog andere TLS-verbindingen bestaan, bijvoorbeeld van de proxy naar de applicatieserver of van de applicatie naar de database. Elk traject heeft zijn eigen tegenpartijen en compatibiliteitseisen. Een moderne bibliotheek vormt hiervoor een belangrijke basis, maar is geen garantie dat alle verbindingen consistent beveiligd zijn.

Toepassingen met een eigen cryptografische integratie vereisen bijzondere aandacht. OpenSSL 3 gebruikt Provider en geeft de voorkeur aan abstracte EVP-interfaces, terwijl talrijke oudere low-level API’s en ENGINE-mechanismen als verouderd worden beschouwd. Bij een upgrade kan daarom niet alleen een serviceconfiguratie, maar ook een plug-in, een taalbinding of een eigen uitbreiding van belang zijn.

De juiste ondersteunde 3.x-takken kiezen

De uitspraak „updaten naar OpenSSL 3“ is te vaag voor de bedrijfsplanning. Op 19 oktober 2026 vermeldt de officiële downloadpagina alleen nog 3.4, 3.5 en 3.6 als regulier beschikbare 3.x-takken. Versies die niet in de lijst staan, krijgen geen openbare upstream-ondersteuning en mogen volgens OpenSSL niet meer in productieomgevingen worden gebruikt. OpenSSL 3.0 en 3.3 vormen daarom geen geschikte upstream-basis voor nieuwe productieplannen.

Voor nieuwe ontwerpen binnen de 3.x-serie geldt dat OpenSSL 3.5 LTS de relevante tak. De ondersteuning hiervoor loopt tot 8 april 2030. OpenSSL 3.4 bereikt het einde van de ondersteuning al op 22 oktober 2026, OpenSSL 3.6 als niet-LTS-tak op 1 november 2026. Wie zelf upstream-pakketten beheert, moet daarom rekening houden met de specifieke tak en de bijbehorende einddatum.

Bij pakketten van een Linux-distributie mag de upstream-versiestring niet op zichzelf worden beoordeeld. Controleer in plaats daarvan in de officiële pakket-, beveiligings- en levenscyclusinformatie van de betreffende distributieaanbieder of de specifieke pakketversie nog wordt onderhouden. Met de beschikbare OpenSSL-bronnen kan geen algemene uitspraak worden gedaan over update- of backport-procedures van afzonderlijke distributies.

Binnen hoofdtak 3 blijven de API en ABI volgens het versiebeleid behouden bij minor-releases; patch-releases bevatten fout- en beveiligingscorrecties. Toch zijn applicatietests noodzakelijk, met name bij verouderde interfaces, eigen providers, hardwaremodules of gebundelde runtime-omgevingen. Containers en statisch gelinkte applicaties kunnen bovendien een andere bibliotheek gebruiken dan het hostsysteem.

Het doel is daarom niet om een zo hoog mogelijke versienummerreeks te hebben, maar om voor elke daadwerkelijk gebruikte component een aantoonbaar ondersteunde en bij te werken versie te hebben. Een zelfgebouwde oplossing op basis van upstream-bronnen brengt meer verantwoordelijkheid met zich mee: updates, bibliotheek- en providerpaden, koppelingen en compatibiliteitstests moeten dan door de beheerder worden gecontroleerd.

TLS is geen versleuteling van gegevensdragers

TLS beschermt gegevens tijdens de overdracht tussen gedefinieerde eindpunten. Bij het bezoeken van een website betreft dit bijvoorbeeld de verbinding tussen de browser en de webserver; bij SMTP kan het de overdracht tussen mailservers of het ophalen van een mailbox beveiligen. OpenSSL stelt hiervoor cryptografische bouwstenen ter beschikking aan applicaties, maar het concrete gebruik van TLS wordt bepaald door de betreffende dienst.

Ook interne verbindingen verdienen dezelfde scheiding. Een applicatie kan TLS gebruiken om verbinding te maken met de database, een reverse proxy met de backend of een mailserver met een relay. Daar zijn certificaatcontrole, hostnaamcontrole en het beheer van betrouwbare certificaten net zo belangrijk als bij openbaar toegankelijke diensten. Versleuteling via het netwerk beschermt echter niet automatisch gegevens die op het eindpunt worden verwerkt of opgeslagen.

De versleuteling van gegevens in rust behoort tot een andere laag. Versleuteling in Linux kan bijvoorbeeld LUKS-versleutelde volumes omvatten; databases kunnen hun eigen versleutelingsfuncties gebruiken en back-ups vereisen een eigen procedure. Deze maatregelen bepalen wat beschermd is bij verlies van een gegevensdrager, ongeoorloofde toegang tot back-upbestanden of toegang tot opgeslagen gegevens. Een OpenSSL-upgrade configureert geen van deze niveaus automatisch.

Een robuuste versleutelingsstrategie combineert daarom bescherming tijdens verzending en opslag, zonder deze twee op één lijn te stellen. Voor TLS zijn geldige certificaten, beveiligde privésleutels en een protocolbeleid dat bij de dienst past vereist. Voor opgeslagen gegevens komen daar nog sleutelbeheer, toegangsrechten, herstelprocedures en de beveiliging van back-ups bij. Als sleutels naast versleutelde back-ups onbeveiligd worden opgeslagen, blijft de praktische beveiliging beperkt.

De juiste controlevraag luidt daarom voor elke gegevensstroom: waar ontstaan de gegevens, welke route volgen ze, waar worden ze permanent opgeslagen en wie kan de bijbehorende sleutels gebruiken? OpenSSL kan een rol spelen bij TLS en andere cryptografische bewerkingen. Het is echter geen vervanging voor volumecodering, noch een volledig sleutelbeheer, noch een garantie voor veilige back-ups.

Het providermodel en de beveiligingsniveaus begrijpen

Met OpenSSL 3 worden cryptografische implementaties via Aanbieder ter beschikking gesteld en op basis van eigenschappen geselecteerd. Hierdoor wordt de vraag welk algoritme nodig is, losgekoppeld van de concrete implementatie. Voor hostingsystemen is dit relevant, omdat de toepassing, de bibliotheekcontext en de OpenSSL-configuratie samen bepalen welke methoden beschikbaar en selecteerbaar zijn.

De legacy-provider wordt niet automatisch geladen. Als een oude toepassing een algoritme nodig heeft dat uitsluitend daar beschikbaar is, kan de betreffende aanroep na de upgrade mislukken. Als tijdelijke uitzondering moet de activering ervan beperkt blijven tot de betreffende dienst, gedocumenteerd worden en gekoppeld zijn aan een datum waarop deze wordt vervangen.

Als providers expliciet worden geactiveerd, is de standaardprovider niet langer automatisch beschikbaar. Deze moet apart worden geladen wanneer de toepassing de implementaties ervan nodig heeft. Het louter laden van de legacy-provider betekent echter niet dat een netwerkdienst automatisch legacy-procedures gebruikt; bepalend zijn de aangevraagde algoritmen, eigenschapsquery's en de betreffende bibliotheekcontext.

De FIPS-provider is geen algemeen beveiligingslabel. Kenmerken zoals fips=yes zijn bepalend voor de keuze van geschikte implementaties, maar vormen op zichzelf geen garantie voor naleving. Doorslaggevend zijn een concreet gevalideerde module en het bijbehorende beveiligingsbeleid. Op het moment van onderzoek vermeldt de OpenSSL-downloadpagina OpenSSL 3.1.2 als de FIPS 140-3-gevalideerde versie.

De Beveiligingsniveau staat daarvan los. Het beïnvloedt niet alleen cipher suites, maar ook handtekeningen, sleutelgroottes en parameters. Een globale instelling zoals @SECLEVEL=2 kan daarom certificaten of tegenpartijen uitsluiten. Test een wijziging met de betrokken diensten en clients, in plaats van alleen op basis van een kortere lijst met versleutelingsalgoritmen te concluderen dat de beveiliging hoger is.

TLS-beleid per dienst configureren

OpenSSL biedt regels en cryptografische functies, maar de effectieve TLS-beleid wordt door elke dienst in zijn eigen configuratie geïmplementeerd. Dit geldt zowel voor openbare webservices als voor reverse proxies en e-maildiensten en heeft onder andere betrekking op minimale protocollen, certificaten, sleutels en de omgang met verschillende tegenpartijen. Voor interne verbindingen, bijvoorbeeld tussen een proxy, een applicatie en een database, gelden dezelfde basisprincipes, maar vaak met een beter beheersbaar klantenbestand.

Allereerst moet een dienst alleen de protocolversies toestaan die door de beoogde tegenpartijen worden ondersteund. Daarna volgen een volledige certificaatketen en een voor de toepassing geschikt sleuteltype. Deze beslissingen kunnen niet zinvol worden behandeld als één enkele globale OpenSSL-instelling: een openbare webserver, SMTP-transport en een intern beheerde database-backend hebben verschillende compatibiliteits- en vertrouwensgrenzen.

Bij cipher-configuraties is de protocolgrens doorslaggevend. Cipher-strings van OpenSSL bepalen TLS 1.2 en oudere TLS-versies; TLS 1.3-cipher-suites worden apart geconfigureerd. Uit de keuze van de ciphers volgt bovendien niet welke TLS-protocolversie een server onderhandelt. Wie alleen een cipher-lijst wijzigt, heeft daarom noch automatisch oude protocollen uitgeschakeld, noch TLS 1.3 volledig benut.

De uitgave van openssl ciphers Dit is geen bewijs van het actieve serverbeleid. Het beschrijft slechts wat de gebruikte CLI-bibliotheek in principe herkent op basis van haar parameters; certificaten, DH-parameters en serviceconfiguratie kunnen de daadwerkelijk onderhandelbare suites verder beperken. Pas een test tegen de concrete dienst met de beoogde servernaam, het certificaat en het clientprofiel is betrouwbaar.

Voor e-maildiensten mag een noodzakelijke uitzondering het beleid voor alle virtuele hosts of alle uitgaande verbindingen niet verzwakken. Het is beter om een gedocumenteerde, tijdelijke uitzondering voor de bekende tegenpartij in te stellen, in combinatie met een migratieopdracht aan de beheerder daarvan. TLS-wijzigingen aan proxy- en sessiearchitecturen met hoge beschikbaarheid vereisen bovendien een geplande omschakeling en een gedocumenteerd noodplan. Als het platform Redis gebruikt voor sessies of wachtrijen, moeten daarbij ook de Redis-failover-strategieën voor productieve hostingsystemen moet hiermee rekening worden gehouden, zodat een door TLS veroorzaakte herstart niet wordt verergerd door een onvoorbereide backend-omschakeling.

Migratie op een gecontroleerde manier voorbereiden en controleren

Een gecontroleerde migratie begint met een Inventaris. Breng web-, e-mail-, proxy-, database- en applicatieprocessen in kaart, evenals TLS-tegenpartijen en specifieke cryptografische afhankelijkheden. Maak onderscheid tussen het pakket van het besturingssysteem en bibliotheken die deel uitmaken van containers, hostingpanelen of gebundelde runtime-omgevingen.

Implementeer de wijziging eerst in een staging-omgeving met realistische certificaatketens, namen en clientprofielen. De pakketstatus, configuratie, providerbestanden en de volgorde van het opnieuw opstarten moeten vóór het onderhoudsvenster vastliggen. Houd vooral rekening met externe e-mailpartners, oudere apparaten en interne diensten waarvan de certificaten of protocollen niet centraal worden beheerd.

De volgende diagnosecommando wijzigt de serverconfiguratie niet en mag alleen worden uitgevoerd op een vrijgegeven testdomein. Het schakelt SNI en hostnaamcontrole in; -verify_return_error beëindigt de aanroep bij een validatiefout, in plaats van de verbinding daarna voort te zetten.

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

De test controleert een specifieke TLS-onderhandeling voor de opgegeven hostnaam. Deze test is geen vervanging voor tests van andere poorten, virtuele hosts, interne verbindingen of clientklassen. Voor een betrouwbare acceptatietest moeten daarom alle relevante verbindingsroutes met representatieve tegenpartijen worden getest.

Controleer na de omschakeling de servicelogboeken, certificaatfouten en mislukte handshakes. Schrijf storingen in eerste instantie toe aan het certificaat, het protocol, de keuze van de versleutelingsmethode of de applicatie. Een algemene verlaging van het beveiligingsniveau of het permanent activeren van de legacy-provider kan de oorzaak verhullen en is geen geschikte standaardoplossing.

Compatibiliteitsproblemen gericht analyseren

Na een OpenSSL-upgrade komt een compatibiliteitsprobleem vaak pas aan het licht bij het tot stand brengen van de verbinding: een browser, e-mailpartner of interne client krijgt een TLS-foutmelding, hoewel de dienst zelf wel is opgestart. Wijzig in dat geval niet meteen de cipher-lijsten of beveiligingsniveaus. Deel de fout eerst in op een van de vier niveaus: certificaat, protocol, cipher-onderhandeling of toepassing. Zo beperk je de uitzonderingen tot de daadwerkelijke oorzaak.

Wat certificaten betreft, is het vooral van belang dat met SHA-1 ondertekende leaf-certificaten vanaf beveiligingsniveau 1 niet worden geaccepteerd. Ook te kleine sleutelparameters of een onvolledige certificaatketen kunnen de handshake verhinderen. Controleer daarom het daadwerkelijk geleverde certificaat, inclusief de keten en het ondertekeningsalgoritme, in plaats van alleen het certificaatbestand te bekijken dat op de server is opgeslagen.

Als de verbinding met een oud eindpunt mislukt, kan de maximale protocolversie daarvan de oorzaak zijn. OpenSSL 3 beschouwt SSL 3.0, TLS 1.0, TLS 1.1 en DTLS 1.0 bij het standaard ingestelde beveiligingsniveau 1 niet langer als bruikbaar. Een dergelijk foutbeeld vereist een beslissing over vervanging, een update of strikt beperkte overgangscompatibiliteit – niet automatisch een algemene verlaging van de beveiligingseisen.

Als er een digest of een versleutelingsmethode ontbreekt, is de oorzaak vaak een verwachte Legacy-algoritme. De Legacy Provider wordt niet automatisch geladen en bevat procedures die niet meer algemeen gangbaar zijn of als onveilig worden beschouwd. Door deze tijdelijk te activeren kan een oude toepassing toegankelijk blijven voor een gedocumenteerde migratie; het is echter geen reguliere beveiligingsmaatregel en er moet een vervaldatum aan worden gekoppeld.

Bij eigen of propriëtaire software controleer je bovendien de cryptografische koppeling ervan. ENGINE’s en talrijke low-level-aanroepen voor RSA, EC en andere algoritmen worden in OpenSSL 3 als verouderd beschouwd; applicaties moeten migreren naar abstracte EVP-interfaces. Dit is belangrijker dan een foutmelding als gevolg van de providerconfiguratie te verdoezelen, omdat oude aanroepen de gewenste providerkeuze kunnen omzeilen.

A Configuratie van de provider moet volledig zijn. Zodra een configuratie andere providers expliciet activeert, wordt de standaardprovider niet meer automatisch geladen. Als bijvoorbeeld alleen Legacy wordt geconfigureerd, kunnen moderne standaardimplementaties ontbreken en kan een dienst onverwacht uitvallen. Laad daarom de benodigde providers bewust, test het betreffende serviceproces na een herstart en verwijder overgangsregels zodra de afhankelijke component is bijgewerkt.

FIPS en speciale gevallen correct beoordelen

De FIPS-provider is voor hostingsystemen alleen een zinvolle bouwsteen als een concrete contractuele, wettelijke of interne eis FIPS-gevalideerde cryptografie vereist. Het is geen algemeen keurmerk voor TLS-beveiliging. OpenSSL biedt een FIPS-providerconcept; implementaties kunnen via eigenschappen zoals fips=yes worden geselecteerd. Dat alleen maakt echter noch de installatie, noch de OpenSSL-3.5-tak tot een gevalideerde FIPS-module.

Voor een degelijke compliance-beoordeling controleer je de vereisten en de techniek afzonderlijk: de tekst van de specificatie, de concreet gevalideerde moduleversie inclusief certificaat en beveiligingsbeleid, het voorgeschreven bouw- en installatieproces, het distributiepakket en de ondersteuning door elke betrokken dienst. Op 19 oktober 2026 vermeldt de OpenSSL-downloadpagina OpenSSL 3.1.2 als een FIPS 140-3-gevalideerde versie en vereist deze dat de instructies van het bijbehorende beveiligingsbeleid voor het downloaden, bouwen en installeren worden opgevolgd.

Zelfs bij een correct geïnstalleerde, gevalideerde module hangt de naleving af van de daadwerkelijke werking. In de documentatie wordt erop gewezen dat met fips=yes onder bepaalde omstandigheden kunnen de gebruikte algoritmen toch niet als toegestaan worden beschouwd. De toepassing, property-query’s, gebruikte algoritmen en de concrete verbindingsroute moeten daarom aan de specificaties voldoen; het louter laden van een provider of een configuratiefragment is niet voldoende.

Wees bijzonder voorzichtig met een globale activering. Een webserver kan vervolgens opstarten, terwijl een e-maildienst, een agent of een toepassing faalt bij het benaderen van een algoritme dat buiten de FIPS-provider valt. Bovendien laadt niet elke toepassing noodzakelijkerwijs dezelfde OpenSSL-configuratie. Test de modus daarom per dienst en per daadwerkelijke verbindingsroute in een geschikte testomgeving, voordat je deze als operationele standaard implementeert.

Gewone TLS-beveiliging Dit staat daar los van: ondersteunde bibliotheekpakketten, actuele certificaten, passende minimumprotocollen en een dienstspecifiek TLS-beleid zijn ook zonder FIPS vereist. Omgekeerd vervangt een FIPS-modus noch het certificaatbeheer, noch het patchbeheer. Plan het daarom als een apart compliance-project met verantwoordelijkheden, bewijsstukken en noodprocedures – niet als een knop voor een algemeen veiligere installatie.

Het bedrijfsmodel voor OpenSSL vaststellen

De Bedrijfsmodel bepaalt wie updates in de gaten houdt en welke bibliotheek een dienst daadwerkelijk gebruikt. Bij een distributiepakket controleer je de exacte status van het pakket aan de hand van de officiële informatie over beveiliging, pakketten en de levenscyclus van de aanbieder. De beschikbare OpenSSL-bronnen geven geen uitsluitsel over hoe een bepaalde Linux-distributie correcties beschikbaar stelt of hoe lang deze een pakket onderhoudt.

Een migratie naar OpenSSL 3.5 LTS Dit is zinvol wanneer er een gedefinieerde upstream-tak nodig is en de beheerder verantwoordelijk is voor het onderhoud daarvan. OpenSSL 3.5 wordt ondersteund tot en met 8 april 2030. Of een distributiepakket of een eigen upstream-versie beter past, hangt daarentegen af van de gedocumenteerde verantwoordelijkheden en vereisten van het systeem.

Containers kunnen een andere libcrypto-versie bevatten dan het hostsysteem; een update van het hostsysteem heeft niet noodzakelijkerwijs invloed op deze runtime. Bij zelfgebouwde systemen komen daar nog providerpaden, service-units en dynamische koppelingen bij. De API- en ABI-garanties binnen de hoofdtak zijn geen vervanging voor tests van applicaties, verouderde ENGINE-koppelingen of externe cryptografische componenten.

Breng, voordat je een beslissing neemt, alle processen met externe en interne TLS-verbindingen in kaart. Werk ze via de betreffende provider bij naar een ondersteunde versie en test de daadwerkelijke werkprocessen in de staging-omgeving. Onvermijdelijke uitzonderingen worden beperkt tot de betreffende dienst en gedocumenteerd met vermelding van het risico, de verantwoordelijke en de einddatum.

Houd tijdens productieve wijzigingen niet alleen TLS-fouten in de gaten, maar ook de processtatus, responstijden en het geheugengebruik. Herstarts en mislukte herverbindingen kunnen tijdelijke piekbelastingen veroorzaken. Het artikel over Geheugendruk in de Linux-kernel helpt om cryptografische fouten te onderscheiden van gelijktijdige druk op de systeembronnen.