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.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “CA/B Forum Update October 2020”.
Key questions
Q: How should security teams respond when certificate fields are removed from public TLS profiles?
A: Treat field removal as a governance change, not a documentation update.
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 order forms keep optional legacy fields?
A: Operational drift breaks first.
Practitioner guidance
- Update certificate request templates Remove deprecated or low-value fields such as OU from public TLS ordering workflows and align internal request forms with current CA/B Forum direction.
- Review browser trust assumptions Validate public-facing certificates against Chrome root store expectations in addition to operating-system trust stores so browser-specific trust failures are surfaced early.
- Separate legacy and new issuance policy Keep previously issued certificates under their original validity rules, but enforce the new field profile for renewals, reissues, and new public TLS certificates.
Bottom line: Certificate field restrictions are tightening because optional certificate data can create governance noise when it is not independently validated.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 11:08 pm
Certificate governance has moved from static formatting to enforced policy. The OU field discussion shows that long-accepted certificate attributes can be reclassified when they no longer provide trustworthy value. That is a governance change, not a cosmetic one, because issuers, order workflows, and relying parties all have to converge on the same field model. Practitioners should treat certificate profiles as governed policy artefacts, not historical defaults.
A question worth separating out:
Q: Should organisations prioritise template cleanup or browser trust validation first?
A: Start with template cleanup if the issuance process still creates noncompliant certificates, then validate browser trust because both controls are necessary. If the certificate cannot be issued correctly, downstream trust checks only confirm a failure that was already built into the workflow.
👉 Read our full editorial: CA/B Forum certificate field changes sharpen PKI governance