Notifications
Clear all
Topic starter
25/06/2026 10:33 pm
TL;DR: CA/B Forum discussions in October 2020 pointed to tighter certificate field restrictions, including likely removal of the OU field, while Google also advanced a Chrome root store model that changes how trust is established in browsers, according to DigiCert. The practical issue is not just certificate content, but how PKI governance, issuance, and browser trust decisions are enforced.
NHIMG editorial — based on content published by DigiCert: CA/B Forum Update October 2020
Questions worth separating out
Q: How should teams handle certificate profile changes without breaking trust?
A: Teams should inventory current certificate templates, identify where optional fields or legacy profiles are still in use, and test how reissued certificates behave in real trust stores.
Q: Why do browser root store changes matter for PKI governance?
A: Browser root store changes matter because trust is no longer determined only by the operating system or issuing CA.
Q: What breaks when certificate metadata is self-reported and unvalidated?
A: When certificate metadata is self-reported, it can create a false sense of identity assurance and lead teams to rely on fields that do not strengthen trust.
Practitioner guidance
- Review certificate templates for unvalidated fields Identify where the OU field or similar optional attributes are still embedded in issuance templates, order forms, and downstream workflows.
- Test browser trust against current root policies Check public TLS certificates against Chrome’s trust expectations, not only operating system trust stores.
- Map renewal exposure before policy enforcement lands Inventory new, renewed, and reissued certificates separately so you know which services will be touched when certificate profiles change.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- The certificate-field transition details for new, renewed, and reissued public TLS certificates.
- The Chrome root store context and what it means for browser trust behaviour in practice.
- The ongoing CA/B Forum and S/MIME governance discussion that shapes future certificate policy.
- The vendor's view of how these changes affect existing certificate estates and renewal planning.
👉 Read DigiCert’s CA/B Forum update on certificate fields and Chrome root policy →
Certificate field changes and Chrome root store updates: what now?
Explore further
25/06/2026 11:08 pm
Certificate policy drift is a governance problem, not a browser tweak. When the acceptable shape of a certificate changes, organisations inherit a mixed estate of old and new profiles that do not behave the same way in audits, renewal flows, or trust validation. That is a lifecycle governance issue across PKI, not a one-time compliance notice. The practitioner conclusion is to treat certificate profile changes as a control change, not a formatting change.
A few things that frame the scale:
- 66% say their current tooling is not adequate to manage the scale of machine identities they now have, according to The Critical Gaps in Machine Identity Management report.
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility, according to The Critical Gaps in Machine Identity Management report.
A question worth separating out:
Q: Who owns certificate lifecycle governance when standards change?
A: Ownership should sit with the team responsible for PKI governance, supported by application and platform owners who consume the certificates. Standards changes are operational events, so accountability must cover inventory, reissue timing, trust testing, and business communications before enforcement arrives.
👉 Read our full editorial: CA/B Forum certificate field changes sharpen PKI governance
