How to obtain a cert without a common name?

Issuance Tech
#1

We submitted a CSR without a Common Name. The certificate issued, and when we inspected it, it had a Common Name (CN) set to the host cryptopp.com. The CSR had two Subject Alt Names (SAN) - cryptopp.com and www.cryptopp.com.

We want to use a CN=“Crypto++ Project”. Common names are displayed to the user and should be friendly names. The IETF is fine with a friendly name, but the CA/Browser Baseline Requirements does not allow it. However, both the BR and IETF make the CN optional so we omit it.

As an aside, the CA/Browser Baseline Requirements and the IETF intersect at CN=hostname is deprecated and discouraged (but not forbidden yet). There’s no need to place a hostname in the CN, especially since (1) the hostnames are in the SAN; and (2) both standards say not to do CN=hostname.

I visited the Certification Practice Statement (CPS) but did not see a treatment. I found something relevant in LE-SA-v1.2-November-15-2017.pdf, section 3.3, that says “The contents of Your Certificates will be based on the information You or Your ACME Client Software sends to ISRG”.

The web server operated for years with a certificate that omits the CN. There have never been any user complaints or operational problems. So we know it is fine in practice.

We would really like to use a certificate with either CN=“Crypto++ Project” or CN omitted.

How do request a certificate without a Common Name? Is it possible to do?

2 Likes
#2

As you know from the BRs, the CN must be a FQDN or IP address, so it can’t be an arbitrary label.

Based on this comment from May, it seems like Let’s Encrypt is of the belief that they have to force the CN from the SAN due to BR rules:

In staging/prod we use doNotForceCN: false for both the RA & CA config. Switching this to true is blocked on CABF work that will likely take considerable time.

2 Likes
#3

Note: another drawback of mandatory common name it that it prevent the creation of certificates containing only long DNS names:

1 Like
#4

Sort of - @jsha has more of the history/context here so I’ll tag him in advance to correct anything I get wrong :laughing:

My understanding is we can’t omit the CN all-together as it causes pretty considerable compatibility issues with a variety of client software. Our alternative was going to be to place something other than a domain identifier in the field, but a strict reading of the baseline requirements forbids this. Quoting @jsha’s reply in the thread @tdelmas linked:

To avoid creating compatibility problems, Let’s Encrypt never issues with an empty Subject. Another approach, which should be broadly compatible, would be to insert a “junk” field other than CommonName in the Subject. We originally thought to do this by copying the serial number field into the subject, but it’s been suggested that the Baseline Requirements would term this “Subject Identity Information,”

Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.

Since Let’s Encrypt uses the CA/Browser Forum domain-validated OID (2.23.140.1.2.1) in its certificates, the certificates are not supposed to have Subject Identity Information

So to connect back to @noloader’s question:

It is not possible at this time.

The web server operated for years with a certificate that omits the CN. There have never been any user complaints or operational problems. So we know it is fine in practice.

I don’t think you can necessarily draw this conclusion from one data point. Maybe you have had compatibility issues that weren’t reported to anyone. Maybe this server’s traffic is biased to specific regions/client software that would preclude incident. If Let’s Encrypt’s operational experience has been any indicator the web PKI has an extremely long tail and I’d be nervous about extrapolating too much on compatibility questions.

2 Likes
Compatibility testing of No Common Name
#5

Yep, @cpu’s got the gist of it. We’d want to do a little more formal investigation of the current client compatibility issues before we made “No CN + critical SANs” an option. That said, I don’t think it’s entirely out of the realm of possibility. Last time I looked, Chrome on Mac was the big blocker. That was a big enough client population to rule out that option at the time. However, I think that has since been fixed, either at the Chrome level or the macOS level. It might be worthwhile to spend some time testing various platforms.

Fortunately, testing compatibility is pretty easy: Just visit https://no-common-name.badssl.com/ on any given platform. If you don’t get a certificate error, that platform handles the “No CN” case properly. If someone wanted to start a new thread for compatibility testing of No CN, that would be really useful!

2 Likes
Compatibility testing of No Common Name
#6

I tried some tests on browserstack.com , I don’t know if it’s realistic but the results are encouraging:

image
image.png920×420 61.8 KB

#7

Thanks everyone.

@cpu > I don’t think you can necessarily draw this conclusion from one data point.

And

@jsha > We’d want to do a little more formal investigation of the current client compatibility issues before we made “No CN + critical SANs” an option.

If it helps, we don’t care about user agents that don’t know how to parse a well formed certificate in 2018. We are more than willing to accept the risk that a visitor may not be able to visit the site.

As far as I am concerned, the broken user agents can stay broken. Or the authors can fix them.

If you know of any broken user agents then I am happy to start filing bug reports. While I have no sympathy for them, I don’t believe in blind-siding them or leaving them unaware of their problem.

The bigger security engineering problem is CN=“Crypto++ Project” is not allowed. CN’s are displayed to users and they must be friendly names.

That’s a CA/Browser failure. About all I can say is, the cartel does what it wants in pursuit of profits, regardless of how negatively it affects security and interoperability with other standards.

#8

@tdelmas

Thanks.

I’m kind of surprised the Galaxy S2 is on the list. But then again, the Android browser was never too impressive. Do you know if anyone uses it? (I tried to use it several times but broke down and installed Firefox).

Windows XP with Firefox 3 is a bit tenuous. Firefox dropped XP and Vista support around version 52. Someone using FF3 likely has other problems to contend with.

By the way, the Crypto++ project still tests back to Windows XP with Visual Studio .Net compilers (2002 and 2003). So we certainly sympathize with anyone who has to use the platform. (And we know IE can no longer connect to microsoft.com on that platform).

#9

It may be worth noting browsers are increasingly dropping the convenience of this display (as part of their shift to drop EV/etc certificates). It takes multiple clicks to get to the CN on the current Chrome and Firefox builds.

Personally, I really like the idea of no common name or being able to use a customized string… but they’re effectively hidden by most software and rather hard to view now.

1 Like
#10

I think this thread has been adequately answered; let’s start a new thread with client compatibility testing results.

#11