current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 3 down vote favorite

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? 

    {
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:acme:error:connection",
        "detail": "DNS problem: SERVFAIL looking up A for dev.server.com",
        "status": 400
      },
share|improve this question
2  
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) – Ay0 2 days ago
    
@Ay0 Is that subject to signature misuse as described here: mailarchive.ietf.org/arch/msg/acme/F71iz6qq1o_QPVhJCV4dqWf-4‌​Yc - The ACME Draft RFC has a warning on a few verification methods – LamonteCristo 2 days ago
    
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. – Ay0 23 hours ago
up vote 0 down vote

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.

share|improve this answer
    
Are you sure? Do you have a source? I read the opposite there: community.letsencrypt.org/t/… – Tom 17 hours ago
    
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 14 hours ago
    
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 14 hours ago
    
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 14 hours ago
    
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 13 hours ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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