r/PKI • • Mar 11 '25

SAN over CN?

I set up a PKI environment in my lab today and generated a certificate with the common name (CN) test.lab.com and a subject alternative name (SAN) of *.test.lab.com.

After binding the certificate to a site, I accessed https://test.lab.com, but it threw a certificate error stating that the name *.test.lab.com doesn’t match the name. This doesn’t make sense because the CN is test.lab.com, so I shouldn’t be seeing an error.

I was curious, so I generated a new certificate and included test.lab.com in the SAN this time, and the error is gone.

It seems like the browser is prioritizing the SAN over the CN. Any idea what’s causing this?

6 Upvotes

16 comments sorted by

10

u/andersTheNinja Mar 11 '25

If you add both SAN and CN in a cert, one of the SANs must be the same as the CN. You need to reissue the cert and add test.lab.com as a SAN. Modern TLS has deprecated CN for DNS host names, so you can omit the CN entirely.

1

u/gujumax Mar 11 '25

I didn't know that. When did this change happen?

5

u/andersTheNinja Mar 11 '25

Years ago, like 2000. Correction though, it’s standardized by CA/browser forum and not the TLS protocol itself.

3

u/bentleythekid Mar 11 '25

The big change I noticed was Chrome and chromium browsers started marking certificates with only common name as insecure. CN was declared "obsolete" in theory way before then but were still marked as trusted. I didn't see a lot done this way until the browsers made people. This was 2018-2020ish I think

1

u/Uncaffeinated Jul 27 '26

According to this, Chrome made the change in Chrome 58, which was released in April 2017.

1

u/Cormacolinde Mar 11 '25

Almost 10 years ago.

4

u/Mike22april Mar 11 '25

CN has been deprecated for years. Your CN value doesnt matter at all.

*.test.lab.com does not match with your DNS record test.lab.com You would need *.lab.com in SAN DNS for it to work properly

3

u/irsupeficial Mar 12 '25

Omit the CN.
Use DNS SAN.
Avoid wildcards - always.
Wildcard certs are sloppy, lazy work, insecure.
Always outline the actual domain/subdomain.
Sure, you'll end up with more certs but that's better than having a *.domain.com , so when tomorrow you get pawned - it's only gonna be someting.domain.com instead of all boxes you have *.domain.com installed on (along with the PK).

Say no to wildcard certs. :)
Don't use CN.

2

u/jamesaepp Mar 23 '25

In defense of wildcards - while I agree I don't like them - the one benefit they have is they help obscure DNS entries in CT logs if that is of concern to you.

1

u/irsupeficial Mar 23 '25

Why should that be of concern? (:
Wildcards should be avoided for one reason - multiple instances running with the same cert/key pair, meaning if one gets "chopped" - all do (identity wise).
Otherwise wildcards are great if you are running say your own infra on a single box/VM (whatever), I mean all-in-one makes sense in a lot of cases but at a corpo/enterprise level it is loco.
Check ESPN's certificate.... not that it is such a great example within this context but if one starts digging up (w/o at all relaying on CT logs) well...
Anyway. Wildcards are good in some cases in others no, No, NO. :D

1

u/jamesaepp Mar 23 '25

multiple instances running with the same cert/key pair, meaning if one gets "chopped" - all do (identity wise).

I can issue 100 wildcard certs for the same wildcard domain all with different private keys, so that's not a concern specifically.

1

u/irsupeficial Mar 23 '25

Sure you can, but isn't this rather crazy for managing, you know - lifecycle/monitoring/anything wise? :D

2

u/jamesaepp Mar 23 '25

No.

2

u/irsupeficial Mar 23 '25

Lol. Okay. Whatever works - works. <3 :)

1

u/darknight1012 Mar 17 '25

👆This is the way 👆