subjectAltName Certificates

Issuance Policy
1

Will it be possible to get SAN certificates?

1 Like
2

Yes, that is going to be a readily available option in the client, and fully supported by the CA.

3 Likes
3

You’re encouraged to put as many names into a given SAN as you like. Boulder’s current default limit is something like 1000 (see “maxNames” in boulder-config.json), though Let’s Encrypt hasn’t announced their limit yet.

Still, it’s probably going to be pretty big.

2 Likes
4

What are the limits at the X.509 level? Are there any additional limits from the Certification Policy or the Baseline Requirements?

1 Like
5

The Baseline Requirements, version 1.3.0, section 7.1.4.2.1 only specify that the SAN exist and have the CN as an entry, there is no upper bound. RFC3280, section 4.2.1.7 defines it as a SEQUENCE SIZE (1..MAX) which means it’s implementation independent. For Firefox, for example, it appears that the max is not enforced so much the number of SAN entries, but rather the total size of the certificate.

We may see compatibility issues if we try a huge SAN, but it’s probably easiest to find out by trying, and if it doesn’t work, asking the client to reissue two certs instead of one only takes a few minutes.

1 Like
6

This would be a great area for community research. If someone can find out the max certificate sizes for various common clients (Firefox, Chrome, IE, Safari, Java, mobile browsers), the client can suggest a default size limit that will maximize compatibility.

1 Like
7

I keep reading SAN and thinking you need a certificate for your storage-area network :sweat_smile:

4 Likes
8

I’d bet most TLS client implementations will parse quite a few SANs before failing, the real issue seems to be choosing a number that avoids unnecessarily bloating the size of the certificate itself. A good example here can be taken from Cloudflare who bundle SANs for their ‘Universal SSL’ service into a single certificate and seem to have a limit of ~47 SANs per cert.

1 Like
9

Based on a quick test openssl with happily parse a cert with over 1000 SANs.

1 Like
10

Unrelated to LE specifically: as @roland mentioned, having a huge certificate (with lots and lots of SAN entries) will — AFAIK — bloat the transfer size required for each SSL handshake, and will be bad for performance, so I wouldn’t really recommend that.

4 Likes
11

true indeed.. but that's what ECC 256bit SSL certs are good for too = smaller sizes :smiley:

12

By SANs you mean LE will issue a certificate as follows:

CN=domain.com
SANs=www.domain.com, otherdomain.org, www.otherdomain.org

So, my question is: will we be able to add completely different domains as SANs?

13

Yep, as long as all domains included pass validation.

14

I was able to get a certificate with 85 domains live. Then I went for 165 and got this error back:

Error signing certificate: 400 {“type”:“urn:acme:error:malformed”,“detail”:“Error creating new cert :: Certificate request has 165 names, maximum is 100.”,“status”:400}

Is this a limitation of the client I’m using or a limit from somewhere else?

Thanks - this is a great project!

15

This is a limitation set in Boulder, the certificate authority server of Let’s Encrypt. There’s no way to bypass that. Perhaps they’ll raise the limit to something else, but at this time, it’s set to 100.

You can find the piece of code in the source code of Boulder on GitHub:

https://github.com/letsencrypt/boulder/blob/master/ca/certificate-authority.go#L274

1 Like
16

Things can get a bit weird with some clients when the SAN field gets too big.

1 Like
17

Which is why it would be nice if we could put wild card entries into the SAN (i.e. *.domain.com, *.domain.net, domain.net, *.domain.org, domain.org)