Co-auteur: Jeremy Rowley

De gemiddelde internetgebruiker realiseert zich waarschijnlijk niet hoeveel werk er achter de schermen gebeurt om de digitale wereld veilig te houden. Digitale certificaten die worden uitgegeven door certificeringsinstanties zorgen ervoor dat websites, e-mails, servers en software kunnen worden vertrouwd. Die certificeringsinstanties worden door normeringsinstanties zoals het CA/B Forum (Certificate Authority/Browser Forum) als betrouwbaar beschouwd. 

Als gevolg van bijvoorbeeld een menselijke fout of een bug kan het soms voorkomen dat de uitgegeven certificaten niet voldoen aan de strenge compliance-eisen die worden gesteld door de beheerders van de zogeheten 'root stores'. Als dit gebeurt, wordt er van de certificeringsinstantie verwacht dat deze inzicht geeft in wat er is misgegaan, de certificaten intrekt en zorgt dat de community kan leren van de fout. 

Maar zoals we hebben kunnen zien bij het verlies van vertrouwen in Entrust-certificaten door Google Chrome, kunnen de gevolgen van het niet tijdig herstellen van de schade enorm zijn, zowel voor de certificeringsinstanties als voor hun klanten. 

Waarom wordt Entrust niet meer vertrouwd door Google?

In juni 2024 maakte het beveiligingsteam van Google Chrome bekend dat vanaf 31 oktober 2024 door Entrust uitgegeven TLS-certificaten niet meer worden vertrouwd. Een paar maanden daarvoor had Entrust toegegeven dat het bedrijf ruim 26.000 EV TLS-certificaten onjuist had uitgegeven.

Volgens de Baseline Requirements van het CA/B Forum is de deadline voor het intrekken van onjuist uitgegeven certificaten heel kort; afhankelijk van de aard van het probleem moet dat binnen 24 uur of 5 dagen worden gedaan. Meestal kan een certificeringsinstantie een dergelijk probleem oplossen met minimale gevolgen voor organisaties – maar Entrust deed niets om de betreffende certificaten in te trekken of te vervangen.  

De risico's van nietsdoen zijn uitval bij organisaties, onzekerheid over de status van de certificeringsinstantie en het verlies van vertrouwen van klanten. En voor een certificeringsinstantie zoals Entrust, die naliet om de verkeerd uitgegeven certificaten in te trekken of te vervangen, kan dit betekenen dat webbrowsers de uitgever niet langer vertrouwen, zoals Google dat nu heeft gedaan.

Onderbrekingen als gevolg van onjuist uitgegeven certificaten voorkomen

Bugs in software zijn vrij gebruikelijk, dus onjuiste uitgiftes kunnen zelfs een bedrijf met zeer geavanceerde procedures voor softwareontwikkeling overkomen. En als dit gebeurt, moet de certificeringsinstantie er alles aan doen om uit te vinden waar de fout is opgetreden en ervoor te zorgen dat dat niet nogmaals kan gebeuren.

In 2023 ontdekte DigiCert dat 300 certificaten die waren uitgegeven aan een grote hardwarefabrikant niet voldeden aan de strenge profielvereisten van de Baseline Requirements van het CA/B Forum. Volgens deze vereisten hadden we vijf dagen om de certificaten in te trekken en compliance met de normen te waarborgen; normen waar alle certificeringsinstanties zich aan houden als openbaar vertrouwde instantie.

Er was alleen één probleem: Uit overleg met de klant bleek dat het intrekken van de certificaten binnen vijf dagen zou leiden tot omvangrijke verstoringen in kritieke systemen, met mogelijke beveiligingsproblemen bij consumenten tot gevolg. We werkten nauw samen met de fabrikant, en kwamen tot de conclusie dat het een maand zou duren om de certificaten te vervangen.

Het niet naleven van de regels van het CA/B Forum was geen optie. Maar tegelijkertijd konden de certificaten niet worden ingetrokken zonder dat er vervangende, op de juiste manier uitgegeven certificaten waren geleverd. We hebben druk overleg gevoerd met de community en dag en nacht samengewerkt met de klant om de nieuwe certificaten binnen de tijd te implementeren. 

Het was een behoorlijk stressvolle tijd voor alle betrokkenen. Maar doordat we goed konden nadenken over wat er was misgegaan, heeft onze klant nu maatregelen kunnen nemen die voorkomen dat onjuist uitgegeven certificaten een blijvend probleem worden.

Het advies geldt voor alle organisaties die vertrouwen op certificaten voor hun veiligheid:

1. Kies waar van toepassing voor intern vertrouwde certificaten.

De normen van CA/B Forum gelden alleen voor openbaar vertrouwde certificaten. Voor intern vertrouwde certificaten geldt geen intrekkingsdeadline van vijf dagen. Bij de hardwarefabrikant uit het voorbeeld hierboven leidde het gebruik van openbaar vertrouwde certificaten op apparaten die dat helemaal niet nodig hadden (verbonden IoT-apparaten in dit geval) tot onnodige problemen.

Ons advies luidt dan ook: Evalueer de manier waarop u certificaten gebruikt en sluit het risico van onderbrekingen door intrekking uit door openbaar vertrouwde certificaten te vervangen door intern vertrouwde certificaten als die afdoende zijn.  

Hieronder staan enkele veelvoorkomende gebruiksscenario's voor interne vertrouwde certificaten:

• Verbonden IoT-apparaten: Deze apparaten gebruiken certificaten uitsluitend voor het authenticeren van verbindingen met gateways, servers, applicaties en andere apparaten. Die verbindingen worden meestal tot stand gebracht via privénetwerken, waardoor openbaar vertrouwen niet noodzakelijk is.
• Interne apps en websites: Een bedrijfsintranet dat niet openbaar toegankelijk is, vereist ook geen openbaar vertrouwen.
• Communicatie tussen bedrijven: Partnerbedrijven kunnen de noodzaak van openbaar vertrouwen omzeilen door te zorgen dat hun systemen elkaars interne certificaten accepteren.
• VPN's: Met interne certificaten voor client-serverauthenticatie zorgt u ervoor dat alleen vertrouwde apparaten verbinding kunnen maken met het bedrijfs-VPN.

Daarnaast adviseren we om uw certificaten automatisch te controleren op compliance met pkilint, de gratis open-source certificaatlinter van DigiCert.

2. Implementeer een complete oplossing voor certificaatbeheer.

In veel bedrijven worden nog altijd spreadsheets gebruikt voor het handmatig bijhouden van certificaten. Met een CLM-oplossing voor het levenscyclusbeheer van certificaten is het veel eenvoudiger om de deadline van vijf dagen van het CA/B Forum te halen. Zonder zo'n oplossing is het vervangen van onjuist uitgegeven certificaten een arbeidsintensief handmatig proces, dat misschien wel weken in beslag kan nemen.

Een goed voorbeeld van een uitgebreide oplossing voor levenscyclusbeheer van certificaten is DigiCert Trust Lifecycle Manager, waarmee u beschikt over:

• Discovery van PKI-certificaten
• Een centrale opslagruimte voor al uw openbare en interne certificaten
• Gedetailleerde informatie en beheermogelijkheden
• Meldingen ter voorkoming van het verlopen van certificaten
• Herstel van kwetsbaarheden

Samenwerken met een certificeringsinstantie die digitaal vertrouwen voorop stelt

Het digitaal vertrouwen waar we het zo vaak over hebben bij DigiCert is geen abstract idee, maar een objectief en meetbaar gegeven. De websites en digitale producten van organisaties zijn veilig dankzij het gebruik van betrouwbare certificaten – en anders niet. Certificeringsinstanties zijn betrouwbaar omdat ze zich houden aan de normen van onder andere het CA/B Forum – en anders niet.

Wanneer een certificeringsinstantie toezegt deel uit te maken van een vertrouwenscommunity, wordt zijn betrouwbaarheid gemeten aan de hand van zijn transparantie en zijn bereidheid zich aan de regels te houden. Op zichzelf leidt een verkeerde uitgifte niet automatisch tot verlies van vertrouwen. Wat telt zijn de reden voor de verkeerde uitgifte, wat de certificeringsinstantie leert van de situatie en hoe er wordt omgegaan met het incident.

De nieuwste ontwikkelingen op het gebied van digitaal vertrouwen

Wilt u meer weten over onderwerpen zoals levenscyclusbeheer van certificaten, digitaal vertrouwen en de oplossingen voor digitaal vertrouwen van DigiCert? Abonneer u dan op het DigiCert-blog zodat u niets hoeft te missen.