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

Issuance Tech
1

Hi,

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;

$req->set_subject("/C=US/O=Acme/CN=foo.com/subjectAltName=DNS:foo.com/subjectAltName=DNS:a.foo.com");
$req->add_ext(Crypt::OpenSSL::PKCS10::NID_subject_alt_name,"DNS:foo.com");
$req->add_ext(Crypt::OpenSSL::PKCS10::NID_subject_alt_name,"DNS:a.foo.com");
$req->add_ext_final();
$req->sign();

print $req->get_pem_req();

which produces:
-----BEGIN CERTIFICATE REQUEST----- MIIB1zCCAUACAQAwXDELMAkGA1UEBhMCVVMxDTALBgNVBAoMBEFjbWUxEDAOBgNV BAMMB2Zvby5jb20xFDASBgNVHREMC0ROUzpmb28uY29tMRYwFAYDVR0RDA1ETlM6 YS5mb28uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDano364OhIBngN Z8UA3Su6v3xg5i3Wqh4l0Sy7jyATM0ECsHIkCf+S2SUq3MXmglOSwysItRwIJUQN Er9DdaXDc+n5WOniEt5feBemu4mqooI/+4m4O0C5gcCAR7AqGPT0RZ/QPYcZH1Da nR1H9k+fEfhrIge3csQpbj9u1n5j1wIDAQABoDswOQYJKoZIhvcNAQkOMSwwKjAS BgNVHREECzAJggdmb28uY29tMBQGA1UdEQQNMAuCCWEuZm9vLmNvbTANBgkqhkiG 9w0BAQsFAAOBgQAr9/FJBjDd3852gJqNzZIw4HK1BKoM3kmRIkyJYZ8WDvqm6i54 b/pnyz7hiVLsr9OJE8Pb7GGgRrwmtXg1MmWjkVdJDscRCjzOt9jhXH2tnxAK68gS 2HdyETzUqHkxrapW3Uv0F+IAwNPpJblPnK1HA3imd1HQhXBtNKEWWt9NaQ== -----END CERTIFICATE REQUEST-----

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

2

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…

3

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.

4

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?

5

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

6

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