X509V3CertificateGenerator (deprecated) allows a non-CA certificate (cA=FALSE, keyUsage=keyCertSign) to issue a child certificate

[wuhuyibeijiu]

Description:

Steps to Reproduce

I created a self‑signed root certificate with the following extensions:

• basicConstraints=CA:FALSE
• keyUsage=keyCertSign, cRLSign, digitalSignature

This certificate is not a CA but claims the right to sign certificates. I used Bouncy Castle's X509V3CertificateGenerator (deprecated API) to attempt to issue a child certificate using this inconsistent root certificate as the issuer.

The attached Java file TestLoadCert.java performs the following:

1. Loads the root certificate (root_ca_false.pem) and its private key.
2. Generates a new key pair for a child certificate.
3. Builds a child certificate template using X509V3CertificateGenerator.
4. Calls generate() using the root certificate's private key to sign the child certificate.

The core signing call is:

X509Certificate childCert = certGen.generate(caPrivateKey, "BC");

The full code is provided as an attachment.

Expected Result：
The generate() method should throw an exception because the issuer certificate has basicConstraints.cA=False. According to RFC 5280, a certificate with cA=FALSE must not be used to sign other certificates, even if keyUsage contains keyCertSign.

Actual Result：
The generate() method succeeds and writes a child certificate (child_load.crt). No error or warning is produced during the signing operation.

Environment：
Bouncy Castle version: 1.70
Java version: 17.0.18
Operating system: Ubuntu 22.04 LTS
API used: org.bouncycastle.x509.X509V3CertificateGenerator (deprecated)

Questions：
1、What is the recommended replacement API for X509V3CertificateGenerator? I noticed the compiler warning that it is deprecated.

2、Is the old X509V3CertificateGenerator API still intended to remain available in the library, or will it be removed in a future release?

3、Since my experiment uses the deprecated API, does the observed behavior still indicate an issue with Bouncy Castle's core certificate signing logic regarding CA constraint enforcement? Or should I retest with the recommended replacement API?

Attachments
TestLoadCert.java
root_ca_false.pem
root_ca_false.key
child_load.crt

References
RFC 5280, Sections 4.2.1.3 and 4.2.1.9
Bouncy Castle API: org.bouncycastle.x509.X509V3CertificateGenerator

[testcase.zip](https://github.com/user-attachments/files/29160955/testcase.zip)

[dghgit]

The class you want to use is org.bouncycastle.cert.X509v3CertificateBuilder which is in the bcpkix package.

Note: this report is not a bug, neither the builder nor the generator perform any checks as to whether a given certificate can act as a CA for another one when the private key is used. That's the job of the path validators and while RFC 5280 is probably the most common profile, it's not the only one. When producing a certificate chain it is up to a user to choose the appropriate extensions with the appropriate values for the profile and job they are trying to do.