8

I have a private Apache server, reachable only from my LAN on port 443, with a StartSSL certificate.

Since Firefox 51 was released, I cannot connect to it any longer as the StartSSL root certificate was removed from the trust store.

I considered migrating to Let's Encrypt, but that appears to require a public-facing HTTP server. Is it possible to use Let's Encrypt in my situation?

I would rather avoid paying for an SSL certificate, if at all possible.

user
  • 4,267
  • 4
  • 32
  • 70
Calimo
  • 400
  • 1
  • 4
  • 15

3 Answers3

11

If you control DNS for the domain then you can use the dns-01 challenge method to prove ownership by creating a TXT-record.

This can be done manually or automated. I think even the official certbot client now supports dns-01.

A quick Google shows me a bunch of tutorials using various scripts and clients so I won't repeat all of them here. This one specifically automates intranet certificates.

Martijn Heemels
  • 7,438
  • 6
  • 39
  • 62
  • Are you sure that it really works on intranet? What if I simply overwrite /etc/resolv.conf of the host on which the certbot runs? – peterh Jan 31 '17 at 02:43
  • @peterh yes, it works on the intranet as per the documentation. – BE77Y Jan 31 '17 at 11:02
  • 2
    @peterh I'm not sure what you're attempting by overwriting resolv.conf. The TXT-record needs to be created in public DNS since the Let's Encrypt validation servers, not the certbot client, needs to be able to resolve the record. If it all happened locally the validation wouldn't be worth much. The server for which the cert is issued can be completely private though. – Martijn Heemels Mar 21 '19 at 17:02
  • @MartijnHeemels Well, now I can't understand my this old comment any more. I create intranet certs with letsencrypt by tricking its DNSes on a way, that it shows a third server, *with public ip*, for all \*.intranet.mydomain requests - but it does *only for the outgoing DNS servers of the letsencrypt*. I got their IPs by tcpdump-ing the incoming DNS traffic. Bind9 has the so-named "views" for that. Thus, this third server can get \*.intranet.mydomain certs with a tricky apache configuration tuned for that. After that, the keys can be mirrored into the intranet with rsync scripts. – peterh Mar 21 '19 at 17:10
  • @MartijnHeemels I am doing this because at the time I had troubles to automatize the zone-based authorization of the letsencrypt. Maybe now it would work, but honestly I am not very satisfied with letsencrypt in general (well... with the troubles of its automatization, of course I am *very* happy that it exists) and I don't want to make it working again, what I've once made okay. (I think we all know the attitude of the bosses about "make it better" tasks like this.) – peterh Mar 21 '19 at 17:12
  • @peterh Ah I see. Yeah, this dns-01 challenge method would be easier now and can be used to request wildcard certs, but I definitely know what you mean about changing something that works. :) Thanks for clarifying this old thread. – Martijn Heemels Mar 21 '19 at 17:18
6

The certbot client has capability to do a manual DNS challenge. The (currently second most popular) answer found in this question How to use Let's Encrypt DNS challenge validation? has all the details, and I just tested it as working.

Basically, you run this command and follow the directions:

certbot -d site.your.dom.ain --manual --preferred-challenges dns certonly
Community
  • 1
vick
  • 171
  • 4
0

You mentioned that you are using Apache, however if you are not bound to it there is a very easy path possible using Caddyserver.

There you only have to define a Caddyfile with the following content:

example.com
tls {
    dns cloudflare
}

Mention the DNS provider you are using in the config and configure the API keys you are via environment variables. Draw from the list of supported providers from the docs.

That's all there is required. The output on the first start will be something like:

Activating privacy features... 2019/10/21 13:36:48 [INFO][cache:0xc0001c8190] Started certificate maintenance routine
[INFO][cache:0xc000092730] Started certificate maintenance routine
2019/10/21 13:24:49 [INFO][example.com] Obtain certificate
2019/10/21 13:24:49 [INFO] [example.com] acme: Obtaining bundled SAN certificate
2019/10/21 13:24:50 [INFO] [example.com] AuthURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/876706285
2019/10/21 13:24:50 [INFO] [example.com] acme: Could not find solver for: tls-alpn-01
2019/10/21 13:24:50 [INFO] [example.com] acme: Could not find solver for: http-01
2019/10/21 13:24:50 [INFO] [example.com] acme: use dns-01 solver
2019/10/21 13:24:50 [INFO] [example.com] acme: Preparing to solve DNS-01
2019/10/21 13:24:50 [INFO] cloudflare: new record for example.com, ID XXX
2019/10/21 13:24:50 [INFO] [example.com] acme: Trying to solve DNS-01
2019/10/21 13:24:50 [INFO] [example.com] acme: Checking DNS record propagation using [127.0.0.11:53]
2019/10/21 13:24:50 [INFO] Wait for propagation [timeout: 2m0s, interval: 2s]
2019/10/21 13:24:50 [INFO] [example.com] acme: Waiting for DNS record propagation.
2019/10/21 13:24:52 [INFO] [example.com] acme: Waiting for DNS record propagation.
2019/10/21 13:24:55 [INFO] [example.com] The server validated our request
2019/10/21 13:24:55 [INFO] [example.com] acme: Cleaning DNS-01 challenge
2019/10/21 13:24:55 [INFO] [example.com] acme: Validations succeeded; requesting certificates
2019/10/21 13:24:56 [INFO] [example.com] Server responded with a certificate.
done.

Serving HTTPS on port 443
https://example.com

2019/10/21 13:36:48 [INFO] Serving https://example.com

Serving HTTP on port 80
http://example.com

2019/10/21 13:36:48 [INFO] Serving http://example.com
Gregor Müllegger
  • 133
  • 1
  • 1
  • 4