starred/mkcert

Fork 0

mirror of https://github.com/FiloSottile/mkcert.git synced 2026-04-25 05:26:03 +03:00

[GH-ISSUE #257] Request: add subject CN for client certificates #167

New issue

Closed

opened 2026-02-25 22:32:46 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 22:32:46 +03:00

Owner

Originally created by @antong on GitHub (Apr 17, 2020).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/257

For server authentication, SAN DNS is what is required. However, many TLS servers that perform client authentication (mutual TLS) use the subject CN in the client certificate as the identity. An example is Mosquitto (see https://mosquitto.org/man/mosquitto-conf-5.html and use_identity_as_username).

I read the discussion in #205. However, I would argue that the situation is different for client certificates. There are common servers and configurations that do not work without the CN in client certificates. Also, TLS clients do not necessarily correspond to DNS names in the way TLS servers do, but may be apps or people (for a person the email address is already supported).

Originally created by @antong on GitHub (Apr 17, 2020). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/257 For server authentication, SAN DNS is what is required. However, many TLS servers that perform client authentication (mutual TLS) use the subject CN in the client certificate as the identity. An example is Mosquitto (see https://mosquitto.org/man/mosquitto-conf-5.html and `use_identity_as_username`). I read the discussion in #205. However, I would argue that the situation is different for client certificates. There are common servers and configurations that do not work without the CN in client certificates. Also, TLS clients do not necessarily correspond to DNS names in the way TLS servers do, but may be apps or people (for a person the email address is already supported).

kerem closed this issue

2026-02-25 22:32:46 +03:00

kerem commented

2026-02-25 22:32:47 +03:00

Author

Owner

@petr-motejlek commented on GitHub (Jul 1, 2020):

Hi.

This is a must for me. As it is now, I can't seem to be able to generate a client cert that would actually be usable with PgSQL, as PgSQL uses CN to identify users. mkcert certs don't have a CN...

@petr-motejlek commented on GitHub (Jul 1, 2020): Hi. This is a must for me. As it is now, I can't seem to be able to generate a client cert that would actually be usable with PgSQL, as PgSQL uses CN to identify users. mkcert certs don't have a CN...

kerem commented

2026-02-25 22:32:47 +03:00

Author

Owner

@FiloSottile commented on GitHub (Oct 25, 2020):

I understand that this is a real need, but I think part of mkcert's role in the ecosystem is to encourage movement towards modern usage. Applications should use DNS, IP, URL, or email SANs on client certificates as well, rather than rely on completely unstructured CNs.

It's very easy to fork mkcert for custom needs, and we'll make it even easier to build derived tools by making the root installation into a library, but the core tool will keep encouraging best practices.

@FiloSottile commented on GitHub (Oct 25, 2020): I understand that this is a real need, but I think part of mkcert's role in the ecosystem is to encourage movement towards modern usage. Applications should use DNS, IP, URL, or email SANs on client certificates as well, rather than rely on completely unstructured CNs. It's very easy to fork mkcert for custom needs, and we'll make it even easier to build derived tools by making the root installation into a library, but the core tool will keep encouraging best practices.

kerem commented

2026-02-25 22:32:47 +03:00

Author

Owner

@antong commented on GitHub (Oct 26, 2020):

I understand and agree. Thank you!

@antong commented on GitHub (Oct 26, 2020): I understand and agree. Thank you!

kerem commented

2026-02-25 22:32:47 +03:00

Author

Owner

@petr-motejlek commented on GitHub (Oct 30, 2020):

Tell that to our company who's OK with using a 20-year-old procedure :D

@petr-motejlek commented on GitHub (Oct 30, 2020): Tell that to our company who's OK with using a 20-year-old procedure :D

kerem commented

2026-02-25 22:32:47 +03:00

Author

Owner

@m2acgi commented on GitHub (Nov 16, 2023):

https://github.com/txthinking/mad can custom the cert O OU and CN

@m2acgi commented on GitHub (Nov 16, 2023): https://github.com/txthinking/mad can custom the cert O OU and CN

kerem commented

2026-02-25 22:32:47 +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 the relevant fields 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 the relevant fields 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.