starred/mkcert

Fork 0

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

[GH-ISSUE #205] Why subject doesn't contain CN for generated certs? #130

New issue

Closed

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

kerem commented

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

Owner

Originally created by @shadyabhi on GitHub (Oct 10, 2019).
Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/205

The typical generated cert via mkcert has subject as:-

subject= /O=mkcert development certificate/OU=username@hostname

While most web certs also have a CommonName attribute.

➤ openssl s_client -servername www.google.com -connect "www.google.com:443" </dev/null 2>&1| openssl x509 -noout -subject -issuer
subject= /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer= /C=US/O=Google Trust Services/CN=GTS CA 1O1

Is there a reason behind this design choice?

I can see that CommonName is ignored while creating the cert.
github.com/FiloSottile/mkcert@df15e0c1ef/cert.go (L61-L64)
Later, for PKCS#12, there's a CommonName added but not for usual default options, why?

Originally created by @shadyabhi on GitHub (Oct 10, 2019). Original GitHub issue: https://github.com/FiloSottile/mkcert/issues/205 The typical generated cert via mkcert has subject as:- ``` subject= /O=mkcert development certificate/OU=username@hostname ``` While most web certs also have a CommonName attribute. ``` ➤ openssl s_client -servername www.google.com -connect "www.google.com:443" </dev/null 2>&1| openssl x509 -noout -subject -issuer subject= /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com issuer= /C=US/O=Google Trust Services/CN=GTS CA 1O1 ``` Is there a reason behind this design choice? I can see that CommonName is ignored while creating the cert. https://github.com/FiloSottile/mkcert/blob/df15e0c1efd3b2f372170e6866cac54df720e724/cert.go#L61-L64 Later, for PKCS#12, there's a CommonName added but not for usual default options, why?

kerem

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

closed this issue
added the
question
label

kerem commented

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

Author

Owner

@FiloSottile commented on GitHub (Oct 13, 2019):

Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. It's an overloaded unconstrained field that should stop being used for web certificates.

Unfortunately, IIS and iOS use it in their UIs, so mkcert sets it in the root and in PKCS#12 certificates.

@FiloSottile commented on GitHub (Oct 13, 2019): Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. It's an overloaded unconstrained field that should stop being used for web certificates. Unfortunately, IIS and iOS use it in their UIs, so mkcert sets it in the root and in PKCS#12 certificates.

kerem commented

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

Author

Owner

@shadyabhi commented on GitHub (Oct 14, 2019):

@FiloSottile Would you accept a PR to add CN if the user needs it or is that out of scope for this project and the direction it wants to head in?

My use-case:-

I'm writing tests and used this amazing utility to create test certs. My production certs have a CN field and I would like the same to exist in test certs too. It's a valid point that it's been deprecated but all major companies still have certs that have CN field in the subject, until today. In my opinion, it should be provided as an option if the user needs it.

@shadyabhi commented on GitHub (Oct 14, 2019): @FiloSottile Would you accept a PR to add CN if the user needs it or is that out of scope for this project and the direction it wants to head in? My use-case:- I'm writing tests and used this amazing utility to create test certs. My production certs have a `CN` field and I would like the same to exist in test certs too. It's a valid point that it's been deprecated but all major companies still have certs that have CN field in the subject, until today. In my opinion, it should be provided as an option if the user needs it.

kerem commented

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

Author

Owner

@FiloSottile commented on GitHub (Oct 16, 2019):

Unfortunately, making the certificates look like production certificates is out of scope. The CN is a fairly small change, but mkcert certificates are pretty opinionated, and mkcert would have to grow a large number of config options to allow everyone to make certificates similar to those they already have. I have seen a few forks made in these situations, and I think that's the way to go, as it gives you complete control over how the certificates look like.

@FiloSottile commented on GitHub (Oct 16, 2019): Unfortunately, making the certificates look like production certificates is out of scope. The CN is a fairly small change, but mkcert certificates are pretty opinionated, and mkcert would have to grow a large number of config options to allow everyone to make certificates similar to those they already have. I have seen a few forks made in these situations, and I think that's the way to go, as it gives you complete control over how the certificates look like.

kerem commented

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

Author

Owner

@will commented on GitHub (Jun 1, 2023):

I was hoping to switch from my stack of incomprehensible openssl commands to mkcert to generate both server certs (this works) and also client certs (this does not work) to test my postgres driver.

It is impossible to use mkcert to generate postgres client certs because postgres uses the cn attribute to map the provided client cert to the requested database user name https://www.postgresql.org/docs/current/auth-cert.html

I appreciate that this is an opinionated tool, and you do not want to support this feature. But I figured maybe this was a use of cn you were not aware of. I will return to my nightmare stack of openssl commands.

@will commented on GitHub (Jun 1, 2023): I was hoping to switch from my stack of [incomprehensible `openssl` commands](https://github.com/will/crystal-pg/blob/cafe5bfee163355f56456946b8dbf402235d7696/.github/setup.sh#L13-L19) to `mkcert` to generate both server certs (this works) and also client certs (this does not work) to test [my postgres driver](github.com/will/crystal-pg). It is impossible to use `mkcert` to generate postgres client certs because postgres uses the cn attribute to map the provided client cert to the requested database user name https://www.postgresql.org/docs/current/auth-cert.html I appreciate that this is an opinionated tool, and you do not want to support this feature. But I figured maybe this was a use of cn you were not aware of. I will return to my nightmare stack of openssl commands.

kerem commented

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

Author

Owner

@marcgardent commented on GitHub (Oct 1, 2024):

"Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. "

curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) 
More details here: https://curl.se/docs/sslcerts.html

curl, chrome and lot of program havent yet received the mkcert's service note.

In additionnaly, we install the ROOT certificate in the system store to able to suppress SSL errors.
this no make sense if the CN not set also.

Windows alternative with valid certificate! :) OMG....

choco install openssl
choco upgrade openssl
$domain="mydomain.local"
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout "$($domain).key" -out "$($domain).crt" -subj "/CN=$($domain)." -addext "subjectAltName=DNS:$($domain),DNS:*.$($domain),IP:127.0.0.1"
Import-Certificate -FilePath .\$($domain).crt -CertStoreLocation Cert:\CurrentUser\Root

@marcgardent commented on GitHub (Oct 1, 2024): "Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. " curl: (60) schannel: SNI or certificate check failed: SEC_E_WRONG_PRINCIPAL (0x80090322) More details here: https://curl.se/docs/sslcerts.html curl, chrome and lot of program havent yet received the mkcert's service note. In additionnaly, we install the ROOT certificate in the system store to able to suppress SSL errors. this no make sense if the CN not set also. Windows alternative with valid certificate! :) OMG.... ```powershell choco install openssl choco upgrade openssl $domain="mydomain.local" openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout "$($domain).key" -out "$($domain).crt" -subj "/CN=$($domain)." -addext "subjectAltName=DNS:$($domain),DNS:*.$($domain),IP:127.0.0.1" Import-Certificate -FilePath .\$($domain).crt -CertStoreLocation Cert:\CurrentUser\Root ```

kerem commented

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

Author

Owner

@ToxicMushroom commented on GitHub (Dec 27, 2025):

Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. It's an overloaded unconstrained field that should stop being used for web certificates.

Unfortunately, IIS and iOS use it in their UIs, so mkcert sets it in the root and in PKCS#12 certificates.

Could you provide a link ?
I found https://datatracker.ietf.org/doc/html/rfc2818#section-3.1but it is about http over TLS, but how does that apply to strange technologies like LDAPS ?

@ToxicMushroom commented on GitHub (Dec 27, 2025): > Common Name has been deprecated for about 20 years, and is now ignored by major X.509 verifiers. It's an overloaded unconstrained field that should stop being used for web certificates. > > Unfortunately, IIS and iOS use it in their UIs, so mkcert sets it in the root and in PKCS#12 certificates. Could you provide a link ? I found https://datatracker.ietf.org/doc/html/rfc2818#section-3.1but it is about http over TLS, but how does that apply to strange technologies like LDAPS ?