The order of Subject Alternative Names is not retained. I have observed this behaviour with all certificates issued by Let's Encrypt.
Example: I have a certificate with the common name
www.wordfeud-help.nl and the SANs
wordfeud-help.nl, www.wordfeud-help.nl. I would have expected the first domain (the common name) to come first in the SAN.
I use Certbot to request certificates. Certbot uses this logic in
acme.crypto_util.make_csr to create a CSR with the SANs:
extensions = [ crypto.X509Extension( b'subjectAltName', critical=False, value=', '.join('DNS:' + d for d in domains).encode('ascii') ), ]
This produces the SANs in the correct order:
>>> domains = ['www.wordfeud-help.nl', 'wordfeud-help.nl'] >>> ', '.join('DNS:' + d for d in domains).encode('ascii') b'DNS:www.wordfeud-help.nl, DNS:wordfeud-help.nl'
However, the resulting certificate's SANs are in a different order. This leads me to believe the 'issue' is not with Certbot.
I'm not sure what's standard practice here, but my Sectigo certificate SANs are in the same order as I passed to their ACME API.
Can anyone explain the reasoning behind this behaviour, and if I can circumvent this? I use a Certbot pre-hook to upload the certificate to an API, which requires the SANs in the certificate to be in the same order.