Cert signed by CA with constraint 'CA:FALSE' are considered valid

[arekkusu]

LDAPServer-generate-cert.txt
LDAPServer-setup-ca.txt
openssl_ca.conf.txt
openssl_srv.conf.txt

CA cert
ca_false.crt.txt
ca_true.crt.txt
Server Cert + Key
server_ca_false.crt.txt
server_ca_false.key.txt
server_ca_true.crt.txt
server_ca_true.key.txt

I am unsure if this is a bug or a known implementation difference between SSL libraries.
It certainly created some confusion so here it is:

I Created a CA and signed certificates with it

• The CA had the basic constrain "CA:FALSE" set to false
• I attached the openssl config + procedure on how I generate CA and server cert (it case it matters)

Certificate considered trusted by OpenSSL and moznss

• Certificate worked fine with OpenLDAP 2.44 client/server compiled with OpenSSL (CentOS 7)
• Same for default OpenLDAP client on CentOS 7 which uses moznss

Certificate considered not trusted by GnuTLS

• I discovered this because ldapsearch on Debian/Ubuntu is compiled with GnuTLS

How to test:

• Generate first set of CA + cert with "CA:FALSE"
• Generate second set of CA + cert with ""CA:TRUE"
• Start openssl s_server
• Test with both openssl s_client and gnutls-cli providing the CA as option

Result: gnu-tls could not verify the cert create by a CA with "CA:FALSE", works with "CA:TRUE:. Both work with openssl.

# GnuTLS output (CA:FALSE):

Peer's certificate issuer is unknown
Peer-s certificate is Not trusted

Reading about the CA constrain it sounds logical this should be turned on for a CA. Is OpenSSL behavior correct ?

[richsalz]

The OpenSSL utilities will sign a certificate without really looking at the signer's certificate.

When verifying a certificate chain, OpenSSL library will see that an invalid CA signed the cert. Just like gnuTLS, etc. Are you sure that openssl did not do this? What version are you using?

[joernheissler]

@arekkusu I think it would be helpful if you could attach the ca cert and server key+cert for which you see this behaviour.

[arekkusu]

Yes I am quite sure. I have used the CA cert with 'CA:false' with OpenLDAP/openssl on CentOS 7 for month. Only recently noticed that OpenLDAP/gnutls in Ubuntu14/Ubuntu16 fails.

Note the extension I used in my openssl config:

[ ca_ext ]
keyUsage                = critical,keyCertSign,cRLSign
basicConstraints        = critical,CA:false
subjectKeyIdentifier    = hash

Let me generate cert + log I can share.

[richsalz]

What version of openssl is your ldap build using?
You don't need to share that information. Your config, saying CA:false, is incorrect. I don't know when gnutls checked it. I don't know off the top of my head when OpenSSL started checking it.

[richsalz]

Sorry I was unclear. "You don't need to share that information" I meant about generating and posting certs or a cert chain. Knowing the version used in your ldap config would be interesting. But this fundamentally comes down to an erroneous config file using a non-CA cert as a CA. Really old versions of openssl did not check this, current ones should. I will leave this open until we find out the openssl version used in the ldap server.

[arekkusu]

Ok added the cert to my first post anyway...

I confirm the behavior with following:

OpenSSL 1.0.2k-fips  26 Jan 2017

[vagrant@default ~]$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

[vagrant@default ~]$ gnutls-cli -v
gnutls-cli 3.3.26

openssl s_client does return:

Verify return code: 0 (ok)

While it should be following if the check failed

Verify return code: 7 (certificate signature failure)

GnuTLS returns:

- Status: The certificate is NOT trusted. The certificate issuer is not a CA.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

[richsalz]

1.0.2k is a bit outdated, but ... I'm stumped. Anyone else @openssl ?

[arekkusu]

Just compiled latest (LTS) openssl and I still see the same behavior.

[vagrant@default openssl-1.0.2n]$ ./apps/openssl version
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
OpenSSL 1.0.2n  7 Dec 2017

How to reproduce:

# Run test server
openssl s_server -key server_false.key -cert server_false.crt -accept 6666
# Run test client (OpenSSL 1.0.2n  7 Dec 2017)
./apps/openssl s_client -CAfile ~/CA_FALSE/ca_false.crt -connect vagrant-srv.example.org:6666
(...)
    Verify return code: 0 (ok)

So I am either doing something wrong or it's is possibly an issue in OpenSSL.

[kaduk]

latest openssl [...] 1.0.2n

The newest release is 1.1.0g, which includes a near-complete rewrite of certificate verification.

[richsalz]

Yeah, but the "check CA flag" code seems to be in 1.0.2, for a very long time. Hence my confusion.

[kaduk]

IIRC we do not apply purpose checking to trusted certificates prior to 1.1.0

[joernheissler]

I can confirm the issue with openssl 1.0.1t and 1.0.2k, but not with 1.1.0g.

[richsalz]

Aha. That was the point I missed, thanks Ben.

So this is a bug in 1.0.2 (or at least a mis-feature) and it's fixed in 1.1.0 We're not going to change the behavior in 1.0.2

I am going to close this.

[arekkusu]

Sorry I did not realize I compiled the latest LTS and not the latest. I confirm everything is fine on openssl-1.1.0g

Thanks a lot for your help !

[mattcaswell]

For info this change in behaviour was introduced by this commit: 0daccd4. It applies to 1.1.0 and master only. So prior to that we don't check chain extensions for trusted certificates.

[0cjs]

Technically the certificate is not compliant with RFC 5280, if this is the config used:

[ ca_ext ]
keyUsage                = critical,keyCertSign,cRLSign
basicConstraints        = critical,CA:false

From section 4.2.1.9 Basic Constraints:

The cA boolean indicates whether the certified public key may be used to verify certificate signatures. If the cA boolean is not asserted then the keyCertSign bit in the key usage extension MUST NOT be asserted.

That said, yes, OpenSSL should fail safe in this scenario.

[tomato42]

This issue has CVE-2021-3601 assigned.

[iamamoose]

CVE was not issued by the OpenSSL CNA. CVE should be rejected. OpenSSL does not class this issue as a security vulnerability. The trusted CA store should not contain anything that the user does not trust to issue other certificates.

[tomato42]

The CVE was assigned to 1.0.2 specifically, at a time when it was already not supported by the OpenSSL Project.

[mattcaswell]

The project still analyses reports of vulnerabilities against 1.0.2 and continues to issue CVEs for it (the most recent one being CVE-2022-2068 which was published last month)

[iamamoose]

The CVE was assigned to 1.0.2 specifically, at a time when it was already not supported by the OpenSSL Project.

CNA's are not allowed to assign a CVE name for any issue in a product covered by another CNA, even if it was unsupported. The CNA should first be approached and asked to assign a name, and any lack of response or dispute is then escalated to their root CNA.

[tomato42]

It was not my decision, I'm just a messanger, please talk with Red Hat Product Security directly: secalert@redhat.com

[iamamoose]

We had the CVE reassigned to our CNA and published the rejection https://www.cve.org/CVERecord?id=CVE-2021-3601