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
      },
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 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) – The Illusive Man Aug 19 '16 at 19:54
  • @Ay0 Is that subject to signature misuse as described here: https://mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4Yc - The ACME Draft RFC has a warning on a few verification methods – makerofthings7 Aug 20 '16 at 04: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. – The Illusive Man 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 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 '17 at 08:09
  • @MichaelKjörling: I agree. But my question is rather: can we deduce *anything* ACME related if the DNS server is not working correctly? – StackzOfZtuff Jun 30 '17 at 13:00

2 Answers2

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.

Søren Boisen
  • 151
  • 1
  • 4
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.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • 3
    Are you sure? Do you have a source? I read the opposite there: https://community.letsencrypt.org/t/how-do-i-handle-cname-webserver-verification/19112 – 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: https://www.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
  • Let's Encrypt supports `CNAME` records (and HTTP redirects). It doesn't allow easy misissuance. "StartEncrypt" was an unrelated service from an unrelated CA. – Matt Nordhoff Mar 23 '17 at 19:26