I managed to get my certs created for certbot --apache in order to get the files in place for Apache. However, as Apache does not support the DNS record or the web content, it was failing when I was running behind my home router. I found some (!) quiet time to get my RPi right on the internet (no router) and get the cert created after updating my DNS entries for the proper IP address. Life is great…
However, will I have to redo this every time I will have to renew my cert, get right on the net and skip the router, for the time of renewing the cert? (which is a bit of a pain…) Or will certbot use the existing cert as the existing proof and renew from there ? Or is there a different way to implement the renewal command so that I can get the cert renewed without intervention (like cron) and remain behind my router ? Is there a “permanent” DNS record I can put in place that will let certbot renew without my manual intervention ?
If you can make the router forward inbound port 443 connections to your server (even temporarily during your renewals), you can pass the TLS-SNI-01 challenge without having a public IP address for the server.
Otherwise, you should consider using the DNS-01 challenge method instead of TLS-SNI-01. As you saw,
certbot --apache does not support that, but you can use a different client instead of Certbot, or use
certbot -a manual -i apache if you like Certbot’s ability to install certificates into your Apache configuration. Clients like acme.sh have a wider range of integrations with DNS provider APIs to help automate completing this challenge.
You cannot receive certificates from Let’s Encrypt without the ability to receive inbound connections on port 443 or port 80, or the ability to make a change to DNS records. Setting a single static DNS record is not enough; the requested DNS record will change every time you request a new certificate. Contrary to early suggestions on Let’s Encrypt’s design, having an existing certificate doesn’t count one way or another as proof when requesting a new certificate.
If your server isn’t accessible to the public and is not accessed by devices other than your own computer, you might be happier with a self-signed certificate. In this context one can argue that it actually provides better, not worse, security than a CA-issued certificate.
Thanks. I tried it and it actually works. what was puzzling me was that although I had an inbound connection on 443/TCP redirected to my computer internally on 443/TCP, it did not work on the initial setup. With the same computer setup, directly connected on the net (after DNS update and propagation), it worked flawlessly. I was afraid that I would have to setup a direct connection on the internet four times a year… But the setup now works… I successfully renewed my certificate.
As a reference for others who would read this later, my setup is a Raspberry Pi 3, connected behind a home router on a cable modem connection. The router redirects traffic on ports 22 (SSH) and 443 (HTTPS) to my RPi directly. Port 80 is not redirected inside. The RPi is setup with the latest of a plain Raspbian, along with Apache 2 and openssl. I also installed Shellinabox as a sub-page of my site, in order to get access to my Linux boxes from locations where only 443/TCP is allowed outbound, and is deeply inspected. I use a dyndns hostname in order to always have the right IP address, and one of the hostnames of my domains is a CNAME that points to this dyndns hostname.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.