Certificaatcontrole vóór uitgifte met pkilint en zlint

Certificaatcontrole vóór uitgifte controleert een certificaat aan de hand van RFC 5280, de basisvereisten van het CA/Browser Forum en de toepasselijke profielregels, voordat het wordt ondertekend. Hierbij worden open-source tools zoals pkilint en zlint gebruikt. Omdat een onjuist uitgegeven certificaat binnen 24 uur moet worden ingetrokken, is het opsporen van een profielfout vóór de ondertekening nu een operationele noodzaak in plaats van een aanbevolen werkwijze, vooral nu de kortere geldigheidsduur van certificaten het uitgiftevolume sterk doet toenemen.

Een certificaat is een kleine, rigide datastructuur die wordt beheerst door een groot aantal regels: RFC 5280, de CA/Browser Forum Baseline Requirements, profielspecifieke richtlijnen en het beleid van elk rootprogramma dat het vertrouwt. Als er een veld fout is, een extensie ontbreekt, een naam onjuist is opgemaakt of een waarde buiten het beleid staat, is het certificaat niet alleen onvolmaakt; volgens de industrieregels is het onjuist uitgegeven en moeten onjuist uitgegeven certificaten binnen een zeer korte termijn worden ingetrokken. Certificaatcontrole (linting) is de praktijk waarbij een certificaat automatisch wordt gecontroleerd aan de hand van deze regels, terwijl pre-uitgiftecontrole (pre-issuance linting) het certificaat controleert voordat het wordt ondertekend. Het verschil tussen de twee is vergelijkbaar met het verschil tussen het voorkomen van een defect en het achteraf verontschuldigen ervan.

Dit artikel legt uit waarom linting vóór uitgifte in 2026 is geëvolueerd van een goede gewoonte naar een operationele noodzaak, hoe de open-source linters pkilint en zlint werken, wat de kosten kunnen zijn van één enkel onjuist profiel wanneer dit een massale intrekking veroorzaakt, en hoe linting in een uitgifteproces kan worden geïntegreerd zodat een profielfout wordt opgespoord voordat deze leidt tot een intrekking met juridische stappen. De stelling is eenvoudig: bij de huidige uitgiftevolumes is preventie de enige economisch haalbare controle, en linting vóór uitgifte is waar die preventie plaatsvindt.

Key Takeaways

• Bij een linter vóór uitgifte wordt een certificaat gecontroleerd aan de hand van RFC 5280, de Baseline Requirements en de toepasselijke profielen voordat het wordt ondertekend. Hierdoor wordt een defect voorkomen in plaats van dat het certificaat achteraf wordt ingetrokken.
• Een onjuist uitgegeven certificaat kan binnen 24 uur worden ingetrokken op grond van paragraaf 4.9.1.1 van de basisvereisten. Voorkomen is beter dan opsporen.
• Zlint en pkilint zijn de twee meest gebruikte open-source linters, en volwassen software-implementatieprocessen gebruiken ze allebei omdat hun regeldekking verschilt.
• De door het CA/Browser Forum ingevoerde gefaseerde verkorting van de geldigheidsduur naar 200, 100 en 47 dagen verhoogt het aantal uitgiften ruwweg met een factor acht, van ongeveer 1,000 verlengingen per jaar naar meer dan 8,000, waardoor zowel de kans op als de impact van een defect in gedeelde profielen toeneemt.
• De PKI-, beveiligings-, platform- en compliance-teams zijn elk verantwoordelijk voor een specifieke actie; de ​​onderstaande matrix met verantwoordelijkheden en acties en de beslissingstabel geven precies aan wat en wie verantwoordelijk is.

Ga direct naar: Samenvatting | Checklist gereedheid | Beslissingstabel | Verantwoordelijkheids-/actiematrix | Wat te doen? | Veelgestelde vragen

Samenvatting voor de teams PKI, Beveiliging, Platform en Compliance

Als u een van deze functies leidt, vindt u hier de beslissing die in dit artikel wordt ondersteund en de bijbehorende beknopte actiehandleiding.

• PKI-teams: Bevestig dat er vóór de publicatie linting plaatsvindt met zowel zlint als pkilint als een fail-closed gate op elk publicatiepad, en dat elk profiel wordt gecontroleerd voordat het live gaat.
• Beveiligingsteams: Begrijp de 24-uurs intrekkingstermijn die een detecteerbare lintingfout kan activeren en bevestig dat geen enkel uitgiftepad deze poort omzeilt.
• Platform-/DevOps-teams: Integreer linting in CI/CD als een controle tijdens het bouwproces, op dezelfde manier als code wordt gescand op beveiliging vóór de implementatie.
• Nalevingsteams: Bevestig dat de gegevens over het verzamelen van stof en de inventarisatie bewaard blijven als bewijsmateriaal voor een audit, waaruit blijkt dat aan de basisvereisten is voldaan.

Snelle gereedheidschecklist

Gebruik deze checklist om te beoordelen of uw uitgifteproces daadwerkelijk beschermd is, en niet alleen dat u zich bewust bent van het risico.

• De bevestigde linting voorafgaand aan de uitgifte werkt als een fail-closed gate, waardoor een certificaat dat de linting niet doorstaat, nooit wordt ondertekend.
• Er is geverifieerd dat zowel zlint als pkilint in die gate actief zijn, en dat de combinatie van hun bevindingen de uitgifte blokkeert.
• Gecontroleerd of elk profiel wordt gelint bij het aanmaken of wijzigen ervan, voordat het op grote schaal wordt uitgegeven.
• Bevestigde linting na uitgifte en steekproeven in het CT-logboek dienen als vangnet, niet als primaire controle.
• Het vaststellen van de omvang van de schade, het informeren van de eigenaren en het opnieuw uitgeven van certificaten binnen 24 uur werden geoefend.

Waarom is dit nu belangrijk?

Drie factoren komen samen waardoor linting vóór uitgifte urgent is geworden. De geldigheidsduur van certificaten wordt korter, waardoor het uitgiftevolume toeneemt; een onjuist uitgegeven certificaat heeft nu een intrekkingstermijn van enkele uren; en de duurste recente mislukkingen in de sector zijn terug te voeren op profieldefecten die een linter had kunnen detecteren. Samen zorgen deze factoren ervoor dat linting niet langer een goede hygiëne is, maar een operationele controlemaatregel.

Kortere looptijden betekenen een veel hoger uitgiftevolume.

De gefaseerde verkorting van de levensduur van TLS-certificaten door het CA/Browser Forum, beginnend met het maximum van 200 dagen in maart 2026 en oplopend tot 47 dagen in 2029, zorgt voor een enorme toename van het aantal uitgiften. Dezelfde voorraad die voorheen ongeveer 1,000 verlengingen per jaar genereerde, zal onder het 47-dagenregime meer dan 8,000 verlengingen per jaar opleveren. Elk van deze uitgiften doorloopt dezelfde profiellogica, waardoor een enkele configuratiefout geen op zichzelf staande vergissing is, maar een defect dat op elk certificaat dat door dat profiel wordt geproduceerd, wordt geregistreerd.

Elke uitgifte biedt een kans dat een profielfout erdoorheen glipt, en bij zo'n hoog volume verspreidt een fout in een gedeeld profiel zich snel. Een hogere doorvoer verhoogt zowel de kans als de impact van een onjuist certificaat. Het verkort ook de tijd die beschikbaar is om een ​​systeemfout op te merken voordat deze zich over een heel profiel heeft verspreid.

Uit het Trust Pulse -onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat 45% van de organisaties het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen, en dat 37.5% een storing specifiek kon herleiden tot een verlopen certificaat . Elke verlenging is een nieuwe stap in dezelfde profiellogica, dus hoe hoger de verlengingsfrequentie, hoe meer uitgiften een enkel profieldefect kan bereiken voordat iemand het ontdekt.

Het voorstel SC-081v3 van het CA/Browser Forum , goedgekeurd op 14 april 2025, verlengt de maximale geldigheidsduur van openbare TLS-certificaten van de huidige 398 dagen naar 200 dagen (maart 2026), 100 dagen (maart 2027) en 47 dagen (maart 2029). Dit is het volledige schema dat ten grondslag ligt aan de hierboven beschreven toename van het uitgiftevolume.

Bij onjuiste uitgifte geldt een herroepingsperiode van 24 uur.

De gevolgen van een ongeldig certificaat worden gedefinieerd in de basisvereisten. Paragraaf 4.9.1.1 stelt de termijnen voor intrekking vast: in sommige situaties is intrekking binnen 24 uur vereist, terwijl in andere gevallen maximaal 5 dagen is toegestaan; deze termijnen gelden ongeacht of het om een ​​enkel certificaat of een massale intrekking gaat.

Een lintingfout valt absoluut binnen het toepassingsgebied: als een probleem dat door linting had kunnen of moeten worden opgemerkt toch wordt gemeld, is dat eerder een ontwerpfout dan een extern gemeld probleem, en als zodanig activeert het zeker de 24-uursklok. Er is zeer weinig tijd om te reageren, daarom is voorkomen beter dan opsporen. Een poort die een ongeldig certificaat blokkeert vóór de ondertekening, heft de klok volledig op, omdat er nooit iets onbetrouwbaars wordt uitgegeven.

De waarschuwende verhalen zijn recent en kostbaar.

Twee gebeurtenissen maken de ernst van de situatie concreet. In juli 2024 kondigde DigiCert de gedwongen intrekking aan van 83,267 certificaten die waren uitgegeven aan 6,807 klanten. Deze klanten kregen 24 uur de tijd om de certificaten te vervangen nadat was ontdekt dat bij sommige CNAME-gebaseerde domeinvalidaties een underscore-prefix ontbrak. De gevolgen waren zo ernstig dat een van de getroffen klanten, het technologiebedrijf Alegeus in de zorgsector, DigiCert aanklaagde en een voorlopige voorziening won die de intrekking opschortte. Daarnaast droeg de onjuiste uitgifte van meer dan 26,000 EV TLS-certificaten door Entrust, in combinatie met een trage oplossing, bij aan het besluit van Google Chrome om na 31 oktober 2024 geen vertrouwen meer te hebben in TLS-certificaten van Entrust. Profiel- en validatiefouten zijn geen theoretische kwestie; ze hebben geleid tot massale intrekkingen, rechtszaken en het verlies van de vertrouwensstatus van een certificeringsinstantie.

Hoe werkt pluizen verwijderen?

Voordat we kijken naar de plaats van linting in een pipeline, is het handig om te begrijpen wat een linter doet, hoe deze praktijk een industrienorm is geworden en welke tools dominant zijn. De volgende paragrafen behandelen wat lintingcontroles zijn, hoe het is voortgekomen uit Certificate Transparency, de twee open-source linters waar de meeste teams op vertrouwen en het cruciale verschil tussen het controleren van een certificaat vóór en na ondertekening.

Welke pluizencontroles

Linting is het proces waarbij statische analyse wordt uitgevoerd op broncode om patronen te signaleren die fouten kunnen veroorzaken. Toegepast op certificaten, analyseert het elk certificaat aan de hand van de TLS Baseline Requirements, EV Guidelines en RFC 5280, indien van toepassing.

Een linter analyseert een certificaat en evalueert honderden regels: vereiste en verboden extensies, naamcodering, consistentie van sleutelgebruik en uitgebreid sleutelgebruik, geldigheidsperiodebeperkingen, serienummerentropie en de vele structurele beperkingen die de standaarden opleggen. Duizenden individuele controles worden uitgevoerd op basis van RFC 5280, de Baseline Requirements en rootprogrammaprofielen. De linter retourneert fouten, waarschuwingen en meldingen, waardoor de uitgever een niet-conform certificaat kan corrigeren of afwijzen. Omdat de regels talrijk zijn en regelmatig worden bijgewerkt, kan een menselijke beoordelaar ze niet betrouwbaar toepassen met de snelheid van een certificaatuitgifte. Dit is precies de reden waarom de controle geautomatiseerd moet zijn.

Hoe het verwijderen van pluizen een standaardpraktijk werd.

Linting is voortgekomen uit Certificate Transparency (CT). Toen certificeringsinstanties (CA's) verplicht werden certificaten te registreren in openbare CT-logs, konden tools zoals crt.sh elk geregistreerd certificaat analyseren. De lintingresultaten van begin 2016 brachten wijdverspreide fouten en waarschuwingen aan het licht in bijna alle certificaten van CA's, wat in feite neerkwam op een openbare aanklacht. Cruciaal is dat linting door de CA direct kan worden ingezet op het eigen certificaat dat nog moet worden ondertekend, of op een CT-precertificaat. Hierdoor kan de CA voorkomen dat een niet-conform certificaat wordt uitgegeven, of het kort daarna detecteren. Die eerste optie, preventie vóór ondertekening, wordt pre-issuance linting genoemd. Het verplaatst de controle naar een eerder stadium, van een openbare audit van reeds uitgegeven certificaten naar een interne controle op certificaten die op het punt staan ​​te worden uitgegeven.

pkilint en zlint

Twee open-source linters domineren. zlint, onderhouden door het zmap-project, en pkilint, onderhouden door DigiCert, zijn de twee meest gebruikte, naast oudere tools zoals certlint en het handmatige lintcert-hulpprogramma. zlint is te vinden op github.com/zmap/zlint en pkilint op github.com/digicert/pkilint.

Ze verschillen in implementatie en regeldekking, waardoor volwassen uitgifteprocessen vaak meer dan één linter gebruiken: zlint is een veelgebruikte linter in Go met brede dekking van Baseline Requirements en RFC 5280, terwijl pkilint een Python-framework is met diepgaande, profielbewuste controles voor verschillende certificaattypen, waaronder S/MIME en andere profielen. Het gebruik van beide verhoogt de kans dat een defect wordt ontdekt vóór de ondertekening. In de praktijk is de profielbewustheid van pkilint waardevol voor niet-webcertificaattypen, terwijl de volwassenheid en snelheid van zlint geschikt zijn voor webuitgifte met een hoge doorvoer.

Linting vóór versus na uitgifte

Het onderscheid is operationeel belangrijk. Linting vóór uitgifte wordt uitgevoerd op het te ondertekenen certificaat, dus een fout blokkeert de uitgifte en er bereikt niets schadelijks de buitenwereld. Linting na uitgifte wordt achteraf uitgevoerd, als steekproef, als compenserende controle of bij het testen van nieuwe linterregels.

Het onderscheid is belangrijk voor de intrekkingstermijn: een lintingfout vóór de release die een detecteerbaar probleem doorlaat, is een ontwerpfout die de 24-uurstermijn activeert, terwijl bevindingen na de release meer te vergelijken zijn met een extern gemeld probleem, omdat het linterbeleid nog niet is geoptimaliseerd en nader onderzoek vereist. De les is dat linting vóór de release de controle is die schade voorkomt; linting na de release is een vangnet, geen vervanging. Door het vangnet als primaire controle te beschouwen, bereiken detecteerbare defecten überhaupt de productie.

Risico's en valkuilen

Zowel het ontbreken van linting als het verkeerd gebruik ervan brengt risico's met zich mee. De onderstaande tabel geeft een overzicht van de meest voorkomende oorzaken en gevolgen van een profielfout voor de bedrijfsvoering, met de bijbehorende informatie en de waarschijnlijke consequenties.

Risico	Veroorzaken	consequentie
Massale herroeping	Een misvormd gedeeld profiel dat in grote hoeveelheden is uitgegeven.	Duizenden certificaten ingetrokken binnen 24 uur.
Rechtszaken en stroomuitval	Klanten kunnen certificaten niet tijdig vervangen.	Contactverboden, stroomuitval en reputatieschade.
Verlies van CA-vertrouwen	Herhaalde foutieve uitgifte en trage afhandeling.	Rootprogramma's wantrouwen de CA en verklaren al haar certificaten ongeldig.
Vals vertrouwen	Uitsluitend vertrouwen op linting na uitgifte.	Defecten bereiken de productie voordat ze worden ontdekt.
Blinde vlekken van de linter	Een enkele linter mist een regel die een andere wel zou opmerken.	Te verhelpen gebreken glippen erdoorheen en worden toch uitgegeven.
Profielverschuiving	Nieuwe profielen of regelwijzigingen zijn niet getest.	Een eerder geldige uitgifte voldoet nu niet meer aan de eisen.

Het defect zit verborgen in het profiel, niet in het certificaat.

Een cruciaal punt is dat massale intrekkingen van certificaten meestal voortkomen uit een fout in een profiel of uitgifteconfiguratie die van toepassing is op veel certificaten, in plaats van een eenmalige vergissing. Het DigiCert-incident illustreert dit precies: het weglaten van het underscore-voorvoegsel was een eigenschap van een validatiepad en trof ongeveer 0.4 procent van de toepasselijke domeinvalidaties over tienduizenden certificaten.

Een enkel profieldefect heeft gevolgen voor de gehele populatie waarop het profiel betrekking heeft. Door middel van linting vóór uitgifte wordt het defect in het eerste certificaat opgespoord, voordat het profiel duizenden andere certificaten heeft uitgegeven. Dat is het doorslaggevende economische argument voor de controle: de kosten voor het opsporen van een defect zijn al hoog bij één certificaat, terwijl de kosten voor het missen ervan evenredig zijn met de gehele profielpopulatie.

Zelfs gedisciplineerde registeraccountants hebben moeite met de logistiek.

Wanneer een massale intrekking plaatsvindt, is het lastig om deze binnen de gestelde termijn uit te voeren. Bij het DigiCert-incident had de certificeringsinstantie moeite om vast te stellen welke certificaten waren getroffen en welke al waren vervangen. Een belangrijke complicatie was dat veel van hun klanten geen uitgebreid gebruik maakten van geautomatiseerd certificaatlevenscyclusbeheer, waardoor snelle vervanging lastig was. Preventie bij de uitgifte voorkomt deze hele chaos. Een defect dat nooit wordt ondertekend, leidt niet tot intrekking, geen melding aan de klant en geen race tegen de klok van 24 uur.

Beste praktijken voor implementatie

Effectief linten implementeren draait om het plaatsen van de juiste controle op het juiste moment in het proces. De onderstaande werkwijzen beginnen bij de allerbelangrijkste controle, linten vóór ondertekening, en werken vervolgens naar de inventarisatie en repetitie die alles omvatten wat de controlepoort over het hoofd ziet.

1. Controleer de pagina's voordat je tekent, altijd: Voer een lintertest uit op het te ondertekenen certificaat of het CT-precertificaat en configureer de uitgifte zodanig dat deze mislukt als er een fout optreedt: als de lintertest een fout meldt, wordt het certificaat niet ondertekend. Deze controle voorkomt schade in plaats van deze te detecteren. CertSecure Manager Dit zorgt ervoor dat deze poort standaard bij elke uitgifte wordt afgedwongen, waardoor het fail-closed-gedrag is ingebouwd in plaats van dat elke pipeline dit handmatig moet configureren.
2. Voer meer dan één linter uit: Gebruik zowel zlint als pkilint, omdat hun regeldekking verschilt en de ene vaak fouten detecteert die de andere over het hoofd ziet. Beschouw de combinatie van hun fouten als een blokkerende voorwaarde. De marginale kosten van het uitvoeren van een tweede linter zijn verwaarloosbaar in vergelijking met de kosten van één gemiste fout. Beide linters worden binnen de uitgiftepoort uitgevoerd, waardoor de combinatie van hun fouten het ondertekenen blokkeert zonder extra integratiewerk.
3. Controleer het profiel, niet alleen het certificaat: Omdat defecten die leiden tot massale intrekking van certificaten hun oorsprong vinden in profielen en de uitgifteconfiguratie, moeten representatieve certificaten van elk profiel worden gecontroleerd telkens wanneer een profiel wordt aangemaakt of gewijzigd, voordat ze op grote schaal worden uitgegeven.
4. Zorg dat linters en regelsets actueel blijven: De basisvereisten, het beleid van het hoofdprogramma en de profielrichtlijnen wijzigen; werk de linterversies en regelconfiguraties bij, zodat een vandaag conforme uitgave ook morgen conform blijft.
5. Gebruik de linting na uitgifte als vangnet, niet als vervanging: Ga door met het steekproefsgewijs controleren van uitgegeven en in CT geregistreerde certificaten om eventuele fouten van de pre-uitgiftecontrole op te sporen en nieuwe regels te valideren, maar vertrouw hier nooit volledig op als primaire controlemethode.
6. Combineer pluizenverwijdering met automatisering en voorraadbeheer: Omdat kortere geldigheidsperioden het volume verhogen, moet u ervoor zorgen dat afhankelijke systemen snel nieuwe certificaten kunnen uitgeven als intrekking ooit nodig is. Daarnaast is het belangrijk een inventaris bij te houden die elk certificaat koppelt aan de eigenaar en het profiel, zodat de reikwijdte binnen enkele minuten in plaats van dagen kan worden bepaald. Een actuele inventaris zorgt ervoor dat een intrekkingsverzoek wordt omgezet in een werklijst in plaats van een onderzoek. Dit is precies wat het biedt: geautomatiseerde verlenging voor al uw certificeringsinstanties, gecombineerd met een gecentraliseerde inventaris die elk certificaat koppelt aan de eigenaar en het profiel.
7. Oefen een reactie op een intrekking: Zelfs met een grondige controle voorafgaand aan de uitgifte, is het belangrijk om te plannen en te testen hoe u de omvang van het probleem vaststelt, eigenaren op de hoogte stelt en binnen 24 uur een nieuwe versie uitgeeft. Zo blijft een eventueel resterend incident beperkt in plaats van dat het tot chaos leidt.

Wat betekent dit voor beveiligingsteams?

Het controleren van certificaten vóór uitgifte is niet alleen een PKI-kwestie; het raakt elk team dat certificaten uitgeeft, gebruikt of erop reageert. De verantwoordelijkheden verschillen per rol, maar de steeds korter wordende levensduur van certificaten verhoogt de risico's voor iedereen.

• PKI-teams Ze beheren de uitgiftepipeline en de profielen waar defecten ontstaan, en zijn primair verantwoordelijk voor de linting voorafgaand aan de uitgifte. CertSecure Manager Het biedt hen één centrale plek om de linting-gateway te handhaven en profielen te beheren voor alle CA's, zowel publieke als private.
• Iedereen die een privé-CA runt Het systeem erft hetzelfde risico op interne schaal en profiteert van linting, ook al vallen privécertificaten buiten de regels van het openbare rootprogramma, aangezien een onjuist geformuleerd intern certificaat nog steeds mTLS kan verstoren of een service kan platleggen.
• DevSecOps-teams Het integreren van geautomatiseerde certificaatuitgifte in pipelines zou linting moeten behandelen als een controlepunt tijdens het buildproces, op dezelfde manier als beveiligingsscans van code, waarbij de build mislukt als een certificaat niet wordt goedgekeurd. De ACME- en REST API-integraties stellen hen in staat om dit controlepunt direct in bestaande CI/CD-pipelines te integreren.
• CISO's Dit kan leiden tot een massale intrekking van licenties, met als gevolg onder andere een storing, juridische procedures en in het ergste geval het volledige verlies van vertrouwen in de CA.
• Compliance- en auditteams Het systeem vertrouwt op linting als gedocumenteerd bewijs dat de uitgifte voldoet aan de basisvereisten en relevante profielen, en als een herhaalbare, geautomatiseerde controle in plaats van een handmatige beoordeling. Dit bewijs wordt centraal vastgelegd, waardoor de auditvoorbereiding een rapport wordt in plaats van een hectische klus.

Hoe kan encryptieconsulting u helpen?

Het opsporen van een onjuist profiel voordat het wordt ondertekend, en het overleven van de zeldzame misser, vereist meer dan open-source linters die aan een script zijn toegevoegd. Het vereist een platform dat de linting bij elke uitgifte afdwingt, een actuele inventaris bijhoudt van wat er is uitgegeven en op grote schaal opnieuw kan uitgeven zodra een intrekking nodig is.

Dat is precies waarvoor onze CertSecure Manager is ontworpen. Ons platform voor certificaatlevenscyclusbeheer voert een linting vóór uitgifte uit als een consistente, gegarandeerde controle op elk profiel. Hierdoor wordt een onjuist certificaat geblokkeerd voordat het wordt ondertekend, in plaats van dat het pas achteraf in een CT-logboek wordt ontdekt. ​​Omdat de dekking van de regels verschilt tussen linters, voert het zowel zlint als pkilint uit in die controle en beschouwt de combinatie van hun bevindingen als een blokkering. Het controleert representatieve certificaten telkens wanneer een profiel wordt aangemaakt of gewijzigd, waardoor een defect in het profiel wordt opgespoord voordat het in grote aantallen wordt gebruikt. Het platform beheert een gecentraliseerde inventaris die elk certificaat koppelt aan de eigenaar, het profiel en de afhankelijke systemen, zodat een intrekkingsverzoek binnen enkele minuten in plaats van dagen kan worden afgehandeld.

Achter de poort zorgt het ervoor dat de linter-regels actueel blijven naarmate de basisvereisten en het beleid van het rootprogramma evolueren, voert het steekproeven uit op CT-geregistreerde certificaten als vangnet na uitgifte en registreert het elke controle als auditklaar bewijs. Bovendien automatiseert het de verlenging en heruitgifte voor uw openbare en private CA's, zodat de kortere levensduur die al dit volume veroorzaakt nooit tot storingen leidt. Dankzij ACME- en REST-integraties zijn dezelfde controles van toepassing, ongeacht of een certificaat wordt uitgegeven vanuit een CI/CD-pipeline of een traditionele PKI.

Diezelfde discipline strekt zich verder uit dan certificaten. Ons CBOM Secure- platform voert dezelfde certificaatdetectie uit voor het volledige cryptografische landschap van een organisatie, en onze handleiding CBOM: Van inventaris naar intelligentie beschrijft hoe u van die inventaris een doorlopend programma kunt maken. Omdat certificaatautomatisering in CertSecure Manager CA-agnostisch is, zorgt dezelfde linting- en inventarisatiediscipline die vandaag de dag massale intrekkingen voorkomt, ook voor de crypto-flexibiliteit die teams nodig hebben in de aanloop naar de post-quantum transitie. Onze 9-fasen PQC- gereedheidsroadmap en het PQC Center of Excellence helpen u bij het plannen van die migratie, in combinatie met het hierboven beschreven werk op het gebied van certificaatbeheer.

Het principe achter het platform is hetzelfde als waar dit artikel voor pleit: het op grote schaal correct uitgeven van certificaten is een technisch proces, geen handmatige controle. Controleer certificaten vóór ondertekening, automatiseer verlenging en ken uw inventaris, zodat een enkel onjuist profiel al bij het eerste certificaat wordt opgemerkt in plaats van dat het pas bij duizenden certificaten wordt ontdekt. ​​Om te zien hoe uw uitgifteproces er momenteel voor staat, kunt u contact opnemen met Encryption Consulting voor een beoordeling van certificaatdetectie en uitgiftebeheer.

Beslissings- en checklisttabel per gebruiksscenario

Gebruik deze tabel om uw situatie te koppelen aan de aanbevolen beheersmaatregel, wie deze beheersmaatregel beheert en hoe een succesvol resultaat eruitziet.

Use Case	Aanbeveling	Operationeel eigenaar	Verwacht resultaat
Nieuwe CA of profiel wordt live gezet	Lint-vertegenwoordigerscertificaten van het profiel voordat deze in grote hoeveelheden worden uitgegeven.	PKI-team	Een profielfout wordt ontdekt bij het eerste certificaat, niet pas nadat er duizenden zijn uitgegeven.
Grote aantallen openbare TLS-uitgiften volgens het 200/100/47-dagenschema.	Voer vóór elke uitgifte een linting-controle uit als een fail-closed gate.	PKI-team / Platform-DevOps	Er wordt geen niet-conform certificaat ondertekend, waardoor de 24-uurs herroepingsperiode nooit ingaat.
Niet-webcertificaattypen, waaronder S/MIME- en privé-PKI-profielen.	Voer pkilint uit naast zlint voor profielbewuste dekking.	PKI-team	Profielspecifieke regels die een op web gerichte linter alleen zou missen, worden nog steeds opgevangen.
CI/CD- of geautomatiseerde uitgiftepipelines	Beschouw linting als een controle tijdens het bouwproces, op dezelfde manier als code wordt gescand op beveiliging.	DevSecOps	Een certificaat dat de linting niet doorstaat, zorgt ervoor dat de build mislukt voordat deze de productieomgeving bereikt.
Audit- of compliance-voorbereiding	Bewaar de resultaten van de pluizenanalyse en de inventarisgegevens als bewijsmateriaal.	Naleving/Audit	Auditklaar bewijs van naleving van de basisvereisten, zonder handmatig gezoek.
Noodplan voor massale intrekking van intrekkingen	Oefen het identificeren van de reikwijdte, het melden en het opnieuw uitgeven binnen 24 uur.	CISO / Leiderschap op het gebied van beveiliging	Een restincident is een afgebakende werklijst en geen openbaar incident.

Eigenaar- en actiematrix per team

Team	Verantwoordelijkheid	Belangrijkste actie
PKI-team	Beheert het uitgifteproces, de profielen en de controle voorafgaand aan de uitgifte.	Dwing een fail-closed lint-gate af bij elke uitgave en controleer elk profiel met een linter voordat het live gaat.
Beveiligingsteam	Eigenaren die bevestigen dat lintingfouten de poort niet kunnen omzeilen en inzicht hebben in de impact van de intrekking	Controleer de linter-bevindingen bij elke profielwijziging en bevestig dat geen enkel uitgiftepad de gate overslaat.
Platform-/DevOps-team	Verantwoordelijk voor de integratie van bedrading in CI/CD- en geautomatiseerde uitgifteprocessen.	De build mislukt als een te ondertekenen certificaat de linting niet doorstaat.
Compliance-/auditteam	Beschikt over bewijs dat de uitgifte voldoet aan de basisvereisten en profielregels.	Bewaar de gegevens over pluizen en inventarisatie als bewijsmateriaal voor elke auditcyclus.

Wat te doen Volgende

• PKI-teams: Bevestig dat zowel zlint als pkilint vandaag als een fail-closed gate draaien en markeer elk profiel dat sinds de laatste wijziging niet is gecontroleerd.
• Beveiligingsteams: Bevestig dat geen enkele uitgifteprocedure, inclusief nood- of handmatige uitgifte, de pluizencontrole kan omzeilen.
• Platformteams: Valideer dat CI/CD-pipelines de build laten mislukken wanneer een certificaat de linting niet doorstaat, in plaats van alleen een waarschuwing te loggen.
• Nalevingsteams: Zorg ervoor dat uw volgende audit de inventaris- en voorraadadministratie als bewijsmateriaal kan tonen, en niet alleen een beleidsverklaring.

Gerelateerde artikelen van Encryption Consulting

• Betere beveiliging met TLS-certificaten met een geldigheidsduur van 47 dagen vanaf 2029. Dit omvat het volledige validatieproces van CA/Browser Forum waarnaar in dit bericht wordt verwezen.
• CBOM: Van inventaris naar intelligentie Dit artikel behandelt de transformatie van cryptografische ontdekking tot een doorlopend programma dat verder gaat dan certificaten.
• PQC Centrum van Uitmuntendheid Dit artikel beschrijft hoe de migratie na de kwantumovergang gepland kan worden, in combinatie met certificaatbeheerwerkzaamheden zoals deze.

Conclusie

Een certificaat is per definitie onvergeeflijk, en de regels die erop van toepassing zijn, gaan gepaard met een intrekkingstermijn van enkele uren. Naarmate de geldigheidsduur korter wordt en het uitgiftevolume tot en met 2026 en daarna toeneemt, stijgt de kans dat een onjuist profiel in productie wordt genomen, en daarmee ook het risico op een massale intrekking zoals die al heeft geleid tot 83,000 intrekkingen van certificaten, rechtszaken van klanten en een gebrek aan vertrouwen in een hele certificeringsinstantie. Controle vóór uitgifte met pkilint en zlint is de controle die voorkomt dat een certificaat met een defect profiel ooit wordt ondertekend. Het is goedkoop, automatiseerbaar en een vangnet dat een niet-conform certificaat blokkeert in plaats van een certificaat te produceren dat later moet worden ingetrokken.

Controleer de profielen vóór ondertekening; gebruik meerdere linters; controleer elk profiel voordat het op grote schaal wordt uitgegeven; en gebruik linting na uitgifte alleen als vangnet. Combineer deze controle met geautomatiseerd levenscyclusbeheer en een cryptografische inventaris , zodat eventuele resterende incidenten binnen de gestelde termijn worden ingedamd in plaats van te escaleren tot een storing. Het doel is een pipeline waarin een onjuist profiel niet kan worden ondertekend, en de zeldzame uitzondering een ingedamde werklijst is in plaats van een openbaar incident. De kosten van een linter in de pipeline zijn minimaal; de kosten van de massale intrekking die het voorkomt, zijn dat niet.

Deze handleiding, die dient als uitleg van de werkwijze en de tools, wordt elke zes maanden herzien en direct wanneer het CA/Browser Forum een ​​nieuwe stemming goedkeurt die van invloed is op de geldigheid van certificaten, of wanneer zlint of pkilint een belangrijke wijziging in de regels doorvoert.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit de certificaatcontrole vóór uitgifte met pkilint en zlint?

Een lintingcontrole vóór uitgifte controleert een certificaat aan de hand van RFC 5280, de CA/Browser Forum Baseline Requirements en de toepasselijke profielregels voordat het wordt ondertekend. Hierdoor wordt een defect geblokkeerd in plaats van dat er na 24 uur een massale intrekking plaatsvindt. Het uitvoeren van zowel zlint als pkilint als een fail-closed gate bij elke uitgifte, en het linten van elk profiel vóór uitgifte op grote schaal, is de standaardprocedure om dit te voorkomen.

Waarom is dit belangrijk voor het beheer van de levenscyclus van bedrijfscertificaten?

Een enkel onjuist profiel kan zich verspreiden naar alle certificaten die het uitgeeft, en sectie 4.9.1.1 van de basisvereisten geeft slechts 24 uur de tijd om een ​​certificaat in te trekken zodra een detecteerbaar defect wordt ontdekt. ​​De intrekking van 83,267 certificaten door DigiCert en het verlies van het vertrouwen van Chrome in Entrust zijn beide terug te voeren op profiel- en validatiedefecten die juist door linting vóór de uitgifte moeten worden opgespoord.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

PKI-teams beheren de uitgiftepipeline en de profielen waar defecten ontstaan, en zijn primair verantwoordelijk voor de linting-controle vóór de uitgifte. DevSecOps-teams zorgen ervoor dat deze controle wordt geïntegreerd in CI/CD-pipelines als een controle tijdens het bouwproces; CISO's dragen de gevolgen van een massale intrekking; en compliance- en auditteams vertrouwen op linting als gedocumenteerd, herhaalbaar bewijs van naleving van de basisvereisten.

Welke risico's nemen toe als dit handmatig wordt afgehandeld?

Zonder een geautomatiseerd, foutafsluitend linting-systeem kan een defect profiel massaal certificaten uitgeven voordat iemand het merkt, waardoor een eenmalige configuratiefout kan uitgroeien tot een massale intrekking. Handmatige controle maakt het bovendien lastiger om de omvang van het probleem snel vast te stellen zodra een defect is gevonden, en dat is precies het logistieke probleem dat de intrekking van DigiCert in 2024 bemoeilijkte.

Hoe vermindert automatisering het risico op certificaatuitval?

Geautomatiseerde controle voorafgaand aan de uitgifte blokkeert een niet-conform certificaat voordat het wordt ondertekend, zodat er niets onbetrouwbaars in productie komt en de 24-uurs intrekkingstermijn nooit ingaat. Door deze controle te combineren met geautomatiseerd certificaatlevenscyclusbeheer en een gecentraliseerde inventaris, wordt een eventuele intrekking binnen enkele minuten voltooid, in plaats van de dagen die sommige DigiCert-klanten zonder geautomatiseerde verlenging nodig hadden.

Welke statistieken moeten teams bijhouden na de implementatie?

Houd bij hoeveel uitgiften de gecombineerde zlint- en pkilint-controle in één keer doorstaan, hoeveel profielen vóór elke livegang gecontroleerd zijn, hoeveel tijd het kost om eventuele fouten die vóór de uitgifte zijn gevonden te corrigeren, en welke bevindingen er na de uitgifte zijn geconstateerd die vóór de uitgifte hadden moeten worden opgemerkt. Rapporteer deze gegevens samen met de dekkingsgraad van de certificaatvoorraad per kwartaal.

Hoe hangt dit samen met de 47-daagse TLS-certificaatgereedheid?

Het voorstel SC-081v3 van het CA/Browser Forum verlengt de maximale geldigheidsduur van openbare TLS-certificaten van 200 dagen (maart 2026) naar 100 dagen (maart 2027) naar 47 dagen (maart 2029). Dit betekent een verachtvoudige verhoging van de vernieuwingsfrequentie, waardoor jaarlijks veel meer certificaten dezelfde profiellogica doorlopen. Door deze volumetoename wordt linting vóór uitgifte, waarbij een profielfout al bij het eerste certificaat wordt opgespoord in plaats van pas na duizenden certificaten, een operationele noodzaak in plaats van een optie.

Hoe moet dit worden aangepakt in multi-cloud- of hybride PKI-omgevingen?

Pas dezelfde linting-gateway vóór uitgifte toe, met behulp van zowel zlint als pkilint, consistent op alle CA-, cloud- en on-premises uitgiftepaden, in plaats van deze in één omgeving af te dwingen en in een andere ongecontroleerd te laten. Een gedeeltelijke uitrol laat precies de blinde vlek op profielniveau achter die linting vóór uitgifte moet dichten, alleen beperkt tot de omgeving die minder prioriteit heeft gekregen.