Bug (?): Multiple 'X509v3 Subject Alternative Name' extension entries truncated to one



My hosting provider uses the Crypt::OpenSSL::PKCS10 perl package to generate CSRs, along the lines of:

use Crypt::OpenSSL::PKCS10 qw( :const );

my $req = Crypt::OpenSSL::PKCS10->new;


print $req->get_pem_req();

which produces:

Running this though openssl req -noout -text gives:

Certificate Request: Data: Version: 0 (0x0) Subject: C=US, O=Acme, CN=foo.com/subjectAltName=DNS:foo.com/subjectAltName=DNS:a.foo.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c0:e1:5e:c6:ee:dd:a2:79:34:41:14:7d:8b:37: 87:41:e0:ac:31:b0:4b:2a:e3:30:c8:b5:7f:8e:f4: 7d:d4:54:39:27:86:73:75:00:b0:99:d1:c3:90:b3: d0:1c:2f:c8:15:22:b6:f9:d4:c3:7b:fb:9c:9b:b5: 9a:c4:8f:89:ef:fb:ee:da:32:ec:00:f2:67:c0:c0: 6e:a6:27:03:44:2d:b5:b4:82:9e:c8:2d:7a:a8:a5: 55:22:a8:ac:a1:66:cf:64:05:64:d6:da:a4:fc:6d: b9:ae:3f:16:74:a9:3d:00:16:e9:f6:b8:68:a6:f6: 5d:c4:e2:2a:8f:d2:79:37:cf Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:foo.com X509v3 Subject Alternative Name: DNS:a.foo.com Signature Algorithm: sha256WithRSAEncryption 34:8f:c2:ce:91:26:e2:d1:aa:96:36:d0:5c:43:48:98:f9:bd: 7a:1a:06:bc:c3:8c:24:78:48:ad:01:84:3f:0e:d0:01:1f:d7: ab:99:f5:76:91:ce:3a:16:09:d3:22:2f:da:cc:ca:07:0f:fe: d7:a6:51:c6:0f:e1:18:3a:8c:04:e2:35:59:06:64:89:02:ac: bb:50:1c:ec:c1:e8:f5:95:f4:b6:f3:1d:3d:ed:07:b1:d8:3b: 03:6c:d3:f2:e8:9a:a4:5a:51:0a:7c:9f:a6:b9:c6:e1:86:81: d1:fd:dc:47:48:a5:d3:e7:c2:0e:61:00:66:10:25:3c:d9:02: 32:b1

Note the two X509v3 Subject Alternative Name entries, instead of a single entry with DNS:foo.com, DNS:a.foo.com.

When I pass this CSR to the new-cert API endpoint (via acme-tiny), the resulting signed certificate only has a single X509v3 Subject Alternative Name entry (which is fine), but the multiple X509v3 Subject Alternative Name entries in the CSR have not been squashed into that single entry.

Assuming a CSR with multiple X509v3 Subject Alternative Name is well formed (couldn’t find anything in the specs saying it wasn’t), I’d expect Let’s Encrypt to either keep the multiple SAN entries as is, or squash them into one. Truncating them seems like a bug?

See also https://github.com/diafygi/acme-tiny/pull/105/commits/820a04ac3fbe72e649812193a04585ffbfc44d0f

Tor Arne


I don’t know for the CSR, but multiple instances of the same extension are explicitly forbidden in a X.509 certificate (see RFC 5280 §4.2, “A certificate MUST NOT include more than one instance of a particular extension.”).

Given that, I would assume that multiple instances of the same extension is also forbidden in the CSR…


Why do you put the SAN in the subject field? And I’d recommend just using a comma separated list in only one SAN extension.


This is the way the CSR was delivered to me by my web host (SAN in subject, and multiple SAN extensions), which is why I’m wondering if such as CSR is valid, or if it’s a bug on the Let’s Encrypt side.

If it’s the former, then perhaps LE should at least warn about the invalid CSR instead of truncating?


I more often try to send people in the other direction (from the GitHub bug trackers to here), but if you believe your CSR is valid and Let’s Encrypt is ignoring part of its contents, it might be helpful to file an issue on the boulder bug tracker at


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.