Win-Acme and using their acme-dns works wiht Let’s Encrypt

Praise
1

Wanted to thank here the acme-dns guys for making that wizard making setup of Let's Encrypt certs easy.

It is a tremendous job and hope we can maintain it going forward. Using their

https://auth.acme-dns.io was also quite helpful

considering that DNS providers don't have usually API for DNS management.

The option that uses port 80 HTTP for validation is pretty undesirable frpm security perspective and the above avoids it. Port 80 should not be open anywhere, and having that open during re-validation requires extra setup.

It trust the chain of trust works very well and am sure you guys have designed it that way.

2

...and should not be used for your own validation. It's only there as a test system, but if you're going to be using acme-dns, you really should be running your own instance of it.

No, it really isn't.

Port 80 should be open on, at least, every public web server. Redirect to HTTPS, sure, but it should be open.

6 Likes
3
3 Likes
4

Yes you can redirect port 80 and that is about it , i doubt any Internet system will talk to a port 80

1: [http] Save verification files on (network) path
2: [http] Serve verification files from memory
3: [http] Upload verification files via FTP(S)
4: [http] Upload verification files via SSH-FTP
5: [http] Upload verification files via WebDav
6: [dns] Create verification records manually (auto-renew not possible)
7: [dns] Create verification records with acme-dns (GitHub - acme-dns/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. · GitHub)
8: [dns] Create verification records with your own script
9: [tls-alpn] Answer TLS verification request from win-acme
C: Abort

All those http methods which require server owner to open them are undesirable and can introduce .

For example : "[http] Save verification files on (network) path" not sure what that means but it wants me to serve the file over port 80 ? No.

All these HTTP options seem to imply that I have to judge and open and close just prior the Renewal job, which there might be a better way,...

Since I can use existing Lets Encrypt cert, or generate dev one, I should be possible to do auto renew over , HTTPS, but I don't know if win-acme will succeed in using that.

Even if I enabled 80 temporarily, it has to be built in the renewal task which I think is an exe, so have to do a script that preceeds it, then closes 80, maybe that is possible but I am looking for cleaner solution.

I can't use 6: [dns] Create verification records manually (auto-renew not possible)

Not sure if this is an option 9: [tls-alpn] Answer TLS verification request from win-acme ?

acme-dns (GitHub - acme-dns/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. · GitHub) maybe possible to compile, but I was looking for a faster way.

It needs to be minimal maintenace plus I want to use a best practice approach obviously.

5

Only if you insist on the anti-pattern of keeping port 80 closed.

I don't use Win-Acme, so I'm not familiar with the menu you list. For HTTP validation, Let's Encrypt needs to be able to connect to your server, from the public Internet, on port 80, and read a challenge token at a specified path. That's it. If you redirect all HTTP traffic to HTTPS, it will follow that redirect, but you really don't need to do that for this token.

That cleaner solution is "leave port 80 open, as you should for any web server open to the public."

3 Likes
6

Yes ISPs block port 80, the renewal must be possible to happen over the existing cert or maybe a developer cert.

And since everybody has redirects for port 80 as the article suggest, it would need people to re-engineer their redirection logic not to break the renewal process,

7

Possibly. The TLS-ALPN challenge uses port 443. Although, I'd generally recommend switching to simple-acme from win-acme. The principal maintainer of win-acme now focuses on simple-acme. See its TLS-ALPN docs here: simple-acme

Also keep watch for a new challenge called dns-persist-01. It is not yet available in Let's Encrypt production. And, you'll need support for it in your ACME Client. simple-acme has been good about supporting new features in general. See: DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt

If port 80 being open doesn't work for you that's fine. There are these other methods. But, getting the HTTP Challenge to work is very easy on many systems. Its pros and cons have been discussed on this forum numerous times before.

3 Likes
8

When they say HTTP/80 , would the connection work if that port was using a developer cert or some cert ?

If it will work over HTTPS that listens on port 80, would be good . In that case I could open port 80 just for renewal. With some restrictons maybe if the incoming source IPs can be restricted.

For me, Ideally they would make the current HTTP options works over HTTPS 443, whether it is using a temp cert or existing Let's encrypt cert. As I don't have to change infra settings.

9

The ACME protocol is described in RFC 8555. This is an industry standard used by all ACME Clients and Servers. Let's Encrypt being just one of a number of Certificate Authorities (CA) that provide an ACME Server. There are numerous ACME Clients.

Modifying that standard is very involved. You would be better focused on learning the options available as they are. A good place to start is here: Challenge Types - Let's Encrypt Note the section on TLS-ALPN is a bit stale as it says very few ACME Clients support it. While it is not as well supported as the other challenge types it is supported by quite a few.

Let's Encrypt does not publish the origin IP of their validation servers. LE currently has 5 validation centers around the world which rotate their IP regularly. See: Multi-Perspective Validation & Geoblocking FAQ

If this is a concern stay with the DNS Challenge (or wait for dns-persist). This requires your DNS Servers to be available world-wide but that is often the case. This also avoids the concerns you have regarding HTTP(S) access to your system.

The acme-dns in your first post is good but you should run your own instance and not use their server (as noted earlier)

You haven't said what services you use the certs for but Apache and nginx servers have built-in ACME Clients. Servers like Caddy and others also have ACME Client built-in.

If we understood more about your needs we could give better advice on options.

2 Likes
10

It's interesting that you're so concerned about the illusory security problem of leaving port 80 open, while completely ignoring that whoever operates auth.acme-dns.io can now create certs for you at will. I'd encourage you to rethink your security posture.

6 Likes
11

Thank you for this information. As I started using Let''s encrypt for my infrastructure, I will learn more and more about it,

I will reference the advice in the thread and use whatever is the easiest option.

I only need to use certs for HTTPS.

There is good set of options for that and I hear the recommendations to run own DNS service when using that option.

12

:slight_smile: In my case opening port 80 needs extra work, but for now I don't have to do it.

I hear the concern about someone spoofing my certs. First I believe those folks are part of the community so are trusted. And secondly if they did issue a cert for someone, they would also have to spoof a whole HTTPs server to do anything. I am figuring at that point the alarms will be ringing ..

Thanks, JA.

13

Well, the acme-dns "folks" say this on their github

You are encouraged to run your own acme-dns instance, because you are effectively authorizing the acme-dns server to act on your behalf in providing the answer to the challenging CA, making the instance able to request (and get issued) a TLS certificate for the domain that has CNAME pointing to it.

See the INSTALL section for information on how to do this.

From this section: GitHub - acme-dns/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely. · GitHub

I don't agree with your other assumptions but you are free to make your own security choices. You admit to being new to this so perhaps don't start off by ignoring expert opinions :slight_smile:

3 Likes
14

Only if you're monitoring certificate transparancy logs. Someone running a webserver responding to your hostname wouldn't make any alarm ring at all. Heck, I can run one for your hostname right now. The issue is getting the traffic originally to your webserver to mine, but that is relatively trivial with current unsecure protocols like BGP. For local attacks other methods exist.

1 Like