openssl x509 certificate question

[SIMON BABY]

Hello Team,

I would like to know if we can have a client certificate with out any extensions in the x509 extensions? Can this function still pass through? X509_verify_cert ().

Regards

Simon

[Viktor Dukhovni]

On Mon, Feb 02, 2026 at 02:13:56PM -0800, SIMON BABY wrote:

> I would like to know if we can have a client certificate with out any
> extensions in the x509 extensions? Can this function still pass
> through? X509_verify_cert ().

Yes, that should be fine. The "clientAuth" extended key usage OID is
only required when the EKU extension is present, in its absence the
certiificate is good for all extended key usages.

Unfortunately, some time back the "openssl req" and "openssl x509"
command-line utilities were changed to automatically add
subjectKeyIdentifier and/or authorityKeyIdentifier extensions.
That really should have been left to the user to decide, but at least
there's an explicit mechanism to ask to turn these off. So, to really
get no extensions, for now you have to ask harder.

Example, (in practice, you'll avoid the >(...) bash wizardry used with
"-out" and "-keyout"):

$ openssl req -nodes -x509 -new -newkey ed25519 \
-keyout >(openssl pkey -noout -text) \
-config <(printf "[exts]\nsubjectKeyIdentifier = none\n") \
-subj "/CN=ClientName" -extensions exts \
-not_after 99991231235959Z \
-out >(openssl x509 -noout -text) \
2>/dev/null | cat
ED25519 Private-Key:
priv:
18:ef:53:84:10:01:ed:ee:df:27:67:03:c6:0f:b4:
02:b5:60:bd:7b:69:8e:0e:97:00:0a:53:65:6b:f5:
e1:cb
pub:
69:99:7d:2b:17:44:26:00:7d:37:7b:80:c5:e5:e6:
cd:b5:a2:ad:c0:dc:ea:22:16:90:a9:54:a1:82:77:
5c:7b
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
47:73:10:46:b0:b0:ca:cd:3a:84:92:0b:a5:0b:7d:1e:fe:43:e9:1a
Signature Algorithm: ED25519
Issuer: CN=ClientName
Validity
Not Before: Feb 3 01:57:09 2026 GMT
Not After : Dec 31 23:59:59 9999 GMT
Subject: CN=ClientName
Subject Public Key Info:
Public Key Algorithm: ED25519
ED25519 Public-Key:
pub:
69:99:7d:2b:17:44:26:00:7d:37:7b:80:c5:e5:e6:
cd:b5:a2:ad:c0:dc:ea:22:16:90:a9:54:a1:82:77:
5c:7b
Signature Algorithm: ED25519
Signature Value:
12:e6:fe:c3:ae:f0:67:50:9c:04:9e:fd:0f:da:0a:c5:a1:b5:
f3:a7:5d:8b:1f:f3:d2:a9:5d:95:80:c3:c3:33:ca:8d:14:75:
2a:ad:22:76:85:9e:b9:ce:57:8a:2d:8e:2a:80:bf:db:dd:68:
4c:5d:3b:48:15:e8:d2:ec:9d:09

--
Viktor. 🇺🇦 Слава Україні!

[SIMON BABY]

Thank you viktor. 

Is this valid for root CA and intermediate CA certificate also ? Or only valid for user certificate? . I am trying to understand if there is any security concerns when there is no extensions in the certificate ? 

Regards

Simon 

--
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-users+unsubscribe@openssl.org.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aYFWle5JFb_2ckFp%40chardros.imrryr.org.

[Viktor Dukhovni]

On Mon, Feb 02, 2026 at 10:05:53PM -0800, SIMON BABY wrote:

> Is this valid for root CA and intermediate CA certificate also ? Or only
> valid for user certificate? . I am trying to understand if there is any
> security concerns when there is no extensions in the certificate ?

Depends on what you mean by "this"? :-)

- CA certificates generally don't need or have EKU extensions. If they
do have an EKU extension, then (rfc5280 notwithstanding) OpenSSL and
IIRC some other implementations interpret that extension as an
additional limitation on the usage of the EE key. So skip the EKU
extension, or also list "clientAuth" if the CA is going to issue TLS
client certificates.

- OpenSSL tolerates (implicitly) CA certificates that have neither a
basicConstraints nor a keyUsage extension, but this is not
recommended. A CA should have at least:

basicConstraints: CA:true, ...
keyUsage: keyCertSign, ...
subjectKeyIdentifiter: ...
authorityKeyIdentifiter: ...

To generate a root CA (generally protect with a strong password,
rather use "-nodes" to disable encryption):

$ openssl req -quiet -nodes -new \
-keyout rootkey.pem -newkey rsa:2048 \
-x509 -out rootcrt.pem \
-subj "/CN=Root CA" -not_after 99991231235959Z \
-addext "basicConstraints = critical, CA:true" \
-addext "keyUsage = critical, cRLSign, keyCertSign"\
-addext "subjectKeyIdentifier = hash" \
-addext "authorityKeyIdentifier = keyid:always"
$ openssl x509 -in rootcrt.pem -noout -text -certopt no_pubkey,no_sigdump

Certificate:
Data:
Version: 3 (0x2)
Serial Number:

7c:ed:8d:cd:6a:1c:c9:ad:ee:c2:16:9d:6e:73:1c:b3:d4:e8:dd:2d
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Root CA
Validity
Not Before: Feb 3 07:12:25 2026 GMT

Not After : Dec 31 23:59:59 9999 GMT

Subject: CN=Root CA
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
D9:D8:10:05:D5:E2:82:20:98:79:8A:57:B6:76:5D:43:0D:54:86:AE
X509v3 Authority Key Identifier:
D9:D8:10:05:D5:E2:82:20:98:79:8A:57:B6:76:5D:43:0D:54:86:AE

An intermediate might then be generated as follows:

$ openssl req -quiet -nodes -new \
-keyout cakey.pem -newkey rsa:2048 \
-x509 -out cacrt.pem \
-subj "/CN=Issuer CA" -days 7305 \
-CAkey rootkey.pem -CA rootcrt.pem \
-addext "basicConstraints = critical, CA:true, pathlen:0" \
-addext "keyUsage = critical, cRLSign, keyCertSign"\
-addext "subjectKeyIdentifier = hash" \
-addext "authorityKeyIdentifier = keyid:always"
$ openssl x509 -in cacrt.pem -noout -text -certopt no_pubkey,no_sigdump

Certificate:
Data:
Version: 3 (0x2)
Serial Number:

6b:dc:1b:4a:a3:23:d3:89:a7:e4:0e:2e:76:0a:a6:07:60:78:33:1e
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=Root CA
Validity
Not Before: Feb 3 07:21:02 2026 GMT
Not After : Feb 3 07:21:02 2046 GMT
Subject: CN=Issuer CA
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Certificate Sign, CRL Sign
X509v3 Subject Key Identifier:
5A:8C:87:49:BF:97:DC:64:30:53:2B:49:F1:0D:57:45:70:FF:EA:92
X509v3 Authority Key Identifier:
D9:D8:10:05:D5:E2:82:20:98:79:8A:57:B6:76:5D:43:0D:54:86:AE

You might find the Webinar helpful:

- Slides: https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit?slide=id.g2b4be0ee06d_0_0#slide=id.g2b4be0ee06d_0_0
- Video : https://www.youtube.com/watch?v=OuH4vwmzP_o

--
Viktor. 🇺🇦 Слава Україні!

[David von Oheimb]

On 03.02.26 08:28, Viktor Dukhovni wrote:

On Mon, Feb 02, 2026 at 10:05:53PM -0800, SIMON BABY wrote:

Is this valid for root CA and intermediate CA certificate also ? Or only
valid for user certificate? . I am trying to understand if there is any
security concerns when there is no extensions in the certificate ?

Depends on what you mean by "this"? :-)

- CA certificates generally don't need or have EKU extensions.  If they
  do have an EKU extension, then (rfc5280 notwithstanding) OpenSSL and
  IIRC some other implementations interpret that extension as an
  additional limitation on the usage of the EE key.  So skip the EKU
  extension, or also list "clientAuth" if the CA is going to issue TLS
  client certificates.

Right, and for maximal compatibility better not include the EKU extension in CA certs
(which as Viktor mentioned yesterday does not place any restriction w.r.t. extended key usage).

- OpenSSL tolerates (implicitly) CA certificates that have neither a
  basicConstraints nor a keyUsage extension, but this is not
  recommended.

Yep.

  A CA should have at least:

    basicConstraints: CA:true, ...
    keyUsage: keyCertSign, ...
    subjectKeyIdentifiter: ...
    authorityKeyIdentifiter: ...

For root CA certs (or other trust anchor certs) the AKID is needless, and so RFC 5280 section 4.2.1.1 permits leaving it out (while requiring both SKID and AKID for all other cases in CA certs).
Generally, AKIDs and SKIDs should be included to help chain building between the EE cert and the trust anchor, while they do not affect the security of chain validation.
For EE certs the SKID is of course not needed for cert chain building, but still may be useful for identifying the signer of non-cert data (as used, e.g., in CMS and CMP).

Further extensions that may be helpful to have in all certs (except root / trust anchor) are CDP and AIA entries providing info for revocation checking using CRLs or  OCSP, respectively.

    David

[SIMON BABY]

Thank you for the clarification . Yes I was asking about the case where all the extensions are empty in root CA and intermediate CA as well. 

So in your example what happen if the below fields are also empty ?

     X509v3 extensions:
                X509v3 Basic Constraints: critical
                    CA:TRUE, pathlen:0
                X509v3 Key Usage: critical
                    Certificate Sign, CRL Sign
                X509v3 Subject Key Identifier: 
                    5A:8C:87:49:BF:97:DC:64:30:53:2B:49:F1:0D:57:45:70:FF:EA:92
                X509v3 Authority Key Identifier: 
                    D9:D8:10:05:D5:E2:82:20:98:79:8A:57:B6:76:5D:43:0D:54:86:AE

Do we have any RFC saying  about the mandatory and optional extensions in CA’s and user certs ?

Regards

Simon

On Monday, February 2, 2026, Viktor Dukhovni <openss...@dukhovni.org> wrote:

--
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-users+unsubscribe@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aYGjrdyC_2sZjREN%40chardros.imrryr.org.

[Viktor Dukhovni]

On Tue, Feb 03, 2026 at 03:04:20AM -0800, SIMON BABY wrote:

> Thank you for the clarification . Yes I was asking about the case where all
> the extensions are empty in root CA and intermediate CA as well.
>
> So in your example what happen if the below fields are also empty ?
>
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:0
> X509v3 Key Usage: critical
> Certificate Sign, CRL Sign
> X509v3 Subject Key Identifier:
> 5A:8C:87:49:BF:97:DC:64:30:53:2B:49:F1:0D:57:45:70:FF:EA:92
> X509v3 Authority Key Identifier:
> D9:D8:10:05:D5:E2:82:20:98:79:8A:57:B6:76:5D:43:0D:54:86:AE
>
> Do we have any RFC saying about the mandatory and optional extensions in
> CA’s and user certs ?

That's an interesting theoretical question, but I am curious why you
feel it is important to pursue this line of inquiry. There is little
reason to not simply include these common CA extensions in your CA
certificates.

You can read RFC5280, but odn't confuse many of its interoperability
"recommendations" with absolute requirements, there is no IETF police,
and not all implementations do or should enforce every requirement
("recommendation") in that RFC. And yet, it is a good idea to conform
whenever possible.

FWIW, OpenSSL allows some or all of these extensions to be missing, but
there's no reason to push your luck, other implementations may be less
tolerant.

--
Viktor. 🇺🇦 Слава Україні!

[SIMON BABY]

Thank you Viktor

--
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-users+unsubscribe@openssl.org.

To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/aYH-thr8JOTNamra%40chardros.imrryr.org.