[GH-ISSUE #533] X509v3 Subject Alternative Name must be critical #319

New issue

Open

opened 2026-02-25 22:33:06 +03:00 by kerem · 1 comment

kerem commented

2026-02-25 22:33:06 +03:00

Owner

Originally created by @seregaizsbera on GitHub (Jun 22, 2023).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/533

Environment

Operating system (including version):
any
mkcert version (from mkcert -version):
1.4.4
Server (where the certificate is loaded):
any
Client (e.g. browser, CLI tool, or script):
OpenDJ 3.5

What you did

Consider legacy soft that expected the server name to match certificate's common name.

What went wrong

That soft issues verification error, since real name of the server resides in SAN Extension.

The Certificate presented by the server example.com could not be trusted. There is a name mismatch between the name of the server (example.com) and the subject DN of the certificate. This could be caused because you are connected to a server pretending to be example.com. Before accepting this certificate, you should examine the server's certificate carefully.

Expected result

If mkcert doesn't allow deprecated usage of common name field in subject, it must specify, that SAN extension is critical, so that legacy soft doesn't try to use it in deprecated way. The error message would be something like 'unsupported certificate purpose'.

Originally created by @seregaizsbera on GitHub (Jun 22, 2023). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/533 ## Environment * Operating system (including version): any * mkcert version (from `mkcert -version`): 1.4.4 * Server (where the certificate is loaded): any * Client (e.g. browser, CLI tool, or script): OpenDJ 3.5 ## What you did Consider legacy soft that expected the server name to match certificate's common name. ## What went wrong That soft issues verification error, since real name of the server resides in SAN Extension. _The Certificate presented by the server example.com could not be trusted. There is a name mismatch between the name of the server (example.com) and the subject DN of the certificate. This could be caused because you are connected to a server pretending to be example.com. Before accepting this certificate, you should examine the server's certificate carefully._ ## Expected result If mkcert doesn't allow deprecated usage of common name field in subject, it must specify, that SAN extension is critical, so that legacy soft doesn't try to use it in deprecated way. The error message would be something like 'unsupported certificate purpose'.

kerem commented

2026-02-25 22:33:06 +03:00

Author

Owner

@DoraTheExploder commented on GitHub (Aug 7, 2025):

I've discovered that if you use an external tool to generate a Certificate Signing Request (.csr) such as DigiCert CSR Tool (or do it manually with openssl), you can customize issue fields (though not sure about SAN support) and then pass it as a sort of configuration file to mkcert with $ mkcert -csr <domain>.

I have not tested using a CSR for initial Root CA installation, but $ mkcert --help implies that it should be possible.

@DoraTheExploder commented on GitHub (Aug 7, 2025): I've discovered that if you use an external tool to generate a Certificate Signing Request (.csr) such as [DigiCert CSR Tool](https://www.digicert.com/easy-csr/openssl.htm) (or do it manually with openssl), you can customize issue fields (though not sure about SAN support) and then pass it as a sort of configuration file to mkcert with `$ mkcert -csr <domain>`. I have not tested using a CSR for initial Root CA installation, but `$ mkcert --help` implies that it should be possible.