Certificate verification fails with chained certificates

[dimaaik27]

A commit in v1.14 changed the certificate chain trust mode from X509ChainTrustMode.System to X509ChainTrustMode.CustomRootTrust in VerifyRemoteCertificate. This breaks certificate validation for certificates with intermediate CA chains that previously worked.

Certificates with intermediate certificate chains fail validation in v1.14. Previously, these certificates validated successfully using the Windows certificate store (X509ChainTrustMode.System). Now With CustomRootTrust, there is currently no mechanism to provide intermediate certificates to the validation chain. Validation always fails because the full certificate chain cannot be resolved

We would like either:
Support a way to supply intermediate certificates for CustomRootTrust validation,
or
Revert to using X509ChainTrustMode.System
or
any other fix that would allow us to use certificates as before

Affected version: v1.14

[dckorben]

Uh, that only worked because it wasn't checking at all.

[dimaaik27]

So How it should work for certificates with intermediate CA chains ? I don't see any way to get these kind of certificates working with the current version of the library.

[dckorben]

X509VerificationFlags.AllowUnknownCertificateAuthority; is probably why it worked because X509ChainTrustMode.System isn't even used.

This isn't an intermediate certificate issue because the public key will validate it. If you are setting a cert directly which came from a CA, there is a CA public cert you can provide so it can validate the child cert. That would be a workaround which would allow certificate validation to pass, but you have to set it explicitly.

The reason for the behavior is: if (caCert is null) ...return false; which is basically assuming you had a self-generated public/private cert but you also would need to have a self-signed CA cert to validate against and not the whole universe of CAs.

To understand the situation:

• You are setting a paid for cert from a public CA that is being set directly in config and not via TLS?
• You have a cert from a public CA for this use and you are setting it manually but don't have the ca cert config set?

[dimaaik27]

I've reproduced the issue in the cloned repository. The problem lies in how the certificate chain validation mode handles intermediate certificates.

What doesn't work:

X509Chain chain = new();
            // add all your extra certificate chain
            chain.ChainPolicy.TrustMode = X509ChainTrustMode.CustomRootTrust;
            chain.ChainPolicy.CustomTrustStore.Add(caCert);
            chain.ChainPolicy.RevocationMode = _socketSettings.CheckCertificateRevocation ? X509RevocationMode.Online : X509RevocationMode.NoCheck;

What works:

X509Chain chain = new();
            // add all your extra certificate chain
            chain.ChainPolicy.TrustMode = X509ChainTrustMode.System;
            chain.ChainPolicy.ExtraStore.Add(caCert);
            chain.ChainPolicy.RevocationMode = _socketSettings.CheckCertificateRevocation ? X509RevocationMode.Online : X509RevocationMode.NoCheck;

So these are the only two lines I'm changing in the current source code (1.14) to make my certificates work. The X509VerificationFlags.AllowUnknownCertificateAuthority is not set in this case.

With X509ChainTrustMode.CustomRootTrust, the chain builder only trusts certificates explicitly added to CustomTrustStore. If caCert is only the root certificate and the certificate chain includes intermediate CAs, those intermediates aren't in the trust store, causing validation to fail.

The place where it fails is notif (caCert is null) ...return false; but rather bool isValid = chain.Build((X509Certificate2)certificate);. isValid is false and then this part is executed else { sslPolicyErrors |= SslPolicyErrors.RemoteCertificateChainErrors; } and eventrually we return false from the method. (I was debugging it so I am sure that it fails in this place)

I have this in my config file
SSLCertificate=...
SSLCACertificate=...

[dckorben]

Enrolling the system cert store is very different than what was there before. That code was built to validate privately generated and shared certs without a Public CA, would need to validate this doesn't break those kinds of keys as well.

[dckorben]

IMO, if you are providing a CA Cert, you should not also enroll the system store. But if you don't provide a CA Cert, falling back to the system store isn't an unreasonable idea. I still don't see why validation is failing if you have the right Public CA Cert. Are you using the parent Public CA Cert and not the intermediate Public CA Cert? Again, the only reason it works is the system store has all of the lineage. The config side doesn't allow you to set an entire lineage of certificates.

[dimaaik27]

Ok, I was using the intermediate CA Cert. Should I always use the root/parent one? What if there are some policies to specifically use intermediate certificates (e.g. to prevent root compromise or due to frequent rotation or whatever internal policies could be)? I understand that with system store it worked because it had all the lineage, but what if we have no other choice than to use this intermediate certificate and so we kind of need the whole lineage from system?

[dckorben]

I use TLS and don't have to specify a cert or CA so I get the system store lineage by default. That was broken and what my PR fixed but also added tests for self-signed key exchanges which are somewhat common.

If you privately generate keys and share the public keys you don't really have a need for a Public CA infrastructure and you don't typically see much key rotation, and it becomes a 1:1 security relationship. I'm actually surprised someone is paying for a cert from a public CA to use in this way instead of using TLS to connect. As a result, I don't have a scenario like this I can write tests for though that wouldn't rely on public vendor endpoints.

Shorter: I don't have:
SSLCertificate=...
SSLCACertificate=...
in my configs at all.

[dckorben]

Ok, I was using the intermediate CA Cert. Should I always use the root/parent one?

Is the cert dual signed by chance? Can you tell me who the CA is?

[dckorben]

Only other possible solution short of code changes is are you setting SSLServerName? The resolution is way stricter with newer certificates than it used to be.

[dckorben]

Built a quick mockup of the setup using local certificates. It cannot validate the intermediate cert because the root cert then isn't present. And if the root cert is used, it's not the signer of the child so that doesn't work either. It is impossible to represent the certificate lineage with the available configuration endpoints.

The answer for this would have to be some kind of relaxing of the rules around certificate chain validation.

I still don't think X509ChainTrustMode.System is the right solve for certs you are explicitly setting to trust.

[dckorben]

With chain.ChainPolicy.VerificationFlags = X509VerificationFlags.AllowUnknownCertificateAuthority; chain.ChainPolicy.RevocationFlag = X509RevocationFlag.ExcludeRoot;
the certificate will validate on windows as a PartialChain with 'A certificate chain could not be built to a trusted root authority.' which I don't think is ...great.

However, this being an interesting situation with it being a Public Root CA where you'd want to verify that, usually.
I think a better solution is if no CA Cert is provided, fall back to the System store. We could test that by generating a Root CA and trusting it at the machine level and then not provide it in the config with a local cert it signed.

[dimaaik27]

yes, I agree that AllowUnknownCertificateAuthority kind of defeats the purpose of certificate validation. The fallback approach seems fine. It also gives some solution to restore backward compatibility (even if we need to remove CA from a config file) with v1.13.

I have tested the branch and it works if I don't specify the CA in the config file.