Struggling with subjectAltNames (SAN)

My ACME client appears to be functional now, i can get certificates however the certificates my client is getting are only valid for the CommonName and it seems that the SubjectAltName from the CSR is being ignored.

My guess is that the format i am using for specifying the SAN must not be valid; or maybe the feature is currently not working on the server side?

I keep checking my CSR online with each different format tried and it seems to be valid; however the certificates i get back seem to ignore any SAN other than the CommonName.

In one of my tests i omitted the SAN in the CSR entirely, and the online CSR checker verified that the SAN was not there, however the certificate i got back from the LE staging server still included a SAN with the same value as the CommonName even though the CSR did not include it…

Can anyone give me some guidance on the correct format to specify multiple domain names within the SubjectAltName property of the CSR?

Below are some of the formats i have tried:

SAN = DNS:www1.us.example.com,DNS:www2.fr.example.com,DNS:www3.jp.example.com
SAN = DNS:www1.us.example.com, DNS:www2.fr.example.com, DNS:www3.jp.example.com
SAN = {DNS:www1.us.example.com,DNS:www2.fr.example.com,DNS:www3.jp.example.com}
SAN = {DNS.1=www1.us.example.com,DNS.2=www2.fr.example.com,DNS.3=www3.jp.example.com}
SAN = {www1.us.example.com,www2.fr.example.com,www3.jp.example.com}

Do you expect anyone to be able to help without any specifics about how you’re generating the CSRs? Those lines don’t tell anything about that.

BTW, LE constructing a single SAN with your common name, even when you didn’t specify a SAN, is perfectly normal. It can construct a cert any way it wants and it can pick any data it’s willing to verify. You will find that it will strip any organisation you put in the CSR, too, for example.

I hypothesize that @tpenner is somehow trying to put these into the DN field as textual data (which wouldn’t survive into the actual CSR because there is no DN element called “SAN”) rather than using the X.509v3 subjectAltName extension. Just a random guess. I agree that we need to know how he is generating the CSR.

Alternatively, it would be helpful to see the openssl x509 -in example.pem -text -noout parsing of the CSR in question.

1 Like

The code i provided above could be considered Psuedo Code.

The actual command i am using to build the CSR is here, it takes two arrays of data for the CSR, properties and values. The properties array uses the code value for the CSR element, and the value is text.

For the SAN code element i am specifying 85 which is the Numerical ID that OpenSSL defines for SubjectAltName.
For the SAN value element i have tried specifying all of the formats i listed above.

I will check the output of the CSR in question now using OpenSSL, prior to now i had been using online tools for checking the CSR.

@schoen the comand you referenced:

openssl x509 -in csr.pem -text -noout 

Produced an error:

unable to load certificate
89550:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64/src/crypto/pem/pem_lib.c:648:Expecting: TRUSTED CERTIFICATE

So i used this command instead:

openssl req -in csr.pem -text -noout

which output

Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=macpro.tp.us.4d.com/subjectAltName={DNS:macpro.tp.us.4d.com,DNS:tpmac.4d.com,DNS:mac.tp.us.4d.com}
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:b6:b2:6f:d3:bc:6a:f4:c9:4a:89:a6:fb:05:97:
89:33:ab:bc:14:ef:2a:b8:51:f4:51:82:22:75:fb:
b4:3d:54:92:68:7e:51:4c:f8:3a:35:be:71:c3:fd:
be:57:d4:6c:bd:e4:19:74:d6:f7:56:24:88:fb:88:
d1:a1:56:e5:22:b7:fd:51:47:ba:3a:25:67:0e:ed:
94:c8:43:cb:21:17:cd:1c:25:e3:22:cc:49:e6:30:
52:a5:2d:45:14:de:8a:e2:0a:f7:c3:30:b0:4a:bf:
20:8a:d4:0e:5a:74:52:85:e9:7f:0d:46:5f:81:b6:
84:4d:28:6f:f5:7f:cb:14:53:dc:6e:3e:49:f0:fa:
d8:3d:28:ae:eb:bf:89:d3:8b:1b:95:37:c7:00:9f:
9f:8f:32:78:63:0b:4b:23:ff:f8:38:e6:19:31:5f:
91:da:17:e5:b7:e7:5c:13:1f:fe:84:5e:03:a4:16:
2b:7c:d0:61:64:14:8b:2f:00:8a:b1:b1:73:ea:72:
58:95:c5:f8:bd:52:6d:de:b5:f2:48:04:7e:d9:6d:
ea:10:00:b1:af:a4:19:1a:c5:f5:14:32:8c:d0:0d:
40:71:f4:75:e0:cd:79:81:45:a8:10:c8:af:5e:b8:
14:02:29:af:0f:c2:4d:03:3b:c6:38:4a:96:6a:5c:
48:85
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
94:85:52:04:e2:be:af:e4:70:53:e3:de:3f:58:7d:38:12:e9:
c1:bd:32:30:ad:70:6d:f2:17:4b:65:7c:ce:73:50:87:dd:bf:
f5:07:24:bd:cd:35:a7:dc:23:22:f1:2a:a7:bb:12:10:ce:a9:
da:1d:be:b5:69:e2:4f:02:63:f0:ce:91:30:9b:b4:81:9e:2f:
c5:98:16:79:d6:5b:b8:87:80:bb:d0:a6:4c:99:83:82:a2:1d:
db:4d:a5:57:5f:ee:13:a6:be:7d:4a:9d:c0:9c:ad:4c:25:50:
ed:d5:58:18:e3:51:eb:53:f9:8c:db:76:bc:ad:e2:78:98:3c:
48:2b:14:54:f6:ec:15:6a:42:ac:49:7b:df:bb:b3:d9:e5:40:
c5:74:db:ab:ef:a0:6b:62:01:fb:ed:b9:1e:1f:f7:21:24:83:
85:ba:fc:94:e6:dc:8c:e5:eb:c2:2c:8c:ac:04:c0:eb:cb:48:
6f:60:7d:ae:c0:fd:41:4e:0f:84:eb:68:1f:5d:6a:ea:2c:b5:
10:25:1d:56:6c:ea:3c:21:43:22:83:2d:01:4a:f9:f7:4e:de:
56:81:c3:21:84:da:d0:ec:8b:91:06:ec:18:d4:41:df:a2:ca:
b6:51:c6:c4:0a:e4:d9:d8:86:bf:a1:ca:b2:a6:be:75:12:59:
f8:e1:15:81

The main difference is that i used the req option instead of x509 because i was checking the certificate request, not the actual certificate...

This is wrong. The SAN does not go into the Subject. It's an extension. It should look like

    Requested Extensions:
        X509v3 Subject Alternative Name:
            DNS:[...], DNS:[...], DNS:[...]

somewhere below the public key.

1 Like

@TCM This seems very helpful.

It looks like the command i was using does not properly support x509v3 extensions since it is adding this data in to the wrong location of the CSR.

Seems like i will need to switch to using a different tool (such as OpenSSL CLI) to create the the CSR.

Thank you very much for this analysis

My guess about the problem above was right! :slight_smile:

@tpenner, sorry for mistakenly saying openssl x509 instead of openssl req; thanks for figuring that out and providing the output.

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