Repository navigation
[4.1.0] Regresion or Undocumented Behavioral change in the X509_check_host #33420
Description
Problem description
Starting the 4.1.0 the X509_check_host always fails when the X509 certificate contains the only subject DN with CN identifies the hostname and no SAN(s) is included. and no flags are used (flags parameter is set to 0).
The call like that X509_check_host(cert, expected_hostname, 0, 0, NULL); returns 0 in Openssl 4.1.0 and returns 1 with previous releases.
The openssl verify command clearly display the behaviour difference. The command below returns:
openssl verify -CAfile <CAFilePath> -verify_hostname <`CN entry` in the `Subject DN`> <certificate path>
- In 4.1.0:
<Subject DN content>
error 62 at 0 depth lookup: hostname mismatch
error <certificate path>: verification failed
- in 4.0.2 and earlier:
<certificate path>: OK
Steps to reproduce
- Generate the certificate with the FQDN/hostname in the
Subject DNand does not contain anySubject Alternative Namefields. - run the command below against the
4.1.0and earlier version(s) ofopensslbinaries,
Activity
esyr commentedon Oct 27, 2026
cc @bob-beck
tregubovav-dev commentedon Oct 27, 2026
I've added the example files for the reproduction.
Certificates Subject DN is
Subject: CN = srv.test.tldUse:
openssl verify -CAfile ca.crt.txt -verify_hostname srv.test.tld <certificate_filename>idrassi commentedon Oct 28, 2026
Thanks for the certificates. I have reproduced the issue.
PR #31982 intentionally changed this behavior. The changelog documents it, but the command line manual still promises CN matching. The standard verification options don't expose a switch to enable it. For these certificates, reissuing with
DNS:srv.test.tldin the SAN is the straightforward migration.Applications that perform their own CN matching also need to be updated. OpenSSL 4.1 applies DNS constraints to the CN only with
X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECTset andX509_CHECK_FLAG_NEVER_CHECK_SUBJECTclear. An application can otherwise accept a CN that OpenSSL hasn't checked against the issuer's DNS constraints.Curl is one example: it relies on OpenSSL for chain validation but performs CN fallback itself. I tested curl commit 3163ec065643, from tag
curl-8_23_0, against both releases.Only the root was trusted. The server supplied this chain beneath it:
I requested
https://victim.testover loopback using--resolve, with certificate and hostname verification enabled.Reversing the
x509_vfy.cchange in e7f3a42 restores rejection without restoring CN matching by default. That isolates the cause: it doesn't settle where the compatibility fix belongs. OpenSSL integrated hostname verification rejects this certificate.For applications retaining independent CN matching, the extra checks must be enabled during chain verification. Setting
ALWAYS_CHECK_SUBJECTthere rejects this example in my probe. Adding it only to a laterX509_check_hostcall won't restore those checks.The flag isn't an exact replacement for the old behavior:
@t8m The curl example shows that moving to 4.1 can weaken certificate validation in applications that retain their own CN matching. Could the project publish a prominent migration notice explaining this impact and how applications should enable the necessary CN constraint checks?
tregubovav-dev commentedon Oct 28, 2026
Thanks a lot Mounir to pointing me out the PR and changelog that missed from my eyes.
It finally confirms our approach to resolve this behavior change.
I would suggest to update the
openssltool documentation update to avoid customers' confusion.You are free to close this issue if you are not planning do any action based on it.
idrassi commentedon Oct 28, 2026
There is still the impact I described above on certificate validation for applications like curl.
We need to communicate about it to avoid security issues on third party application that would update to 4.1. Not sure how this can be done.