5

I found the technical paper on ACME's inner workings, but I still feel a bit confused about the ways Let's Encrypt's Domain Validation works.

From what I already know, verification can be performed over either port 80 or 443. Client connects to the server, which tells the client to put a specific file on the server.

  • Does the client decide which port is used?
  • Can the data be put anywhere within the server?
  • How does ACME actually work in the Let's Encrypt example?
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
d33tah
  • 6,524
  • 8
  • 38
  • 60
  • ... Can you link the paper so we can read it too? Otherwise it's kinda hard to know what you're talking about. Also: port 443 is the HTTPS port, how can you offer HTTPS before you've gotten your certificate? – Mike Ounsworth Dec 09 '15 at 11:24
  • @MikeOunsworth: self-signed one? It's all about putting specific content up. Also, you might want to migrate. – d33tah Dec 09 '15 at 11:27
  • Any self-respecting SSL stack should refuse to connect to a self-signed cert unless it's been added to the trust store, which yours won't be for letsencrypt – Mike Ounsworth Dec 09 '15 at 11:30
  • 1
    Honestly, I don't know - I read about TLS challenges somewhere. It makes sense for me because you don't really need confidentiality or authenticity there if HTTP is your alternative. You just want the user to be able to prove that he can publish data on the domain. – d33tah Dec 09 '15 at 11:32
  • 1
    Normally Mike you'd be right, but in this case the ACME system (here Let's Encrypt's boulder) explicitly ignores any certificate presented by your HTTPS server. You can read this in the Internet Draft for the ACME protocol. This is safe because the whole purpose of ACME making the HTTP request is to figure out if the server it's talking to is controlled by the Subscriber (CA terminology for "whoever we're issuing this certificate to"), the very thing the certificate it's ignoring would otherwise vouch for. – tialaramex Mar 26 '16 at 11:44

1 Answers1

11

The ACME spec lists a number different challenges:

  1. Identifier Validation Challenges
    7.1. Simple HTTP
    7.2. Domain Validation with Server Name Indication (DVSNI)
    7.3. Proof of Possession of a Prior Key
    7.4. DNS

If I had to summarize the detailed process (about two screens full) given in section 7.1. Simple HTTP, then I'd say it goes a something like this:

Client: Hey server, my customer number is x, challenge me!
Server: Okay, put a file named y on your HTTP(S) server and sign it with your customer number key.
Client: Done.
Server: Lemme check... Okay, here's your certificate.

There is also a description of that process with screenshots.

Does the client decide which port is used?

Yes. But you can only pick between http on 80 or https on 443.

There is a long-running discussion about whether to allow other ports.

Can the data be put anywhere within the server?

No. I think you're bound to this path:

The path at which the resource is provisioned is comprised of the fixed prefix “.well-known/acme-challenge/”, followed by the “token” value in the challenge.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • 2
    As a side note, when using HTTPS the certificate used by your server is not validated by the ACME server. So, you can use any cert while fulfilling the challenge, including self-signed ones. – dst Dec 09 '15 at 15:10