Domain Validation without HTTPS

[KevinTheDrummer]

Hi,

I would like to be able to install a Domain Validation (DV) certificate. I run only an email server. I have no interest to install a web server. But, it seems the only way to get a certificate is to install and configure a web server, as well as opening up a couple ports on my firewall. At least that's what the FAQ and certbot tend to indicate. Maybe I'm mistaken?

How can I get a DV certificate?

Thanks much folks!

My domain is: doinkmusic.com

My web server is (include version): N/A, my mail server is Fedora 27.

The operating system my web server runs on is (include version): N/A

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no (not yet anyway)

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): N/A.

[Osiris]

@KevinTheDrummer

But, it seems the only way to get a certificate is to install and configure a web server, as well as opening up a couple ports on my firewall. At least that's what the FAQ and certbot tend to indicate. Maybe I'm mistaken?

If you read all of the docs, you'd also see the Challenge Types page. Here, besides the http-01 challenge it also explains the dns-01 challenge. The dns-01 challenge doesn't require a webserver nor open incoming ports to your server. It only requires a publically available DNS server.

Also, note that certbot can act as a temporary tiny webserver by just using Python. So no "external" webserver like Apache or nginx is required. That does however require an open incoming port 80.

[KevinTheDrummer]

Ooops, I buried myself in the Get Started path, and didn't look up to find the Documentation link. Sorry.

Yes, DNS-01 looks workable, though not super convenient as another human needs to attend to the DNS TXT record.

It looks like I need to dig deeper into certbot's temporary (self-contained?) webserver.

My ISP is Comcast/Xfinity. It looks like they don't enable port 80 by default. But, they're also are said to not block port 80. I would probably want to block that port on my firewall with an exception for LetsEncrypt. I'll check the docs to see if there's there an address block for LetsEncrypt which I should open.

Thanks for the assist @Osiris !

[schoen]

@KevinTheDrummer

I'll check the docs to see if there's there an address block for LetsEncrypt which I should open.

You'll find that there isn't—a longtime topic of discussion and debate here on the forum. Let's Encrypt does not encourage or facilitate whitelisting particular addresses by publishing the addresses that it currently uses for these validations.

If you can control your firewall from software somehow, you could make the Let's Encrypt client open port 80 on the firewall right before the challenge and close port 80 again afterward. With Certbot, you can use --pre-hook and --post-hook for this (to make it run commands before and after attempting the domain validation challenges).

[KevinTheDrummer]

In case this helps someone else, the standalone certbot script is looking pretty good for me, as someone that doesn't run a webserver.

Using the certbot documentation here https://certbot.eff.org/docs/ indicated that I could install both certbot and letsencrypt packages, which I did on my LinuxMint 19.3 system.

[Osiris]

@KevinTheDrummer

Using the certbot documentation here https://certbot.eff.org/docs/ indicated that I could install both certbot and letsencrypt packages

Huh? How do you mean, the "letsencrypt package"? At the very early beginning of Let's Encrypt, the ACME client now called certbot was called "letsencrypt", but it was renamed to "certbot" very early on.. For more than 4 years now I believe.

Where did you read that you needed to install both?

[KevinTheDrummer]

I was reading here: https://certbot.eff.org/docs/install.html where both packages are mentioned. It didn't say what each is used for. It did have "or" parenthetically referring to letsencrypt, and that probably was a hint I took less seriously than I should have. Both were available in the repo, so I installed both. I've now deleted letsencrypt, leaving me with certbot.

I was wondering about redundancy there, as both scripts' help messages are identical. The two packages have identical version numbers: 0.27.0-1~ubuntu18.04.2 for whatever that might imply.

[Osiris]

@KevinTheDrummer

Both were available in the repo

Which is kinda weird enough on its own..

@KevinTheDrummer

I was wondering about redundancy there, as both scripts' help messages are identical. The two packages have identical version numbers: 0.27.0-1~ubuntu18.04.2 for whatever that might imply.

One is probably just a "symbolic link" kinda thing for packages I hope.. Also, 0.27 is very, very old. You might want to look at the "snap" method of installation.

[griffin]

Welcome to the Let's Encrypt Community

@KevinTheDrummer

My ISP is Comcast/Xfinity. It looks like they don't enable port 80 by default. But, they're also are said to not block port 80. I would probably want to block that port on my firewall with an exception for LetsEncrypt. I'll check the docs to see if there's there an address block for LetsEncrypt which I should open.

Best Practice - Keep Port 80 Open - Let's Encrypt - Free SSL/TLS Certificates

[rg305]

What is the point of blocking port 80, when you have stated clearly that you don't have, nor want to run, a webserver?
If you leave that port open, and forwarded, then certbot can use it to validate the HTTP challenge requests (when used in --standalone mode).

[KevinTheDrummer]

It's just a philosophical posture of having everything blocked that I don't use.

Now I'm starting to see a reason to have port 80 open, which is purely for certbot to use. Earlier in this thread @schoen suggested I might look into controlling my firewall using certbot's --pre-hook and --post-hook options. That might be cool. I haven't looked at that yet.

[rg305]

I begin configuring firewalls with one rule: DROP EVERYTHING.
Then I add all the ones that need accepts above it
[So I get where you are coming from.]

I'm not too keen on having any other program control the firewall configuration, but that is a valid option in certain cases (not for yours thou; as you have no HTTP listener on that port - opened or closed makes no security difference).

[KevinTheDrummer]

@rg305 Aw man, you have really hard questions. For instance, which poses a greater risk, a dangling open port, or a Python script altering the firewall? I guess I'm going to have to agree with you. Python is a risk. Any python script is a risk. Any script with root privilege is a risk. Owning a computer is a risk. Turning it on presents even more risk.

Thanks again...

[Osiris]

@KevinTheDrummer

a dangling open port

A port isn't open if nothing is listening.

[rg305]

So if I allow you to come in and sit down...
But I don't have any chairs?
I'm good!

[griffin]

Confucius say:

If no one listening, does port even exist?

Also say:

Man who stand on toilet seat be high on pot.

[jvanasco]

@schoen

If you can control your firewall from software somehow, you could make the Let's Encrypt client open port 80 on the firewall right before the challenge and close port 80 again afterward. With Certbot, you can use --pre-hook and --post-hook for this (to make it run commands before and after attempting the domain validation challenges).

My main production systems have a pre/post hook that opens the firewall for an iptables ruleset on port-53 and starts an acme-dns server; then shuts it all down. This lets us run dns-01 challenges for wildcard certs, with traffic open for only very very very small amounts of time. running this in a ruleset that is early-on also lets us run fail2ban, and aggressively ban network blocks.