TLS-certificaatbeheer in 2026: 7 problemen en hoe ze op te lossen

TLS -certificaatbeheer is het complete proces van het ontdekken, uitgeven, verlengen, bewaken en intrekken van de TLS/SSL-certificaten die de websites, API's en interne services van een organisatie beveiligen. Nu de levensduur van certificaten steeds korter wordt, richting 47 dagen, is dit handmatig niet langer schaalbaar. Geautomatiseerde verlenging, volledig inzicht in de certificaatketen en een duidelijke verantwoordelijkheidsverdeling zorgen ervoor dat dit niet langer als best practice, maar als operationele noodzaak wordt beschouwd.

In april 2025 keurde het CA /Browser Forum wetsvoorstel SC-081v3 goed , een gefaseerde verlaging van de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten van 398 dagen naar slechts 47 dagen. De eerste verlaging is al doorgevoerd: de maximale geldigheidsduur daalde naar 200 dagen op 15 maart 2026, naar 100 dagen op 15 maart 2027 en bereikt 47 dagen op 15 maart 2029. Voor teams die certificaatvernieuwingen nog steeds via spreadsheets, e-mailherinneringen en handmatige tickets afhandelen, is dit geen beleidswijziging van de lange termijn. Het is een operationele crisis die zich in slow motion voltrekt.

Fase	Ingangsdatum	Maximale TLS-geldigheid	Geschat aantal verlengingen per jaar
Vorige basislijn	Tot 14 maart 2026	398 dagen	~1
Fase 1 (huidig)	Maart 15 2026	200 dagen	~2
Fase 2	Maart 15 2027	100 dagen	~4
Fase 3	Maart 15 2029	47 dagen	~8

Bron: CA/Browser Forum-stemming SC-081v3 (goedgekeurd april 2025). De hergebruiksperioden voor domeincontrolevalidatie (DCV) worden parallel verkort en bereiken 10 dagen in maart 2029, waardoor zelfs de validatiegegevens achter elk certificaat bijna continu moeten worden vernieuwd.

Een grote, ongeplande certificaatstoring kan, inclusief systeemstoringen en herstelkosten, in de miljoenen dollars lopen. Verlopen en slecht beheerde certificaten behoren tot de meest voorkomende oorzaken van serviceonderbrekingen die voorkomen kunnen worden, en zijn met de juiste processen en tools ook het gemakkelijkst te verhelpen.

Deze blog behandelt de zeven meest voorkomende problemen die verantwoordelijk zijn voor certificaatfouten in de praktijk bij bedrijven, met specifieke richtlijnen voor het oplossen van elk probleem voordat de termijn van 47 dagen de standaard wordt.

1. Weet je hoeveel certificaten je hebt?

De meeste organisaties onderschatten de omvang van hun TLS-certificaatbeheer bij de eerste inventarisatie, vaak met een derde of meer. Dit patroon is herhaaldelijk waargenomen bij de Public Key Infrastructure (PKI) van grote organisaties . De certificaten die teams bijhouden in een spreadsheet of een IT Service Management (ITSM)-ticket geven zelden een volledig beeld.

Certificaten bevinden zich op webservers, loadbalancers, API-gateways, interne microservices, IoT-endpoints en ontwikkelomgevingen die worden opgezet en vervolgens vergeten. Elk certificaat heeft een andere verlengingsinstantie en een andere faalmodus.

De oplossing is het combineren van actieve netwerkscans met integratie in uw CA-uitgiftelogboeken. CA's registreren elk certificaat dat ze uitgeven. Door die lijst te vergelijken met wat uw scanners vinden, worden schaduwcertificaten blootgelegd die buiten het formele proces zijn uitgegeven en niet in een registratiesysteem zijn opgenomen.

Schaduwcertificaten verlopen onevenredig vaak zonder waarschuwing, juist omdat er geen team is dat ze in de gaten houdt. Het dichten van deze lacune in het certificaatbeheer is de voorwaarde voor elke andere verbetering in het beheer van TLS-certificaten.

2. Vernieuwt u certificaten nog steeds handmatig?

Een certificaat met een geldigheidsduur van 398 dagen gaf vernieuwingsteams ongeveer 13 maanden de tijd. Een certificaat met een geldigheidsduur van 47 dagen laat ongeveer 33 bruikbare dagen over, na een buffer van twee weken voor vernieuwing en herstel. Op bedrijfsniveau, waar duizenden certificaten volgens een doorlopend schema worden vernieuwd, leidt handmatige vernieuwing statistisch gezien gegarandeerd tot storingen.

Het ACME- protocol (Automated Certificate Management Environment) elimineert menselijke tussenkomst volledig uit de vernieuwingscyclus. Een client die op het doelsysteem draait, genereert een nieuw Certificate Signing Request ( CSR ), voltooit de domeinvalidatie bij de CA en installeert het uitgegeven certificaat, allemaal zonder ticket of e-mailconversatie.

Interne PKI-omgevingen vereisen hetzelfde automatiseringsmodel, doorgaans via een Enterprise PKI Services-laag die ACME- of EST- eindpunten (Enrollment over Secure Transport) beschikbaar stelt aan interne certificaatgebruikers. De maximale geldigheidsduur van 47 dagen, vastgesteld door het CA/Browser Forum, geldt alleen voor publiekelijk vertrouwde TLS-certificaten; organisaties die een private PKI beheren, kunnen langere geldigheidsperioden aanhouden, zelfs als ze dezelfde automatiseringsprincipes toepassen.

Automatisering zorgt ook voor consistentie in profielen. Bij elke verlenging kan een gevalideerd certificaatsjabloon worden toegepast, waardoor wordt voorkomen dat verouderde algoritmen en verkeerd geconfigureerde alternatieve onderwerpnamen zich ophopen in de gehele organisatie.

3. Houdt u de volledige certificaatvertrouwensketen in de gaten?

Elk TLS-certificaat dat door een server wordt aangeboden, is gekoppeld aan een tussenliggend certificaat, dat op zijn beurt is gekoppeld aan een rootcertificaat dat door browsers en besturingssystemen wordt vertrouwd. Het vernieuwen van het bladcertificaat vernieuwt het tussenliggende certificaat niet.

Tussenliggende certificaten hebben doorgaans een geldigheidsduur van twee tot vijf jaar. Wanneer een certificaat verloopt, worden alle onderliggende certificaten tegelijkertijd als onbetrouwbaar beschouwd, ongeacht hoe recent deze certificaten zijn vernieuwd. Dit is een van de meest voorkomende oorzaken van grootschalige storingen die meerdere diensten treffen.

Het monitoren van de geldigheid van tussenliggende certificaten komt in de praktijk veel minder vaak voor dan het monitoren van alleen de eindcertificaten. Effectief TLS-certificaatbeheer volgt de volledige certificaatketen , waarbij waarschuwingen worden geactiveerd na 90 dagen voor elk tussenliggend of rootcertificaat in een actief vertrouwenspad.

4. Worden privésleutels op hardwareniveau beschermd?

Een vernieuwd certificaat biedt geen beveiligingsvoordeel als de privésleutel die ermee wordt geverifieerd, is gecompromitteerd. HSM- apparaten (Hardware Security Module) genereren en bewaren privésleutels in fraudebestendige hardware, waardoor het extraheren van sleutels bestand is tegen aanvallen op softwareniveau.

Voor gereguleerde omgevingen is de basisvereiste voor de aanschaf een HSM die is gevalideerd volgens FIPS 140-3 Niveau 3 , wat authenticatie op basis van identiteit afdwingt en sleutelmateriaal wist bij detectie van manipulatie. Deze periode van naleving loopt echter ten einde: op 21 september 2026 verplaatst het Cryptographic Module Validation Program (CMVP) van NIST alle FIPS 140-2-certificaten naar de historische lijst, waarna alleen FIPS 140-3-modules in aanmerking komen voor nieuwe federale aanbestedingen in de VS.

In een volwaardige TLS-certificaatbeheerarchitectuur verlaat de privésleutel voor elk waardevol certificaat de HSM nooit. Ondertekeningshandelingen vinden plaats binnen het apparaat en het sleutelmateriaal wordt nooit blootgesteld aan de applicatielaag.

Een aanzienlijk deel van de certificaatincidenten vindt zijn oorsprong in omgevingen van leveranciers waar HSM-vereisten niet contractueel worden afgedwongen. Organisaties zouden de belangrijkste beveiligingsnormen moeten uitbreiden naar elke derde partij die namens hen certificaten beheert.

Naarmate de industrie overstapt op post-kwantumcryptografie , voorkomt de keuze voor HSM's met updatebare algoritmefirmware een hardware-vernieuwingscyclus wanneer nieuwe standaarden worden vastgesteld.

5. Heeft elk certificaat een genoemde eigenaar?

Het meest schadelijke patroon in het beheer van TLS-certificaten is niet een tekort aan tools, maar een gebrek aan verantwoordelijkheid. Wanneer er geen team is aangewezen om de verlenging van een certificaat voor een specifiek systeem te verzorgen, wordt de verlenging ofwel volledig overgeslagen, ofwel gedupliceerd door twee teams die niet van elkaars bestaan ​​afweten.

Onderzoek naar operationele risico's toont consequent aan dat processen die niet onder controle zijn, tot de sterkste voorspellers van terugkerende incidenten behoren. Certificaatbeheer bevindt zich op het snijvlak van beveiliging, netwerken en applicatieteams. Alle drie kunnen ervan uitgaan dat een van de anderen verantwoordelijk is, en niemand onderneemt actie totdat een storing het tegendeel bewijst.

De oplossing is om aan elk certificaat in de inventaris een benoemde eigenaar en een benoemde back-up toe te wijzen. Deze gegevens worden vastgelegd in het certificaatbeheersysteem in plaats van in iemands geheugen of een gedeelde inbox. Vernieuwingsworkflows worden automatisch naar die eigenaar doorgestuurd met vooraf ingestelde doorlooptijden.

Het verschil tussen de testomgeving en de productieomgeving is een gerelateerd probleem. Een certificaat dat in een testomgeving is vernieuwd, wordt niet automatisch in de productieomgeving vernieuwd. Tools voor certificaatbeheer zouden deze certificaten als onafhankelijke, bijgehouden assets moeten behandelen, en niet als hetzelfde certificaat in verschillende contexten.

6. Zijn de certificaatprofielen consistent binnen het hele landgoed?

Wanneer individuele teams de certificaatconfiguratie onafhankelijk van elkaar beheren, ontstaat er een heterogene structuur die duur wordt om te beheren. Sommige certificaten gebruiken RSA-2048, andere RSA-4096, weer andere ECDSA. Sommige hebben één SAN, andere tientallen. Sommige worden uitgegeven door interne CA's, andere door externe CA's met verschillende validatievereisten.

Deze inconsistentie is geen oppervlakkig probleem. Het verhoogt direct de kosten van cryptografische migraties . Wanneer een verouderd algoritme moet worden vervangen voor duizenden certificaten, kunnen organisaties met afgedwongen profielen die migratie binnen enkele dagen uitvoeren. Organisaties zonder dergelijke profielen hebben daar maanden voor nodig.

De workflows voor certificaatuitgifte vormen een steeds vaker misbruikt aanvalspunt: ongeautoriseerde certificaatuitgifte kan net zo schadelijk zijn als het volledig compromitteren van een privésleutel. Door profielen af ​​te dwingen tijdens de uitgifte via een beleidsengine wordt het aanvalsoppervlak in het aanvraagproces verkleind.

CertSecure Manager van Encryption Consulting valideert de sleutelgrootte, het handtekeningalgoritme, de SAN-configuratie en de geldigheidsperiode voordat een verzoek de CA bereikt. Deze beleidslaag zorgt ervoor dat TLS-certificaatbeheer op grote schaal coherent in plaats van chaotisch verloopt.

7. Is uw organisatie voorbereid op de transitie na het kwantumtijdperk?

Certificaten die vandaag met RSA-2048 worden uitgegeven, vallen mogelijk binnen de geldigheidsperiode van een functionerende kwantumcomputer die in staat is die sleutel te kraken. De overgang naar cryptografie na het kwantumtijdperk is geen probleem voor 2035. Het is een probleem voor elk certificaat dat nu wordt uitgegeven en dat over drie tot vijf jaar nog steeds betrouwbaar zal zijn. NIST IR 8547 (concept) keurt RSA-2048 en andere 112-bits beveiligingsalgoritmen af ​​voor nieuwe federale systemen na 2030 en verbiedt alle kwantumkwetsbare publieke-sleutelalgoritmen na 2035.

NIST heeft op 13 augustus 2024 de eerste post-kwantumcryptografiestandaarden afgerond: FIPS 203 (ML-KEM, voor sleutelinkapseling, afgeleid van CRYSTALS-Kyber), FIPS 204 (ML-DSA, voor digitale handtekeningen, afgeleid van CRYSTALS-Dilithium) en FIPS 205 (SLH-DSA, een stateless hash-gebaseerd handtekeningschema, afgeleid van SPHINCS+). Een vierde standaard, FIPS 206 (FN-DSA, afgeleid van FALCON), doorloopt momenteel het standaardisatieproces van NIST en de afronding ervan wordt eind 2026 of in 2027 verwacht.

Certificaatuitgiftesystemen moeten deze nieuwe algoritmen uiteindelijk ondersteunen, en de organisaties die snel kunnen overstappen, zijn degenen die crypto-flexibiliteit hebben ingebouwd in hun TLS-certificaatbeheerarchitectuur, wat betekent dat ze algoritmen kunnen wisselen zonder het uitgifteproces opnieuw te hoeven opbouwen.

Organisaties die de Amerikaanse nationale veiligheidssystemen ondersteunen, worden geconfronteerd met een strenger mandaat: de CNSA 2.0- suite van de NSA specificeert ML-KEM-1024 en ML-DSA-87, waarvan de implementatie nu gaande is; categorie-specifieke deadlines voor exclusief gebruik lopen van 2030 voor netwerkapparatuur en firmware-ondertekening tot 2033 voor besturingssystemen en clouddiensten, waarbij de volledige migratie van alle nationale veiligheidssystemen uiterlijk in 2035 vereist is onder NSM-10.

Het selecteren van HSM's met ondersteuning voor bijwerkbare algoritmen, het bijhouden van schone certificaatinventarissen met algoritmetagging en het afdwingen van profielbeleid via een centraal platform zijn de drie voorwaarden voor een beheersbare migratie naar post-kwantumcryptografie.

De encryptielaag die uw gegevens tijdens de overdracht beschermt, is slechts zo sterk als de certificaat- en sleutelbeheerpraktijken die eraan ten grondslag liggen. Organisaties die deze planning uitstellen, zullen onder tijdsdruk gedwongen worden tot een migratie.

Wat er steeds misgaat: patronen in daadwerkelijke implementaties

In bedrijfsomgevingen doen zich steeds dezelfde faalpatronen voor, ongeacht de branche of de omvang van de organisatie. Alertmoeheid is er een van. Wanneer er waarschuwingen afgaan voor verlopen certificaten na 90, 60, 30 en 14 dagen voor duizenden certificaten, beginnen teams deze te negeren. Door het grote aantal waarschuwingen raken mensen eraan gewend het signaal te negeren, waardoor echte noodgevallen ondersneeuwen.

Een andere veelvoorkomende fout is de doorlooptijd. Externe certificeringsinstanties (CA's) met uitgebreide validatievereisten kunnen 10 tot 20 werkdagen nodig hebben om een ​​certificaat af te geven. Een verlengingsverzoek dat 30 dagen voor het verlopen van een certificaat met een geldigheidsduur van 47 dagen wordt ingediend, kan mogelijk niet worden verwerkt voordat het certificaat verloopt. Geautomatiseerde systemen moeten rekening houden met de CA-specifieke afgiftetermijnen in hun verlengingstriggers.

Een derde patroon is het behandelen van TLS-certificaatbeheer als een IT-operationele taak in plaats van een beveiligingsmaatregel. Slecht certificaatbeheer is een erkende oorzaak van inbreuken op encryptie en servicestoringen. Wanneer de certificaatstatus niet wordt gerapporteerd aan het beveiligingsmanagement, weerspiegelt de prioriteit die eraan wordt gegeven die blinde vlek.

Welke beveiligingsmaatregelen moet certificaatautomatisering omvatten?

Automatisering vermindert menselijke fouten in de vernieuwingscyclus, maar creëert nieuwe aanvalsoppervlakken. De ACME-client, de CA API-referenties en de certificaatleveringspipeline worden allemaal doelwitten voor aanvallers die frauduleuze certificaten in uw namespace willen uitgeven.

De inloggegevens die door geautomatiseerde TLS-certificaatbeheersystemen worden gebruikt om zich bij certificeringsinstanties (CA's) te authenticeren, moeten volgens een vast schema worden vernieuwd en opgeslagen in een HSM (Hardware Security Module) of een geheime kluis, niet in configuratiebestanden. Een gecompromitteerde CA-referentie geeft de mogelijkheid om certificaten uit te geven binnen uw domein.

Certificatentransparantielogboeken bieden een detectiemechanisme dat organisaties vaak onvoldoende benutten. Alle publiekelijk vertrouwde certificaten worden bij uitgifte openbaar geregistreerd. Door de CT-logboeken te controleren op onverwachte uitgiften binnen uw domein, worden ongeautoriseerde certificaten binnen enkele uren, in plaats van weken, opgespoord.

Voor organisaties die behoefte hebben aan een onafhankelijke beoordeling van hun huidige situatie, biedt Tailored Advisory Services architectuurreviews en implementatieplannen die aansluiten op de tijdlijn van het CA/Browser Forum.

Waarom is de periode van 47 dagen de bepalende factor?

De zeven bovengenoemde problemen zijn niet nieuw. Ze komen tegenwoordig voor in vrijwel elk certificaatsysteem van een onderneming. Wat wel nieuw is, is dat de geldigheidsperiode van 47 dagen de buffer wegneemt die ze voorheen beheersbaar maakte. Er is niet langer voldoende tijd tussen een gemiste melding en een verlopen certificaat om een ​​ticket aan te maken, een goedkeurder te vinden en een handmatige verlenging te voltooien.

De organisaties die de doorlopende deadlines van het CA/Browser Forum zonder problemen kunnen opvangen, bouwen nu al aan hun infrastructuur voor TLS-certificaatbeheer: een complete inventarisatie, geautomatiseerde verlenging, afgedwongen profielen, ketenbewaking, hardwarematige sleutelbescherming, duidelijke eigendomsstructuur en cryptografische flexibiliteit.

Wie wacht, krijgt te maken met een gedwongen modernisering onder operationele druk, wat de duurste manier is om infrastructurele veranderingen door te voeren.

Om te bespreken hoe uw organisatie ervoor staat ten opzichte van de deadline van 2029, kunt u contact opnemen met Encryption Consulting voor certificaatlevenscyclusbeheer.

Hoe encryptieconsulting u kan helpen

Encryption Consulting helpt organisaties alle bovengenoemde hiaten te dichten voordat steeds korter wordende geldigheidsperioden tot storingen leiden. Ons platform voor certificaatlevenscyclusbeheer, CertSecure Manager , detecteert certificaten in de gehele organisatie, automatiseert de verlenging via ACME en EST, handhaaft certificaatprofielen bij uitgifte en bewaakt de volledige vertrouwensketen, inclusief tussenliggende en rootcertificaten, met proactieve, door de eigenaar gerouteerde waarschuwingen.

Voor intern vertrouwen ontwerpen en beheren onze Enterprise PKI Services robuuste CA-hiërarchieën met HSM-ondersteunde sleutelbescherming die is gevalideerd volgens FIPS 140-3 . Daarnaast integreren onze adviesteams crypto-flexibiliteit en gereedheid voor post-kwantumcryptografie in uw architectuur, zodat u de FIPS 203- , FIPS 204- en FIPS 205- algoritmen kunt implementeren zonder uw uitgifteproces opnieuw te hoeven ontwerpen.

Via onze adviesdiensten op maat bieden we onafhankelijke beveiligingsassessments, architectuurreviews en implementatieplannen die aansluiten op de tijdlijn van het CA/Browser Forum, zodat uw overstap naar 47-daagse certificaten gepland is en niet geforceerd.

Conclusie

De overstap naar TLS-certificaten met een geldigheidsduur van 47 dagen is geen hypothetische toekomst. Het is een geplande, meerfasige verandering die al gaande is, waarbij de maximale geldigheidsduur nu 200 dagen bedraagt ​​en verder afneemt. De zeven problemen in dit artikel zijn dezelfde problemen die al jarenlang certificaatstoringen veroorzaken; wat is veranderd, is dat de kortere geldigheidsduur de handmatige veiligheidsmarge wegneemt die het herstel ervan voorheen mogelijk maakte.

Organisaties die nu actie ondernemen (een complete inventaris opbouwen, verlenging automatiseren, profielen afdwingen, de volledige keten bewaken, sleutels beschermen in FIPS 140-3-hardware, duidelijke verantwoordelijkheden toewijzen en ontwerpen voor crypto-flexibiliteit ) zullen elke deadline zonder problemen halen. Degenen die wachten, zullen te maken krijgen met een gedwongen modernisering onder hoge druk, volgens de planning van de sector in plaats van hun eigen planning. Het werk is duidelijk en de deadlines zijn openbaar; de enige variabele is of je begint vóór of na de volgende vervaldatum die een dienst uitvalt.