Uitleg van CRL-redencodes: Certificaatintrekking in PKI

Het intrekken van certificaten is een van de belangrijkste, maar vaak over het hoofd geziene onderdelen van Public Key Infrastructure (PKI). Wanneer een certificaat niet langer betrouwbaar is vóór de vervaldatum, trekt de uitgevende certificeringsinstantie (CA) het certificaat in en publiceert deze status via mechanismen zoals Certificate Revocation Lists (CRL's) of het Online Certificate Status Protocol (OCSP).

De intrekkingsstatus geeft vertrouwende partijen aan dat een certificaat niet langer te vertrouwen is. Een redencode voor intrekking voegt context toe door uit te leggen waarom, en die informatie wordt meegenomen in de CRLReason-extensie zoals gedefinieerd in RFC 5280.

Inzicht in CRL-reden codes helpt PKI-beheerders, beveiligingsteams, auditors en compliance-teams onderscheid te maken tussen een routinegebeurtenis in de certificaatlevenscyclus en een echt beveiligingsincident. Deze blog behandelt wat de codes zijn, de waarden die RFC 5280 definieert, hoe ze verschillen van ReasonFlags, hoe het openbare TLS-beleid ze beperkt en de werkwijzen die ervoor zorgen dat intrekkingsgegevens bruikbaar blijven.

Wat zijn CRL-redencodes?

Een CRL-redencode is een gestandaardiseerde waarde die in een individuele CRL-vermelding kan worden opgenomen om aan te geven waarom een ​​certificaat is ingetrokken. RFC 5280 definieert CRLReason als een optionele CRL-vermeldingsuitbreiding die is gekoppeld aan een ingetrokken certificaat, zodat de CA niet alleen een certificaat als ongeldig kan markeren, maar ook de reden daarachter kan vastleggen.

Dat onderscheid is operationeel gezien van groot belang. Een certificaat dat wordt ingetrokken omdat het is vervangen door een nieuwer certificaat, vereist een heel andere reactie dan een certificaat dat wordt ingetrokken omdat de privésleutel ervan is gecompromitteerd. Omdat de codes een gemeenschappelijke standaard volgen, kunnen platforms voor certificaatlevenscyclusbeheer , monitoringsystemen en beveiligingsworkflows intrekkingsgebeurtenissen consistent verwerken in verschillende PKI-omgevingen.

CRL-redencodes gedefinieerd in RFC 5280

RFC 5280 definieert de CRLReason-waarden als een ASN.1-opsomming. De numerieke code is van belang, omdat deze daadwerkelijk in de CRL-vermelding van het certificaat verschijnt.

Code	Reden	Betekenis
0	gespecificeerd	Er wordt geen specifieke reden gegeven.
1	sleutelCompromise	Het is bekend of vermoed dat de privésleutel van het certificaat is gecompromitteerd.
2	cACompromis	Het is bekend of er bestaat een vermoeden dat de privésleutel van de uitgevende certificeringsinstantie is gecompromitteerd.
3	affiliatieGewijzigd	De naam of affiliatiegegevens van de betrokkene zijn gewijzigd.
4	vervangen	Het certificaat is vervangen door een nieuwer certificaat.
5	beëindiging van de operatie	Het certificaat is niet langer nodig voor het oorspronkelijke doel.
6	certificaatHold	Tijdelijke schorsing van het certificaat
8	verwijderUitCRL	Een certificaat dat eerder in de wacht stond, is niet langer ingetrokken; wordt alleen gebruikt in delta CRL's.
9	privilege ingetrokken	Een in het certificaat opgenomen voorrecht is ingetrokken.
10	een compromis	Er is bekend of er bestaat een vermoeden dat een Attribute Authority-sleutel is gecompromitteerd.

Waarde 7 is opzettelijk gereserveerd en wordt niet gebruikt, vandaar dat de opsomming van 6 naar 8 gaat. Het overslaan van deze codes met één, door te vergeten dat 7 ontbreekt, is een bekende bron van CRL-fouten in de praktijk, dus het is belangrijk om rekening te houden met deze lacune. Niet elke CA gebruikt elke code, en openbare TLS-ecosystemen beperken welke redenen zijn toegestaan, zoals hieronder wordt uitgelegd.

Waarom de redenen voor intrekking ertoe doen

De intrekkingsstatus geeft aan of een certificaat nog steeds betrouwbaar is. De redenen voor intrekking geven aan waarom het certificaat niet langer betrouwbaar is. Het verschil is vergelijkbaar met het omruilen van een verlopen creditcard voor een nieuwe en het melden van een gestolen kaart: in beide gevallen wordt de oude kaart ongeldig verklaard, maar alleen in het laatste geval wordt fraude geconstateerd en is een onmiddellijke reactie vereist.

Als een certificaat wordt ingetrokken vanwege een keyCompromise-fout, moeten beveiligingsteams doorgaans onderzoek doen naar mogelijke blootstelling van inloggegevens, de getroffen sleutels vernieuwen en beoordelen of systemen zijn gehackt . Een certificaat dat wordt ingetrokken omdat het is vervangen, daarentegen, weerspiegelt vaak normaal levenscyclusbeheer, zoals het vervangen van een verlopend certificaat door een vernieuwd certificaat. Deze context verbetert de incidentrespons, compliance-rapportage, auditonderzoeken, levenscyclusautomatisering en oorzaakanalyse.

Organisaties met grote certificaatinventarissen vertrouwen hierop om prioriteit te geven aan herstelwerkzaamheden en operationele ruis te verminderen. In de praktijk is nauwkeurige intrekkingsmetadata essentieel voor een meetbaar en controleerbaar certificaatlevenscyclusprogramma.

CRLReason en ReasonFlags zijn niet hetzelfde.

Een van de meest voorkomende misvattingen over PKI is dat CRLReason en ReasonFlags als hetzelfde worden beschouwd. Dat zijn ze niet.

CRLReason is de reden voor intrekking die is gekoppeld aan een specifiek ingetrokken certificaat in een CRL, en legt uit waarom dat specifieke certificaat is ingetrokken. ReasonFlags is een BIT-STRING die wordt gebruikt in de CRL Distribution Points -extensie om aan te geven welke categorieën van intrekkingsredenen een bepaald distributiepunt omvat.

Bestanddeel	Doel
CRLReason	Legt uit waarom een ​​specifiek certificaat is ingetrokken.
Redenvlaggen	Geeft aan welke redenen voor intrekking een CRL-distributiepunt dekt.

In de praktijk beschrijft CRLReason de intrekking zelf, terwijl ReasonFlags certificaatgebruikende applicaties en systemen helpt bepalen waar de relevante intrekkingsinformatie te vinden is. Dit onderscheid is belangrijk bij het oplossen van validatieproblemen, het ontwerpen van een PKI of het beoordelen van een certificaatprofiel. De bredere rol van vertrouwde uitgevers in deze keten wordt behandeld in het overzicht van de certificeringsinstantie van Encryption Consulting.

Hoe CRL-redencodes TLS-bewerkingen beïnvloeden

Hoewel RFC 5280 de volledige set codes definieert, voegen TLS- ecosystemen in de praktijk daar bovenop nog beleid toe. Openbaar vertrouwde certificeringsinstanties (CA's) werken volgens de basisvereisten en het beleid van het rootprogramma van de browser, en die regels beperken de redenen waarom openbaar vertrouwde certificaten zijn toegestaan.

Twee beperkingen zijn het vermelden waard. De Baseline Requirements (BR §4.9.1.1) stellen dat voor een TLS-certificaat de CRLReason niet ongespecificeerd (0) mag zijn; als er geen specifieke reden van toepassing is, laat de CA de reasonCode-extensie volledig weg. Ze verbieden ook certificateHold (6) voor TLS-certificaten, en verschillende codes zoals cACompromise, removeFromCRL en aACompromise zijn helemaal niet van toepassing op TLS-certificaten voor eindgebruikers. In de praktijk blijven er dus vijf toegestane redencodes over:

• Een keyCompromise-melding duidt op een beveiligingsincident en leidt doorgaans tot onmiddellijke actie.
• 'Vervangen' duidt op een routinematige vervanging van het certificaat.
• cessionOfOperation verschijnt wanneer een service of applicatie wordt stopgezet.
• affiliationChanged is van toepassing wanneer het eigenaarschap of de bevoegdheden van een organisatie veranderen.
• De certificeringsinstantie gebruikt privilegeWithdrawn wanneer er bewijs is van misbruik van het certificaat of een wezenlijke schending van de abonnementsvoorwaarden.

Moderne intrekking van certificaten combineert CRL's, OCSP , monitoring van certificaattransparantie en steeds kortere geldigheidsduur van certificaten. In april 2025 heeft het CA/Browser Forum Ballot SC-081v3 aangenomen , waarmee de maximale geldigheidsduur van publiekelijk vertrouwde TLS-certificaten geleidelijk wordt verlaagd van 398 dagen naar 47 dagen op 15 maart 2029. De eerste limiet van 200 dagen ging in op 15 maart 2026, met een verdere verlaging naar 100 dagen op 15 maart 2027 en een definitieve limiet van 47 dagen op 15 maart 2029.

In dezelfde periode wordt het venster voor hergebruik van domeinvalidatiegegevens teruggebracht tot 10 dagen. Deze veranderingen maken geautomatiseerd certificaatlevenscyclusbeheer essentieel in plaats van optioneel. De manier waarop browsers omgaan met intrekking verschilt, maar accurate intrekkingsinformatie blijft cruciaal voor PKI-vertrouwen en is afhankelijk van dezelfde discipline die gedurende de gehele levensduur van TLS-certificaten wordt toegepast.

Veelgemaakte fouten en uitdagingen in de praktijk

Veel organisaties gebruiken standaard 'niet gespecificeerd' voor bijna elke intrekking. Dat is technisch gezien geldig voor private PKI, maar het ontneemt de context die onderzoek, rapportage en automatisering effectief maakt, en voor publieke TLS is het zelfs niet toegestaan.

Een ander veelvoorkomend probleem is het verkeerd begrijpen van certificateHold. Het is ontworpen voor tijdelijke opschorting in plaats van permanente intrekking, en hoewel RFC 5280 het definieert, komt het niet vaak voor in moderne omgevingen en is het niet toegestaan ​​voor openbare TLS. Teams verwarren CRLReason ook met ReasonFlags, wat leidt tot verkeerde aannames over hoe intrekkingsinformatie wordt verspreid en verwerkt.

In gereguleerde omgevingen leidt inconsistent gebruik van redencodes tot auditproblemen, omdat een onderzoeker niet kan vaststellen of een certificaat is ingetrokken vanwege een beveiligingsincident of een routinematige administratieve wijziging.

Best practices voor beveiliging

Intrekking van certificaten moet worden beschouwd als een essentieel onderdeel van het beheer van de levenscyclus van certificaten, en niet als een loutere afvinklijst. Bij het intrekken van certificaten zijn een paar gewoontes belangrijk om de gegevens betrouwbaar en bruikbaar te houden.

• Gebruik de meest accurate reden die beschikbaar is, en laat bij openbare TLS de reasonCode weg in plaats van de standaardwaarde 'niet gespecificeerd' te gebruiken.
• Leg de procedures voor intrekkingen in verband met een inbreuk vast, zodat keyCompromise consistent en snel kan worden toegepast.
• Houd een auditlogboek bij voor elke intrekkingactie.
• Bescherm CA-ondertekeningssleutels met sterke beveiligingsmaatregelen, met behulp van een FIPS 140-3 Niveau 3 gevalideerd Hardwarebeveiligingsmodule waar nodig. De sleutelbeheer- en HSM-diensten van Encryption Consulting kunnen organisaties helpen bij het selecteren, implementeren en beheren van de juiste HSM-infrastructuur voor hun PKI-omgeving.
• Houd de publicatie van CRL en OCSP in de gaten, zodat informatie over intrekking beschikbaar blijft voor de partijen die erop vertrouwen.

Nauwkeurige metadata over intrekking versterkt zowel de beveiligingsprocessen als de rapportage over naleving van regelgeving, en helpt teams sneller te reageren wanneer zich een incident met betrekking tot certificaten voordoet.

Hoe encryptieconsultancy kan helpen

Het beheren van certificaatintrekking binnen een grote omgeving wordt complexer wanneer een organisatie meerdere certificeringsinstanties, certificaattypen en vertrouwensdomeinen gebruikt. Encryption Consulting helpt bij het ontwerpen, implementeren en beheren van schaalbare PKI via haar Enterprise PKI Services . Deze services omvatten certificaatlevenscyclusbeheer, intrekkingsworkflows, CA-architectuurbeoordelingen, compliance-afstemming en operationele best practices, zodat intrekking zowel de beveiligings- als de bedrijfsdoelstellingen ondersteunt.

CertSecure Manager biedt voor de dagelijkse werkzaamheden een gecentraliseerd overzicht van certificaatinventarissen, vervaldatums, geautomatiseerde vernieuwingsworkflows en de status van intrekkings-endpoints (CRL en OCSP) binnen de gehele organisatie. Naarmate de geldigheidsperioden van publiekelijk vertrouwde certificaten steeds korter worden, richting 47 dagen, maakt deze automatisering het verschil tussen routinematige vernieuwingen en vermijdbare storingen.

Of het nu gaat om het moderniseren van een bestaande PKI of het bouwen van een nieuwe vertrouwensarchitectuur, Encryption Consulting kan helpen bij het opzetten van intrekkingsprocessen die veilig, controleerbaar en operationeel efficiënt zijn.

Conclusie

CRL-reden codes lijken misschien een klein detail, maar ze verklaren waarom certificaten worden ingetrokken en hoe een organisatie daarop moet reageren. Het belangrijkste onderscheid om te onthouden is dat CRLReason aangeeft waarom een ​​specifiek certificaat is ingetrokken, terwijl ReasonFlags aangeeft welke intrekkingsredenen een CRL-distributiepunt dekt. ​​Het verwarren van de twee leidt tot fouten in PKI-ontwerp, probleemoplossing en beleid.

Naarmate organisaties meer aspecten van de certificaatlevenscyclus automatiseren, wordt nauwkeurige intrekkingsinformatie steeds waardevoller voor beveiligingsoperaties, audits, compliance en incidentrespons. Goed toegepaste CRL-reden codes transformeren intrekking van een simpele statuscontrole tot een betekenisvol onderdeel van vertrouwensbeheer. Een praktische eerste stap is het standaardiseren van de reden codes die uw teams gebruiken en te controleren of deze overeenkomen met zowel RFC 5280 als het beleid dat van toepassing is op uw openbare certificaten.