Rejecting intermediate CA certificates

[Bruce Stephens]

Is there a way to do this? Obviously the motivation is eMudhra but
presumably they're not the only instance where you might want to block
an intermediate CA without blocking their issuer entirely.

[Leon Timmermans]

I was wondering the same. A CRL would be the obvious way to do this, but there is no default CRL to go with the default certificates.

Leon

[Tomas Mraz]

You can use the TRUSTED CERTIFICATE format in the trust store to
decorate the affected intermediates with explicit distrust. Please note
you have to explicitly reject it for all purposes not just the
anyExtendedKeyUsage as that rejects it only for usages that do not
require explicit trust. The manual page openssl-verification-options(1)
is wrong in that regard.

Tomas Mraz

--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

[Dimitri Ledkov]

Heya,

On Wed, 21 Oct 2026, 13:19 'Tomas Mraz' via openssl-users, <openss...@openssl.org> wrote:

You can use the TRUSTED CERTIFICATE format in the trust store to
decorate the affected intermediates with explicit distrust. Please note
you have to explicitly reject it for all purposes not just the
anyExtendedKeyUsage as that rejects it only for usages that do not
require explicit trust. The manual page openssl-verification-options(1)
is wrong in that regard.

This did work, and I have a prototype of that to share.

But we had mixed feelings about shipping that internally.

1. it worked for things that use libssl

2. one had to include each variant of certificate signed with each CA chain

3. One may not know or have all cross-signed chains

4. Websites can present alternative chains

5. the trusted bit did work and survived across update-ca-certs

6. some software does not use libssl, or doesn't parse trusted bits, or only uses libcrypto / alternative stacks (i.e. go, java)

Thus initially it was a nice solution, but by the time we tested all corner cases mozilla removed the affected CA roots altogether - asking legitimate intermediate CA users to move to any other roots and chains. Effectively the intermediate CA poisoned and caused removal of the root CA.

Current guidance is to drop the root CA altogether.

But having something nicer for the future would be nice.

Tomas Mraz

On Wed, 2026-10-21 at 12:56 +0100, Bruce Stephens wrote:
> Is there a way to do this? Obviously the motivation is eMudhra but
> presumably they're not the only instance where you might want to
> block
> an intermediate CA without blocking their issuer entirely.

--
Tomáš Mráz, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy… everywhere.
https://openssl.foundation/donate/ways-to-give

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-user...@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/918e81ae7ec19a27e3295796305407ec8fdd9c6d.camel%40openssl.foundation.

[Bruce Stephens]

I agree, this feels wrong. I'd like some direct way to say that some
X509* should be added to an X509_STORE* and reject paths containing
that certificate. Maybe I can get that by calling the (undocumented)
X509_add1_reject_object for each of the right ASN1_OBJECT* values
(none of which is about issuing certificates) but it doesn't feel
right.

Removing the root CA is nice and simple so that seems workable for
this case, but something simpler for rejecting intermediate CAs (and
EE certs, for that matter) feels worthwhile.

[Leon Timmermans]

I think that I'm wrong, and that having a CRL among your trust roots will do the trick for openssl. I'm just not sure if anyone is actually doing that.

Leon