Why subject doesn't contain CN for generated certs?

[shadyabhi]

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.

mkcert/cert.go

Lines 61 to 64 in df15e0c

	Subject: pkix.Name{
	Organization: []string{"mkcert development certificate"},
	OrganizationalUnit: []string{userAndHostname},
	},

Later, for PKCS#12, there's a CommonName added but not for usual default options, why?

[FiloSottile]

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.

[shadyabhi]

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

[FiloSottile]

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.

[will]

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.

[marcgardent]

"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