Certificates with serialNumber in subject

Server
1

Per https://github.com/letsencrypt/boulder/issues/1488, we’ve fixed Boulder so that it won’t issue a certificate with a CN greater than 64 characters in length. However, this creates a problem for hostnames longer than 64 characters (fortunately they are relatively rare).

In order to issue for a hostname longer than 64 characters, we’d have to include the hostname as a dNSName in the subjectAltNames extension, and omit the hostname from the Subject. This is fine, since CN in Subject has been deprecated for a long time. However, Subject does have to be non-empty.

Here’s our approach in the short term: We’re going to be adding serialNumber to the Subject field of all certificates. For now, we will continue to include CN in the Subject, but only if the CN field was present in the CSR.

When we receive a CSR that includes a CN, we will continue to use that CN both in Subject and in subjectAltNames. If we receive a CSR with no CN (that is, all the names in the CSR are in subjectAltNames), we will issue certificate with a Subject containing only a serialNumber field. Using the official Python client, you would get:

        Subject: CN=www.example.com/serialNumber=fa85bc05fcfd90b51cd2ebd1025153318362

However, if you constructed your own CSR with subjectAltNames but no CN (for instance, because your hostname is longer than 64 characters), you could get:

        Subject: serialNumber=fa85bc05fcfd90b51cd2ebd1025153318362

This change is currently active in staging. You can get a certificate without CN with a command like this (substitute example.com for your own domain name):

openssl req -new -nodes -keyout key.pem -sha256 -subj "/" -outform der -out csr.der -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(echo -e "[SAN]\nsubjectAltName=DNS:example.com"))
./letsencrypt-auto --test-csr --csr csr.der

I’d appreciate any help testing out various clients. Please let us know if you’re aware of any client that will fail when presented with a certificate that either (a) has a serialNumber in the Subject, or (b) has no CN in the Subject.

Thanks,
Jacob

3 Likes
2

Nice that there is an fix for this problem. But i would prefer that the serialNumber is only included if the Subject would be empty otherwise. Because some software print the Subject and the lines get unnecessary long.

3

The “Issued to” section in for example iceweasel lists CN, O, OU and Serial number (the latter also works if the serial number is not in the Subject field).

If CN can no longer be set by ‘us’, there is no way anymore to fill anything in the default view of “Issued to” of a certificate (the SANs are hidden far away). I understand that you cannot allow us to fill O or OU because these are DV-, and not EV- or whatever certificates.

Note that the current way staging works is fine with me, at least iceweasel just shows the CN fine, my objection is specifically to the plan to not allow us to set the CN at all anymore.

4

The current short-term plan is to make Subject optional. If your CSR includes a CN, and it matches a hostname you have an authorization for, the resulting certificate will have that CN in the Subject as well as in SAN. If your CSR does not include a CN, the Subject will include only serialNumber.

We haven’t yet decided what the long term plan is regarding whether to prohibit CN in the Subject entirely. Your feedback is valuable, thanks! Can you tell me more about your use case?

5

Hi,
i did not fill the SR but i can remember that there is an length limit for CN.
So this could cause that there would be no valid SAN for the CN.
Prohibiting CN in the i think is an bad idea because this is shown first to
the user if he look at an certificate. So if an company have multiple domains
they could prever that there company Domain name is shown in the subject.
If not the subject does not provide any identification to what side the cert
may belong to.

So i think the short-term would be nice for long term to.
Maybe allow optional email in the subject if the mail is verified via an extra check.
(This would not mean that the certificate is valid for smime)

1 Like
6

My usecase is: having a dozen or so subdomains, for my personal domain, for a really really tiny place in the internet. My main concern is: I would expect & want a user who clicks ‘View certificate’ to be able to easily verify that ‘yes, this certificate is for the website I’m looking at, and yeah, I recognize the domain as to be the one I’m dealing with’. Because the default view in most browsers is to NOT show certificate details when clicking the icon next to ‘https’ (only issuer info and metadata), and the ‘details/more information/view certificate’ button/link leads to a place where you can immediately see “CN, O, OU and serial”, but not SAN. Of course I preferably would have had my realname in the O= field, but that’s not going to happen with a free service, I’m afraid, so hence settling for CN which is sort of my name anyway.

As a side-note, I came to this forum initially to alert you guys about a behaviour change staging vs production, because when not requesting a CN (but having my primary domain first in the SAN list), I got ‘admin.example.org’ as CN in production (alphabetically first), but nothing in staging. I now learned the cause, and that in both production and staging I can select the CN even when using a SAN list, as long as I specify it. I’d like to retain this possibility.

7

Doesn't the top-level browser UI tell you this? If the certificate is not valid for the domain in the URL bar, the browser will prevent you from loading the page.

8

Hi @jsha

Is this fix in production? I’m getting this error:

{
   "type": "urn:acme:error:malformed",
   "detail": "Error creating new cert :: CN was longer than 64 bytes",
   "status": 400
}

I get this when submitting a CSR without a Subject field and with a SAN that is >64bytes. (I double checked with openssl asn1parse and the CSR being submitted certainly does not appear to have a Subject field)

Let me know if more information is required.

9

Hi @voutasaurus,

I’m afraid we haven’t yet put the fix in production. We get hung up on wanting to double-check standards compliance, and wound up de-prioritizing it. One short-term workaround is to put multiple hostnames in your cert, of which one hostname is under 64 characters and is present in the CSR’s CN. Not ideal, I know.

10

Thanks @jsha

Hope the LE team gets time to sort out the finer details.

Thanks for the workaround. The workaround may be what we end up doing but at that point I think for us it might be driven by specific user request and not on by default. I’ll have to discuss it with my team. We run an edge service and it would certainly be surprising to customers to see an unexpected common name in a certificate being served for their website. Some of our customers may be fine with it but I suspect others will want to work with us to use a specific subject name at which point we’d probably have to do something a little more manual.

11

Hi @jsha,

is there are any news regarding putting the fix in production?

Regards,
Neven

12

Not yet, sorry! We’ve been distracted by other projects.

13

Is there an update on this yet or any ETA when we can expect this change to hit production?

14

Nope, sorry, not yet. :frowning:

15

An update on this topic: The CA/Browser Forum Baseline Requirements probably conflict with our original plan to put serialNumber in certificate subjects as an alternative to CommonName. Peter Bowen of Amazon put forth a ballot at the Forum to codify dnQualifier for this purpose. Unfortunately the ballot failed, partly due to concerns about whether this was a proper use of dnQualifier, and partly due to compatibility issues Peter discovered after the ballot was posted.

Peter has subsequently proposed new directions to solve the problem. If you’re interested, you can follow along by subscribing the the CA/Browser Forum public mailing list. Unfortunately, until a ballot passes, we are probably blocked on this front.

4 Likes