6

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
      },
Improve this question
6
  • 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)
    – user15194
    Aug 19, 2016 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
    – makerofthings7
    Aug 20, 2016 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.
    – user15194
    Aug 21, 2016 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, 2016 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 192.0.2.123 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.
    – user
    Jun 30, 2017 at 8:09

2 Answers 2

Reset to default
5

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.

Improve this answer
0

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.

Improve this answer
6
  • 3
    Are you sure? Do you have a source? I read the opposite there: community.letsencrypt.org/t/…
    – Tom
    Aug 21, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .