subject alternative names (no vhosting)

[joernclausen]

I'd like to register a hostname with its FQDN and a more user friendly CNAME in one certificate, no vhosting involved, using DNS challenge. I can request certificates for either the FQDN or the CNAME, but not both. I tried

ServerName CNAME
MDomain CNAME FQDN manual

but this generates two challenges (i.e. two TXT records), not one. As far as I can see, Let's Encrypt challenges only FQDN and fails. In our environment, both _acme-challenge.FQDN and _acme-challenge.CNAME point to a third host that has the sole purpose of collecting ACME-DNS challenges, so both TXT records should be visible for either challenge (this method is known to work with e.g. acme.sh).

[icing]

Could you given an example, like with example.com what exactly you are trying to do?

[joernclausen]

Suppose I have a machine "minion123.example.com" and a CNAME "www.example.com" pointing to it:

minion123.example.com     A        192.168.21.43
www.example.com           CNAME    minion123.example.com

The machine is running a single, non-vhosted webserver, and normally it would be accessed as "https://www.example.com". But I also want "https://minion123.example.com" to work. I do this by requesting a certificate for "www.example.com" with "minion123.example.com" as additional Subject Alternative Name. The corresponding config file for openssl would contain

subjectAltName = DNS:www.example.com, DNS:minion123.example.com

and the certificate would contain

X509v3 Subject Alternative Name:
   DNS:www.example.com, DNS:minion123.example.com

How do I tell mod_md that I want this? I had hoped that

MDomain www.example.com minion123.example.com

would do the trick - even though "minion123" is nowhere else mentioned in the Apache configuration.

[icing]

If you do not use virtual hosts, you might need to configure MDBaseServer, see https://github.com/icing/mod_md#mdbaseserver

Usually, mod_md does not mess with the base server configuration, only the virtual hosts. That may be the cause here. Otherwise, one can add other DNS names (CNAME or A does not matter) to an MDomain to get a certificate for all of them.

If the problem persists, you'll find a file job.json in the md/stagin/www.example.cm directory which should tell us more what exactly did happen when the module tried to get a certificate.

[joernclausen]

Sorry, I missed MDBaseServer completely. I added MDBaseServer CNAME to the example in the first comment, but as far as I can tell, the behavior is the same.

md/domains contains only one subdirectory (CNAME), and md.json looks promissing:

{
  "name": "CNAME"
  "domains": [
    "CNAME"
    "FQDN"
  ]
...

The details from job.json (in chronological order) show:

        "detail": "Checking staging area"
        "detail": "Resetting staging area"
        "detail": "Assessing current status"
        "detail": "Contacting ACME server for CNAME at https://acme-staging-v02.api.letsencrypt.org/directory"
        "detail": "Resetting staging for CNAME"
        "detail": "Driving ACME protocol for renewal of CNAME"
        "detail": "Selecting account to use for CNAME"
        "detail": "Creating new ACME account for CNAME"
        "detail": "Creating new order"
        "detail": "Starting challenges for domains"
        "detail": "Setting up challenge 'dns-01' for domain CNAME"
        "detail": "Setting up challenge 'dns-01' for domain FQDN"
        "detail": "Monitoring challenge status for CNAME"
        "detail": "Monitoring challenge status for CNAME: domain authorization for CNAME is valid"
        "detail": "Monitoring challenge status for CNAME: domain authorization for FQDN failed with state 3"
        "detail": "domain authorization for FQDN failed with state 3"
        "detail": "Monitoring challenge status for CNAME"
        "detail": "Checking staging area"
        "detail": "Assessing current status"
        "detail": "Contacting ACME server for CNAME at https://acme-staging-v02.api.letsencrypt.org/directory"
        "detail": "Driving ACME protocol for renewal of CNAME"
        "detail": "Selecting account to use for CNAME"
        "detail": "Loaded order from staging"
        "detail": "Starting challenges for domains"
        "detail": "Starting challenges for domains: unexpected AUTHZ state 3 for domain FQDN"
        "detail": "unexpected AUTHZ state 3 for domain FQDN"
        "detail": "Starting challenges for domains"
        "detail": "Checking staging area"
        "detail": "Assessing current status"
        "detail": "Contacting ACME server for CNAME at https://acme-staging-v02.api.letsencrypt.org/directory"
        "detail": "Driving ACME protocol for renewal of CNAME"
        "detail": "Selecting account to use for CNAME"
        "detail": "Loaded order from staging"
        "detail": "Starting challenges for domains"
        "detail": "Starting challenges for domains: unexpected AUTHZ state 3 for domain FQDN"
        "detail": "unexpected AUTHZ state 3 for domain FQDN"

Two TXT records are created. I am not sure if the second Monitoring challenge status for CNAME should read Monitoring challenge status for FQDN? And once more: Both TXTs are attached to the same object, i.e. requesting TXT of either _acme-challenge.CNAME or _acme-challenge.FQDN would always return both of them.

(BTW: I wrongly assumed, that for one certificate only one challenge is needed, but a little more thinking made me realize, that of course Let's Encrypt needs to check every SAN. When you know it, it's obvious...)

[icing]

Thanks for the details. This seems to indicate that Let's Encrypt is not happy with the TXTs it sees. AUTHZ state 3 means that the challenge for FQDN was not answered correcty from their point of view.

(The CNAME appears everywhere as the module uses the first DNS name as the name of the whole thing, e.g. the MDomain)

I think you should look and ask around at https://community.letsencrypt.org where there are a many helpful people who have more experience in the DNS challenges than me.

[joernclausen]

Thanks, I'll try to investigate further. We have used this scenario successfully with acme.sh in our environment, though.

[icing]

Maybe the order of challenge setup and verification is different with acme.sh. As you see in the logs, mod_md does the setup for all domains and then monitors the status at LE.

The AUTHZ state 3 means invalid. LE only gives this, when it has seen the wrong challenge. If the challenge is missing, it will wait and retry. I am not sure of the CNAME setting could cause LE to find the wrong TXT record when both CNAME and FQDN have challenge TXTs set.

[icing]

Closed as being stale.