De geldigheidsduur van een codeondertekeningscertificaat is het maximale aantal dagen dat een publiekelijk vertrouwd codeondertekeningscertificaat geldig mag blijven voordat het moet worden vernieuwd. Sinds 1 maart 2026 is dat aantal gedaald naar 460 dagen, van de 39 maanden waarop teams jarenlang vertrouwden. Deze regel is afkomstig van de CA/Browser Forum Code Signing Baseline Requirements , de groep van certificeringsinstanties en browserleveranciers die de regels vaststelt waaraan elk publiek certificaat moet voldoen. Deze blog behandelt de wijzigingen, hoe ondertekening en tijdstempeling werken, waar privésleutels moeten worden opgeslagen en hoe u zich kunt voorbereiden zonder op het laatste moment in paniek te raken.
Wat is er veranderd op 1 maart 2026?
De regel zelf is eenvoudig. Elk codeondertekeningscertificaat dat op of na 1 maart 2026 is uitgegeven, mag geen geldigheidsperiode hebben die langer is dan 460 dagen, oftewel ongeveer 15 maanden. Certificaten die vóór die datum zijn uitgegeven, blijven geldig volgens hun oorspronkelijke schema totdat ze vanzelf verlopen. Hierdoor is er een tijdlang een mix van langlopende en kortlopende certificaten. De regel geldt voor zowel Organization Validation (OV) als Extended Validation (EV) certificaten, zonder uitzondering voor beide typen, en volgt een patroon dat de industrie al heeft toegepast op TLS-certificaten. Codeondertekening volgt deze ontwikkeling nu simpelweg.
Vanuit risicooogpunt is de redenering eenvoudig. Een codeondertekeningscertificaat staat voor vertrouwen, en dat vertrouwen blijft bestaan ​​zolang het certificaat geldig is. Als de privésleutel erachter ooit wordt gestolen of misbruikt, duurt de schade precies zo lang als het certificaat geldig is. Een certificaat met een geldigheidsduur van drie jaar geeft een aanvaller drie jaar de tijd om een ​​gestolen sleutel te blijven gebruiken. Een certificaat met een geldigheidsduur van 460 dagen verkort die periode met meer dan de helft en dwingt organisaties om sleutels volgens een voorspelbaar schema te vernieuwen in plaats van ze jarenlang ongebruikt te laten.
Kortere levensduur dwingt teams bijna noodgedwongen tot automatisering, omdat handmatig certificaatbeheer snel vastloopt zodra de verlenging elke 15 maanden in plaats van elke drie jaar plaatsvindt. Die verschuiving, van een incidentele taak naar een routinematig operationeel proces, is eigenlijk de kern van de regel, meer dan het specifieke aantal dagen dat is gekozen.
Hoe codeondertekening en tijdstempeling daadwerkelijk samenwerken
Wanneer een uitgever software ondertekent, wordt er een hash gegenereerd, een unieke vingerafdruk van de code die volledig verandert als er zelfs maar één byte wordt gewijzigd. Die hash wordt ondertekend met de privésleutel van de uitgever, wat resulteert in een digitale handtekening die samen met het openbare certificaat van de uitgever aan de software wordt gekoppeld. Wanneer een gebruiker het bestand downloadt, berekent het besturingssysteem de hash opnieuw en controleert deze aan de hand van de handtekening met behulp van de openbare sleutel. Als de hash overeenkomt en de certificaatketen teruggaat naar een vertrouwde root-CA, wordt de software als geverifieerd weergegeven; als er iets is gewijzigd sinds de ondertekening, is de handtekening ongeldig. Dit is waarom de privésleutel zo belangrijk is en waarom de regels met betrekking tot de opslag ervan steeds strenger worden.
Dit roept een voor de hand liggende vraag op: wat gebeurt er met software die je jaren geleden hebt ondertekend zodra het certificaat verloopt? Het antwoord is tijdstempeling, het allerbelangrijkste detail in deze overgang. Wanneer je code ondertekent, kan je software de handtekening ook naar een Time Stamping Authority (TSA) sturen, een vertrouwde derde partij die cryptografisch bewijs vastlegt van het moment waarop de handtekening is aangemaakt, volgens het IETF RF C 3161 Time-Stamp Protocol , een standaard die de meeste ondertekeningstools al ondersteunen.
Zodra een tijdstempel is toegevoegd, kan het besturingssysteem bevestigen dat de handtekening is aangemaakt terwijl het certificaat nog geldig was, zelfs nadat dat certificaat is verlopen. Het vertrouwen wordt vastgelegd op het moment van ondertekening, niet wanneer iemand het bestand opent. Dit maakt frequente certificaatrotatie überhaupt mogelijk.
Het probleem is dat tijdstempels niet overal automatisch worden toegevoegd. Sommige oudere buildscripts slaan dit over en sommige verouderde tools controleren het niet correct. Aangezien certificaten nu ongeveer elke 15 maanden verlopen, is het de moeite waard om uw ondertekeningsproces vandaag nog te controleren om te bevestigen dat elke build correct van een tijdstempel is voorzien. Het correct toevoegen van tijdstempels is echter slechts de helft van het werk; de andere helft is ervoor zorgen dat de bijbehorende pipeline gelijke tred kan houden met certificaten die nu elke 15 maanden in plaats van elke paar jaar worden vernieuwd.
Je build-pipeline voorbereiden
Voor de meeste teams komt de operationele impact neer op een paar concrete veranderingen. Buildsystemen kunnen niet langer een certificaatpad hardcoderen en ervan uitgaan dat dit jarenlang zal werken; pipelines moeten het actuele, geldige certificaat dynamisch ophalen in plaats van te verwijzen naar een statisch bestand dat halverwege een release uiteindelijk verouderd raakt. Omgevingen voor digitale handtekeningen, die veel voorkomen in industriële besturing, de gezondheidszorg en overheidssoftware, hebben een voorspelbaar schema nodig voor het importeren van nieuwe certificaten, omdat ze vaak geen verlenging automatisch kunnen ophalen.
De aanschaf van certificaten voor meerdere jaren moet plaatsmaken voor frequentere verlengingen en de bijbehorende budgettering en goedkeuringstijd. Iedereen die EV- of OV-certificaten beheert, heeft een verlengingskalender nodig die rekening houdt met de tijd die de CA nodig heeft voor validatie. Dit kan enkele dagen duren en mag nooit tot het laatste moment worden uitgesteld.
Op zichzelf is dit allemaal niet moeilijk. De echte uitdaging is dat het ondertekenen van certificaten historisch gezien werd beschouwd als een eenmalige installatietaak die eens in de paar jaar werd uitgevoerd, en niet als een continu proces. Door het in een korte reeks stappen aan te pakken, wordt de overgang beheersbaar. Begin met een complete inventarisatie: maak een lijst van alle codeondertekeningscertificaten op buildservers, CI/CD-pipelines, ondertekeningswerkstations en air-gapped omgevingen, en noteer de uitgevende CA, de uitgiftedatum, de vervaldatum en waar elke privésleutel zich bevindt. Dit levert meestal meer certificaten op dan teams verwachten.
Maak vervolgens tijdstempels onmisbaar door uw ondertekeningsscripts te controleren en te bevestigen dat elke build een tijdstempel krijgt via een vertrouwde TSA. Automatiseer vervolgens de verlenging en sleutelrotatie waar handmatige stappen nog nodig zijn, aangezien handmatige verlenging niet schaalbaar is zodra certificaten elke 15 maanden verlopen. Stel ten slotte een duidelijk beleid op met betrekking tot sleutelsterkte, goedgekeurde algoritmen, het vereiste HSM-certificeringsniveau en certificaateigendom, en houd een auditspoor bij van elke ondertekeningsbewerking, zodat compliance-audits probleemloos verlopen.
Een paar veelgemaakte fouten sijpelen steeds terug. Hier volgen een paar tips om ze te voorkomen:
- Ga er niet van uit dat al uw certificaten op dezelfde datum verlopen; u zult een tijdlang een mix van certificaten met een lange en een korte geldigheidsduur naast elkaar hebben.
- Vergeet niet dat pipelines die gebouwd zijn rond een statisch certificaatbestand niet meer werken zodra dat certificaat verloopt, vaak midden in een release.
- Beschouw tijdstempels niet als optioneel, aangezien ze de belangrijkste factor zijn in de betrouwbaarheid van oudere, ondertekende software.
- Laat privésleutels niet ongewijzigd bij verlengingen, aangezien dit een groot deel van het beveiligingsvoordeel tenietdoet dat een kortere geldigheidsduur juist zou moeten bieden.
Op deze manier aangepakt, is een kortere geldigheidsduur van certificaten geen bron van stress meer, maar een routineonderdeel van de softwarelevering. De gewoonten die u nu ontwikkelt, zijn precies wat de volgende, grotere cryptografische verschuiving vereist, waardoor de inspanning nooit voor niets is.
Hoe dit verband houdt met crypto-wendbaarheid en paraatheid na het kwantumtijdperk.
Dezelfde vaardigheden die u ontwikkelt voor het beheren van 460-daagse codeondertekeningscertificaten, namelijk ontdekking, automatisering en snelle rotatie, zijn precies wat uw organisatie nodig heeft voor de bredere verschuiving naar post-kwantumcryptografie (PQC). NIST heeft in augustus 2024 de eerste post-kwantumstandaarden afgerond: FIPS 203 (ML-KEM) voor sleutelinkapseling, en FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) voor digitale handtekeningen. Dit zijn definitieve standaarden, geen concepten, en van organisaties wordt verwacht dat ze hier nu al rekening mee houden bij hun planning.
Codeondertekening kent een eigen deadline die het waard is om te kennen. De Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) van de NSA vereist dat software- en firmwareondertekening post-kwantumalgoritmen ondersteunt en de voorkeur geeft aan deze, met name de stateful hash-gebaseerde schema's LMS en XMSS (NIST SP 800-208). Deze fase is in 2025 van start gegaan en exclusief gebruik is vereist vanaf 2030. Door nu al een sterke cryptografische inventaris en rotatiegewoonten op te bouwen, terwijl u de overgangsperiode van 460 dagen doorloopt, is uw team voorbereid op deze verandering in plaats van later helemaal opnieuw te moeten beginnen.
Crypto-agility is het vermogen om cryptografische algoritmen, sleutels en certificaten te vervangen met minimale verstoring van bestaande systemen. Hierdoor kunnen organisaties snel reageren op het verouderen van algoritmen, veranderende regelgeving of opkomende dreigingen zonder hun infrastructuur voor digitale handtekeningen opnieuw te hoeven ontwerpen. In de praktijk betekent dit dat de overstap naar nieuwe standaarden, zoals die vereist zijn onder CNSA 2.0 of toekomstige richtlijnen voor het post-kwantumtijdperk, een operationele wijziging van het cryptografische beleid wordt in plaats van een kostbare technische inspanning.
Het biedt ook operationele veerkracht. Als een ondertekeningsalgoritme verouderd raakt, een kwetsbaarheid wordt ontdekt of de wettelijke goedkeuring verandert, kunnen organisaties overstappen op een alternatief algoritme zonder de software-releaseprocessen te onderbreken. Tijdens de migratieperiode na de kwantumtechnologie is de aanbevolen strategie hybride codeondertekening, waarbij elk artefact wordt ondertekend met zowel een klassiek algoritme (zoals ECDSA of RSA) als een post-kwantumalgoritme (zoals ML-DSA of LMS). Dit stelt vertrouwende partijen in staat om handtekeningen te valideren met behulp van beide schema's, waardoor de interoperabiliteit met bestaande systemen behouden blijft en cryptografische continuïteit wordt gewaarborgd naarmate post-kwantumondersteuning zich verder verspreidt.
Organisaties die hun infrastructuur voor codeondertekening al hebben gemoderniseerd met geautomatiseerd certificaatlevenscyclusbeheer, regelmatige certificaatrotatie, veilige sleutelopslag in hardwarematige omgevingen en RFC 3161-conforme tijdstempels, zijn aanzienlijk beter gepositioneerd om nieuwe algoritmen te implementeren naarmate standaarden evolueren. In de praktijk is het bereiken van dit niveau van cryptografische flexibiliteit veel eenvoudiger met speciaal daarvoor ontwikkelde tools en de juiste expertise.
Hoe encryptieconsultancy kan helpen
Het overstappen naar een kortere geldigheidsduur van codeondertekening is veel eenvoudiger wanneer uw certificaat- en sleutelbeheer al georganiseerd is, in plaats van verspreid over verschillende teams en tools. Encryption Consulting werkt samen met beveiligings-, PKI- en DevSecOps-teams om structuur te brengen in dit soort overgangen, te beginnen met een helder overzicht van waar elk certificaat en elke sleutel zich momenteel bevindt.
Ons team helpt organisaties bij het bouwen en moderniseren van hun infrastructuur voor publieke sleutels, en ons CodeSign Secure- platform is specifiek ontworpen om de werkwijzen in deze blog te operationaliseren: HSM-ondersteunde opslag van privésleutels, beleidsgestuurde goedkeuringsworkflows, automatische tijdstempeling bij elke ondertekeningsbewerking en gedetailleerde audit trails. CodeSign Secure biedt ook native ondersteuning voor post-quantum ondertekeningsalgoritmen zoals ML-DSA en LMS, zodat teams die het nu implementeren geen tweede migratieproject hoeven te starten wanneer de deadlines voor CNSA 2.0 naderen.
Naast het ondertekenen van code bieden we ook ondersteuning bij het beheer van de levenscyclus van certificaten, sleutelbeheer en het afstemmen van uw naleving op standaarden zoals NIST en PCI DSS. Zo zorgen we ervoor dat uw ondertekeningsproces bestand is tegen audits en aanvallen.
Conclusie
De overstap naar codeondertekeningscertificaten met een geldigheidsduur van 460 dagen is een belangrijke verandering, maar wel beheersbaar als u er nu mee begint. Zorg voor een duidelijke inventarisatie van uw certificaten, maak tijdstempels standaard, vervang privésleutels bij elke verlenging en automatiseer alle handmatige stappen. Teams die dit als routineonderhoud beschouwen, zullen de overgang nauwelijks merken. Teams die wachten, zullen de gevolgen merken in hun releaseplanning, waarschijnlijk meer dan eens, aangezien dit de eerste is van een reeks verlagingen van de levensduur van certificaten die nog zullen volgen. Als u hulp nodig heeft om uw codeondertekening en certificaatlevenscyclusbeheer voor te bereiden op deze verandering, of op wat erna komt, is Encryption Consulting een goede plek om dat gesprek te beginnen.
