De implicaties van Google's actie tegen Entrust en wat dit voor u betekent

Kort antwoord: Google Chrome vertrouwt sinds 11 november 2024 geen nieuwe Entrust TLS-certificaten meer, na jarenlange aantoonbare problemen met de naleving van de certificeringsnormen. Certificaten die vóór die datum zijn uitgegeven, blijven geldig tot hun vervaldatum, maar elke organisatie die nog steeds Entrust-certificaten gebruikt, heeft een migratieplan nodig, ondersteund door geautomatiseerd certificaatbeheer , om waarschuwingen en storingen in de browser te voorkomen.

Bijna tien jaar lang was Entrust een van de vertrouwde root-certificaatinstanties binnen het Chrome Root Program. Dat veranderde in juni 2024, toen het Chrome Security Team van Google aankondigde dat het geen vertrouwen meer had in Entrusts vermogen om te voldoen aan het beleid van het Chrome Root Program en de basisvereisten van het CA/Browser Forum. Deze beslissing trof elke organisatie die gebruikmaakte van openbare TLS-certificaten uitgegeven door Entrust en schiep een precedent dat Google, Apple en Mozilla sindsdien ook hebben toegepast op andere certificaatinstanties. 

Samenvatting

Google Chrome is op 11 november 2024 gestopt met het vertrouwen op nieuwe Entrust TLS-certificaten, na jarenlange gedocumenteerde nalevingsproblemen. Apple en Mozilla volgden diezelfde maand met hun eigen einddata. Entrust heeft sindsdien zijn activiteiten op het gebied van openbare certificaten verkocht aan Sectigo. Hetzelfde handhavingspatroon herhaalde zich in 2025 tegen Chunghwa Telecom en Netlock, en het sluit aan bij de gefaseerde verlaging van de maximale TLS-validiteit naar 47 dagen door het CA/Browser Forum tegen maart 2029. Deze handleiding begeleidt PKI-, beveiligings-, platform- en compliance-teams door de beleidstijdlijn, de impact per rol en deadline, een checklist voor gereedheid en een migratieplan, zodat een toekomstige situatie waarin het vertrouwen in een certificaat wordt ingetrokken of een overgang naar een andere geldigheidsperiode een routine-update wordt in plaats van een noodsituatie.

Key Takeaways

• Chrome is gestopt met het vertrouwen van nieuwe Entrust TLS-certificaten met SCT's die na 11 november 2024 zijn gedateerd; Apple en Mozilla hanteerden later die maand hun eigen uiterste data.
• Entrust heeft zijn activiteiten op het gebied van openbare certificaten inmiddels verkocht aan Sectigo, maar certificaten die al onder de oude Entrust-root zijn uitgegeven, zijn niet automatisch beschermd tegen het gebrek aan vertrouwen.
• Hetzelfde handhavingspatroon herhaalde zich in augustus 2025, toen Google Chunghwa Telecom en Netlock wantrouwde vanwege soortgelijke tekortkomingen in de naleving van de regels. Dit toont aan dat het om een ​​terugkerend risico gaat en niet om een ​​geïsoleerd incident.
• Handmatig bijhouden van certificaten is een bewezen risico: uit de Trust Pulse Survey van DigiCert uit juli 2025 bleek dat 45% van de bedrijven het afgelopen jaar te maken had met uitval als gevolg van certificaatproblemen, en dat 37.5% de storingen specifiek kon herleiden tot verlopen certificaten.
• Het wantrouwen jegens Entrust en de gefaseerde overstap van het CA/Browser Forum naar een maximale certificaatvaliditeit van 47 dagen tegen maart 2029 wijzen beide op dezelfde oplossing: geautomatiseerde detectie, uitgifte en verlenging van certificaten in plaats van handmatige registratie in spreadsheets.

Wat betekent Googles besluit tegen Entrust?

Certificeringsinstanties zoals Entrust bestaan ​​om de identiteit van een website te garanderen voordat een browser de versleutelde verbinding vertrouwt. Browsers verlenen dat vertrouwen via rootprogramma's, en elk rootprogramma kan het intrekken wanneer een certificeringsinstantie niet aan haar verplichtingen voldoet. De actie van Google tegen Entrust was precies dat: een intrekking van het vertrouwen op rootprogrammaniveau, geen tijdelijke waarschuwing.

Waarom Google Entrust wantrouwde

De openbare toelichting van Google was gebaseerd op een patroon in plaats van op een enkel incident. Entrust was sinds 2018 onderwerp geweest van meerdere publiekelijk bekendgemaakte compliance-incidenten, waaronder vertraagde intrekkingen en herhaaldelijk niet voldoen aan de CA/Browser Forum Baseline Requirements. Mozilla's eigen incidentregistratie documenteerde een vergelijkbare geschiedenis. Wanneer een CA herhaaldelijk belooft oplossingen te implementeren maar geen meetbare vooruitgang boekt, verliezen browserrootprogramma's het vertrouwen in de uitgiftepraktijken van de CA, en Google concludeerde dat Entrust die grens had overschreden.

Wat is er gebeurd sinds november 2024?

TLS-certificaten van Entrust die waren uitgegeven met een Signed Certificate Timestamp (SCT) van na 11 november 2024, verloren het vertrouwen van Chrome. Apple paste dezelfde beperking toe vanaf 15 november 2024 en Mozilla vanaf 30 november 2024. Certificaten die vóór deze datums waren uitgegeven, bleven werken tot hun vervaldatum. Dit verzachtte de directe impact, maar creëerde ook een vals gevoel van veiligheid bij teams die aannamen dat het probleem alleen nieuwe aankopen trof. Entrust verkocht vervolgens zijn activiteiten op het gebied van openbare certificaatuitgifte aan Sectigo, waardoor het klantenbestand werd ondergebracht bij een andere certificeringsinstantie met andere operationele controles.

Google heeft Entrust niet als een eenmalige actie beschouwd. In augustus 2025 paste Chrome 139 dezelfde aanpak toe op Chunghwa Telecom en Netlock, wederom vanwege aanhoudende problemen met de naleving van de regels en een gebrek aan meetbare verbetering. De boodschap voor iedereen die afhankelijk is van een openbare CA is consistent: vertrouwen in de root-store is voorwaardelijk en kan met een opzegtermijn van ongeveer vier tot vijf maanden worden ingetrokken.

Officiële beleidsbronnen en ingangsdata

Elke deadline in dit artikel is gebaseerd op een primaire bron. Beschouw de onderstaande tabel als de referentie en controleer de bron zelf voordat u een migratiebeslissing neemt, aangezien browserrootprogramma's en CA/Browser Forum-stemmingen kunnen worden herzien.

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

Een vertrouwensbreuk of het verstrijken van een geldigheidsperiode wordt pas een zakelijk probleem wanneer het bijhouden van certificaten afhangt van iemand die de vervaldatum onthoudt. Zo werken de meeste organisaties nog steeds, en de gegevens laten zien wat hen dat kost.

De kosten van handmatig certificaatbeheer

Uit het Trust Pulse-onderzoek van DigiCert, gepubliceerd op 2 juli 2025, bleek dat bedrijven niet de certificaten zelf, maar handmatige processen de belangrijkste oorzaak van storingen zijn. Vijfenveertig procent van de respondenten had in het voorgaande jaar te maken gehad met serviceuitval als gevolg van een incident met certificaten, en 37.5% koppelde die uitval specifiek aan een verlopen certificaat, een van de meest te voorkomen storingen in de gehele certificaatlevenscyclus. Wanneer de onderliggende certificeringsinstantie (CA) ook niet langer wordt vertrouwd, zoals gebeurde met Entrust, komt elk handmatig bijgehouden certificaat van die CA in aanmerking voor noodvervanging binnen een korte tijdspanne. Dit is precies het scenario dat leidt tot uitvalkosten van zes cijfers. Certificaatdetectie is de eerste stap om dit probleem op te lossen, want je kunt niet vervangen wat je niet hebt geïnventariseerd.

Het bredere patroon: de geldigheidsduur van certificaten neemt in de hele sector af.

Het wantrouwen jegens Entrust en de verkorting van de geldigheidsduur van certificaten door het CA/Browser Forum zijn twee symptomen van dezelfde verschuiving: de industrie tolereert geen langlopende, nauwelijks gecontroleerde certificaten meer. Op 11 april 2025 heeft het CA/Browser Forum stemming SC-081v3 aangenomen, later samengevat door Sectigo, waarmee de maximale geldigheidsduur van openbare TLS-certificaten in drie fasen wordt verkort van 398 dagen naar 47 dagen.

De 47-daagse certificaatgereedheidshandleiding van Encryption Consulting doorloopt dit schema stap voor stap, maar in het kort komt het neer op dezelfde conclusie waar Entrust al op wees: certificaatlevenscyclusbeheer moet geautomatiseerd zijn, niet afhankelijk van agendaherinneringen.

Impact per rol en deadline

Het Entrust-wantrouwen en de termijn van 47 dagen hebben verschillende gevolgen, afhankelijk van welk team verantwoordelijk is voor de reactie. De onderstaande tabel geeft de verantwoordelijkheden weer, zodat er geen hiaat tussen de teams ontstaat.

Checklist voor gereedheid en migratieplan

Snelle gereedheidschecklist

• Controleer welke certificeringsinstanties uw huidige certificaatinventaris hebben uitgegeven en markeer alle certificaten die nog steeds gekoppeld zijn aan een onbetrouwbare of recent verkochte rootcertificaat.
• Identificeer alle certificaten met een geldigheidsperiode van meer dan 200 dagen; deze moeten vóór de deadline van maart 2026 worden vervangen, ongeacht wanneer ze verlopen.
• Controleer of uw platform of proces voor certificaatlevenscyclusbeheer geautomatiseerde uitgifte en verlenging op basis van ACME ondersteunt.
• Controleer of de privésleutels bij elke verlenging worden geroteerd in plaats van te worden hergebruikt voor opnieuw uitgegeven certificaten.
• Bevestig dat de validatie van domeinbeheer herhaald kan worden binnen de steeds korter wordende hergebruiksperioden van 200, vervolgens 100 en daarna 10 dagen.
• Leg voor elk certificaat het eigenaarschap vast, zodat de verantwoordelijkheid voor de verlenging niet automatisch bij degene komt te liggen die de waarschuwing voor de vervaldatum opmerkt.

Migratieroutekaart

1. Ontdek: Voer een volledige certificaatcontrole uit op openbare en interne systemen om een ​​actuele inventaris op te bouwen, inclusief certificaten uitgegeven door certificeringsinstanties die u niet langer actief gebruikt.
2. Prioriteren: Rangschik certificaten op basis van hun zakelijke relevantie en hoe dicht de uitgevende certificeringsinstantie (CA) bij een wijziging in geldigheid of vertrouwen staat, te beginnen met alles wat gekoppeld is aan Entrust of een andere recentelijk niet meer vertrouwde root.
3. PLC: Implementeer de op ACME gebaseerde uitgifte en verlenging eerst voor de certificaatgroepen met het hoogste volume en het hoogste risico, in plaats van te proberen om in één keer volledig over te schakelen.
4. Valideren: Controleer of geautomatiseerde verlengingen daadwerkelijk worden voltooid en sleutels roteren, en niet alleen gepland, voordat u ze gebruikt voor productieverkeer.
5. Monitor: Houd de certificaatstatus en aankomende wijzigingen in het CA/Browser Forum of het rootprogramma van de browser continu in de gaten, zodat de volgende beleidswijziging geen verrassing is.

Voor een stapsgewijze uitleg van hoe deze migratie er in de praktijk uitziet, laat de onderstaande video zien hoe u een overstap naar een nieuwe certificeringsinstantie kunt plannen en uitvoeren.

Hoe automatisering het risico op certificaatuitval vermindert

De meeste certificaatstoringen worden niet veroorzaakt door aanvallen. Ze komen voort uit het verlopen van een certificaat terwijl niemand de spreadsheet goed in de gaten hield. Geautomatiseerd certificaatlevenscyclusbeheer elimineert deze fout door de verlenging te koppelen aan een workflow in plaats van aan de agenda van een persoon. CertSecure Manager detecteert certificaten in cloud-, on-premises- en hybride omgevingen, geeft ze uit en verlengt ze via directe CA-integraties en ACME, en zorgt voor rotatie van de privésleutel bij elke cyclus. Hierdoor wordt een steeds korter wordende geldigheidsperiode een planningsaspect in plaats van een terugkerende noodsituatie.

Te volgen meetgegevens na implementatie

• Percentage van certificaten onder actief geautomatiseerd beheer versus handmatig bijgehouden certificaten
• Aantal incidenten of bijna-incidenten met betrekking tot certificaten per kwartaal, met een dalende trend richting nul.
• Gemiddelde tijd tussen het ontdekken van een nieuw certificaat en het volledig classificeren ervan in de inventaris.
• Succespercentage van de verlenging bij de eerste geautomatiseerde poging, zonder handmatige tussenkomst.
• De benodigde tijd om elk certificaat te vervangen dat gekoppeld is aan een enkele onbetrouwbare of gecompromitteerde CA, gerekend vanaf dag één.

Overwegingen bij multi-cloud en hybride PKI

In multi-cloud- en hybride omgevingen, waar certificaten worden uitgegeven door verschillende CA's in AWS, Azure, GCP en on-premises PKI's, vaak zonder een gedeelde inventaris, zijn veranderingen in het vertrouwen tussen certificeringsinstanties en certificaten lastiger op te vangen. Een vertrouwensbreuk zoals die bij Entrust kent geen omgevingsgrenzen: een door Entrust uitgegeven certificaat dat een interne load balancer beschermt, loopt net zoveel risico als een certificaat dat een publiek toegankelijke website beschermt. Door de ontdekking en uitgifte van certificaten in alle omgevingen te centraliseren, in plaats van de native certificaattools van elke cloud afzonderlijk te beheren, kan er binnen enkele dagen in plaats van maanden worden gereageerd op een vertrouwensbreuk of een wijziging in de geldigheidsduur. PKI-as-a-Service biedt hybride en multi-cloudorganisaties één centraal beheersysteem voor uitgifte en beleid, waardoor een wijziging op CA-niveau in één omgeving niet vereist dat het proces overal opnieuw wordt opgebouwd.

Wat te doen Volgende

Het Entrust-wantrouwen, de 47-dagentermijn voor certificaten en de bredere drang naar post-kwantumcryptografie zijn geen afzonderlijke projecten die om dezelfde budgetpost strijden. Ze zijn allemaal gebaseerd op dezelfde basis: een nauwkeurige, continu bijgewerkte inventaris van elk certificaat en cryptografisch actief in uw omgeving. PKI-, beveiligings-, platform- en compliance-teams die die inventaris eenmaal opbouwen en actueel houden, zullen de volgende CA-wantrouwensgebeurtenis of geldigheidswijziging als een routine-update beschouwen in plaats van als een noodsituatie.

Teams die nog niet zijn begonnen, zouden certificaatdetectie als de eerstvolgende stap moeten beschouwen, vóór PQC-gereedheid of crypto-agility -initiatieven die ervan uitgaan dat de inventaris al bestaat. Het PQC Center of Excellence van Encryption Consulting en CBOM Secure beginnen beide bij diezelfde detectielaag, dus het werk dat wordt verricht om het wantrouwen van Entrust weg te nemen, draagt ​​direct bij aan het werk dat nodig is voor het 47-dagenplan en voor de migratie na de quantum-update. Voor een beter begrip van hoe die inventaris een doorlopende capaciteit wordt in plaats van een eenmalig project, zie hoe een cryptografische stuklijst inventaris omzet in intelligentie.

Hoe encryptieconsultancy kan helpen

Het reageren op een CA-wantrouwingsgebeurtenis of een verkorte geldigheidsperiode begint met dezelfde ontdekkingslaag, ongeacht welke beleidswijziging de gebeurtenis triggert. Ons CertSecure Manager- platform detecteert en inventariseert certificaten in cloud-, on-premises- en hybride omgevingen en automatiseert vervolgens de uitgifte en verlenging, zodat een niet-vertrouwde root of een verkorte geldigheidsperiode een planningsdetail wordt in plaats van een noodsituatie. Voor organisaties die certificaten beheren in AWS, Azure, GCP en on-premises PKI, biedt PKI-as-a-Service dezelfde ontdekking en uitgifte via één centraal beheersysteem. Deze inventarisatie vormt ook de basis voor werkzaamheden op de lange termijn: ons PQC Center of Excellence en PQC- gereedheidsbeoordelingen bouwen voort op dezelfde ontdekkingsdiscipline, en CBOM Secure zet dit om in een complete cryptografie-lijst met materialen. Ontdek hoe een CBOM inventarisatie omzet in intelligentie en hoe certificaatautomatisering, PQC-gereedheid en CBOM met elkaar verbonden zijn.

Conclusie

Googles besluit om Entrust niet te vertrouwen, ging eigenlijk niet over Entrust zelf. Het was een demonstratie dat vertrouwen in de root-certificaatopslag actief wordt afgedwongen, en niet een referentie die certificeringsinstanties eenmalig verdienen en voor onbepaalde tijd behouden. Hetzelfde principe geldt nu voor de levensduur van certificaten zelf: de stap van het CA/Browser Forum naar een maximale geldigheidsduur van 47 dagen gaat ervan uit dat organisaties certificaten kunnen uitgeven en vernieuwen volgens een schema dat met geen enkel handmatig proces vol te houden is.

Of de volgende verstoring nu het verlies van vertrouwen door een andere certificeringsinstantie betreft, een overgangsperiode voor geldigheidscertificaten, of een migratie naar een algoritme na de introductie van kwantumtechnologie, de organisaties die er zonder problemen doorheen komen, zijn de organisaties die al precies weten welke certificaten ze hebben, wie de eigenaar ervan is en hoe die certificaten worden vervangen zonder dat iemand het hoeft op te merken.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit het rapport 'De gevolgen van Googles actie tegen Entrust en wat betekent dit voor u?'

Google Chrome is gestopt met het vertrouwen op nieuwe Entrust TLS-certificaten die na 11 november 2024 zijn uitgegeven, na jarenlange gedocumenteerde nalevingsproblemen. Certificaten die vóór die datum waren uitgegeven, bleven geldig tot de vervaldatum, maar de onderliggende les is breed toepasbaar: het vertrouwen in de rootcertificaatwinkel van browsers is voorwaardelijk en kan worden ingetrokken. Organisaties hebben daarom behoefte aan continue certificaatdetectie en geautomatiseerde vernieuwing in plaats van voor onbepaalde tijd te vertrouwen op de reputatie van één enkele certificeringsinstantie.

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

Handmatig certificaatbeheer maakt van elke wijziging in het vertrouwensniveau van een certificeringsinstantie een noodsituatie. Uit de Trust Pulse Survey van DigiCert uit juli 2025 bleek dat 45% van de bedrijven het afgelopen jaar te maken had met downtime als gevolg van certificaatproblemen, waarvan 37.5% te wijten was aan verlopen certificaten. Wanneer een vertrouwde certificeringsinstantie zoals Entrust niet langer wordt vertrouwd, komt elk certificaat van die instantie in aanmerking voor vervanging binnen een zeer kort tijdsbestek. Daarom is geautomatiseerd lifecyclemanagement belangrijker dan ooit.

Welke teams zijn verantwoordelijk voor de uitvoering van deze richtlijnen?

PKI-teams zijn verantwoordelijk voor beslissingen over root-of-trust en CA-diversificatie. Beveiligingsteams controleren de rotatie van privésleutels en bewaken verlopende certificaten in alle omgevingen. Platform- en DevOps-teams actualiseren CI/CD-pipelines om kortere vernieuwingscycli te ondersteunen via ACME-automatisering. Compliance-teams onderhouden auditklare certificaatinventarissen en volgen continu wijzigingen in beleidsbronnen van het CA/Browser Forum en browserrootprogramma's.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Handmatige verwerking vergroot het risico op onopgemerkte verlopen certificaten, dubbele of achtergebleven certificaten, inconsistente rotatie van privésleutels en vertraagde reacties op een CA-wantrouwgebeurtenis. Naarmate de geldigheidsperioden tegen maart 2029 afnemen tot 47 dagen, maakt de vereiste vernieuwingsfrequentie handmatige controle operationeel onhoudbaar, waardoor de kans op een storing als gevolg van een certificaat dat niemand actief in de gaten hield, toeneemt.

Hoe vermindert automatisering het risico op certificaatuitval?

Automatisering koppelt certificaatvernieuwing aan een workflow in plaats van dat een persoon de vervaldatum moet onthouden. Platforms zoals CertSecure Manager detecteren certificaten in cloud-, on-premises- en hybride omgevingen, geven ze uit en vernieuwen ze via directe CA-integraties en ACME, en zorgen voor rotatie van de privésleutel bij elke cyclus. Dit elimineert het punt van menselijke fouten dat de meeste certificaatgerelateerde storingen veroorzaakt.

Welke meetgegevens moeten teams bijhouden na de implementatie?

Houd het percentage certificaten bij dat actief geautomatiseerd wordt beheerd, het aantal certificaatgerelateerde incidenten per kwartaal, het slagingspercentage van de geautomatiseerde verlenging bij de eerste poging, de tijd tussen het ontdekken van een nieuw certificaat en de classificatie ervan in de inventaris, en de tijd die nodig is om elk certificaat te vervangen dat is gekoppeld aan een enkele onbetrouwbare of gecompromitteerde certificeringsinstantie.

Hoe hangt dit samen met de gereedheid van het TLS-certificaat binnen 47 dagen?

Het Entrust-wantrouwen en de 47-dagen certificaattermijn komen beide voort uit dezelfde trend in de sector: kortere certificatenlevensduur en strengere verantwoordingsplicht van certificeringsinstanties. Het voorstel SC-081v3 van het CA/Browser Forum verkort de maximale TLS-geldigheid tot 200 dagen in maart 2026, 100 dagen in maart 2027 en 47 dagen in maart 2029. Dit vereist dezelfde geautomatiseerde infrastructuur voor uitgifte en verlenging als een CA-wantrouwenssituatie.

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

In multi-cloud- en hybride omgevingen worden certificaten vaak uitgegeven door verschillende certificeringsinstanties (CA's) binnen AWS, Azure, GCP en on-premises PKI's, zonder een gedeelde inventaris. Hierdoor is het lastiger om een ​​CA-wantrouwingsgebeurtenis of een wijziging in de geldigheid te traceren. Door de ontdekking en uitgifte te centraliseren via een platform zoals PKI-as-a-Service krijgen deze omgevingen één centraal beheersysteem. Hierdoor hoeft een wijziging op CA-niveau op één plek niet te leiden tot een volledige herziening van het proces op alle andere locaties.