I'm using ngrok to demonstrate the ACME protocol on IIS/Windows. However, this service prefers CNAMEs over A records.

In debugging the interaction it seems that ACME only allows for A records. What is the security rationale for this behavior? What alternative is there?

Error message here:

      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
        "status": 400
  • 3
    fwiw, there is a dns-01 challenge as well, which uses txt records. However, it's not supported in the official client (certbot) until the next release (0.9.0) – eez0 Aug 19 '16 at 19:54
  • @Ay0 Is that subject to signature misuse as described here: mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc - The ACME Draft RFC has a warning on a few verification methods – goodguys_activate Aug 20 '16 at 4:21
  • that message is from a year ago, maybe something was already fixed. Let's Encrypt servers officially started to support this challenge at the beginning of this year. – eez0 Aug 21 '16 at 10:48
  • 1
    I read SERVFAIL. Shouldn't that be NXDOMAIN instead? Even if there is no such A record? DNS server troubles maybe? – StackzOfZtuff Sep 21 '16 at 12:54
  • @StackzOfZtuff In DNS, NXDOMAIN means that the RRname doesn't exist, whereas SERVFAIL means that the DNS server experienced some kind of problem during name resolution. If the RRname exists but does not contain any RR of the requested type (for example, you have a.example.com. A but not a.example.com. AAAA 2001:db8::3, and you explicitly ask for the AAAA) then you will get a NOERROR response back with an empty answer section. Keep in mind that combining CNAME with RRs of any other type is strongly discouraged, and many resolvers may balk at it. – a CVn Jun 30 '17 at 8:09

The answer by sebastian nielsen is wrong insofar that the security hole was in an unrelated service called startencrypt. The implication that Letsencrypt doesn't support CNAME records is also incorrect as verified by this thread and several others where Letsencrypt moderators assure people that they do support CNAME records. In fact I have just passed verification for a subdomain that I have pointed at an Azure VM by using a CNAME record.

The error message certbot gives, when something is wrong is pretty misleading though and I could not find anything in the official docs about CNAME support, leading to all this confusion.


The reason for this, is that its possible to generate certificates for sites you don't own if you allow CNAME.

There was a security hole, where you could setup a own CNAME like "yoursite.com CNAME google.com" and then was able to generate certificate for google.com. The same problem existed with redirects, where you could set up a redirect and cause a unauthorized certificate to be issued.

However, instead of fixing the actual hole by re-verifying the adress after stumbling upon a CNAME/redirect, they simply blocked out so redirects and CNAMEs are not allowed.

  • 3
    Are you sure? Do you have a source? I read the opposite there: community.letsencrypt.org/t/… – Tom Aug 21 '16 at 16:55
  • What I have read on multiple pages, that this has been a s ecurity issue allowing generation for sites you don't own. There might be possible that Let's encrypt have now fixed the underlying hole and enabled the CNAME. – sebastian nielsen Aug 21 '16 at 19:23
  • 2
    It may be a security issue if you set your CNAME to a site you don't own, owned by somebody you don't trust. In the same way than setting your A record to an ip you don't own. I am wrong? – Tom Aug 21 '16 at 19:31
  • 1
    The difference was that if you set your A record to a IP you don't own, you would still get a certificate for the domain you own. But with CNAMEs/redirects, there was a problem since the implementation updated the domain to the one in the CNAME/redirect, without also revalidating that the user did really own the "new" domain. For example Startencrypt had such a vulnerability, you can read about it here: computest.nl/blog/startencrypt-considered-harmful-today – sebastian nielsen Aug 21 '16 at 19:57
  • If you set up a A record to a domain you don't own they can generate certificate for your domain. The Startencrypt vulnerability is if you setup a redirect to a domain you don't own, they accepted to give them a certificate for your domain – Tom Aug 21 '16 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.