Request: add subject CN for client certificates

[antong]

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).

[petr-motejlek]

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...

[FiloSottile]

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.

[antong]

I understand and agree. Thank you!

[petr-motejlek]

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

[m2acgi]

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