Ability to handle (or ignore) added critical X509 cert extension 1.3.6.1.4.1.311.21.10?

[delfuego]

Is there any ability to have the timestamp server (or any Go-based X509-utilizing app) either handle or ignore the X509 cert extension 1.3.6.1.4.1.311.21.10?

I was finally able to engage our agency PKI folks to work with me on generating a proper certificate for timestamping from the agency PKI CA, and they generated it today — and while it has the proper key usage and critical extended key usages in place, it also has a critical extension with OID 1.3.6.1.4.1.311.21.10 set. And the presence of this extension prevents timestamp-server from starting; it panics with an "x509: unhandled critical extension" error, which seems to be bubbling up from the Go x509 module's initial processing of the cert.

This is an extension that's included by default by the Active Directory Certificate Authority, and is a Microsoft custom extension that's now legacy and likely can be disabled for the ADCA. BUT, it's almost certain that our agency is going to need to put a formal change management plan in place to try disabling it (it can only be disabled tenant-wide, it can't be controlled on an issued-certificate basis). So that means... probably a lot of time.

On the flip side, it also looks like the contents of the extension are just a recapitulation of the critical timestamp EKU (e.g., they follow the MS advice "If you are issuing certificates that include both application policy and EKU extensions, ensure that the two extensions contain identical object identifiers"). Given that, is there any way that this could be handled at the app level, such that Go doesn't treat this as an unexpected/unhandled extension and instead will either ignore it or do the comparison and give it a pass if it matches the EKU?

In the end, as I said, I'm heavily engaged with our agency PKI team to advocate for getting this extension disabled in the AD Cert Authority. But there might also be reason to properly handle this in timestamp-authority, since it would mean that any other users who are standing up a server with an ADCA-generated certificate won't have to worry about this particular thorn.

I'm happy to provide the generated cert, if you'd like to take a look — I just didn't know whether you'd want it shared in this ticket, vs. provided privately.