Renewing certificate on an unreachable/private server

Help
1

I have one web server that is not typically publicly accessible. When I originally created its certificate, I opened the firewall for that host in order to use tls-sni-01 authorization. After the certificate was created, I returned the firewall to its original state.

The “how it works” document at https://letsencrypt.org/how-it-works/ appears to indicate that renewals do not need to pass the same authentication. It states:

“Once the agent has an authorized key pair, requesting, renewing, and revoking certificates is simple—just send certificate management messages and sign them with the authorized key pair. … The agent also signs the whole CSR with the authorized key for example.com so that the Let’s Encrypt CA knows it’s authorized.”

However, evidence suggests that the renewal process described is not what is actually implemented. I can only renew certificates if I open the firewall again, which is a process that doesn’t fit well with automation.

What am I missing? Is it possible to renew certificates automatically for hosts that are not publicly reachable, as described in the “how it works” document?

My domain is:
darlington ee washington edu

I ran this command:
certbot certonly --quiet --standalone --keep-until-expiring
-d darlington…
–email webmaster @ …edu
–agree-tos --expand

It produced this output:
Cert is due for renewal, auto-renewing…
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for darlington…
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/darlington…conf produced an unexpected error: Failed authorization procedure. darlington… (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout.
Skipping.

My web server is (include version):

rpm -q httpd

httpd-2.4.6-45.el7.centos.4.x86_64

The operating system my web server runs on is (include version):
CentOS 7.3.1611

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

2

That document does seem misleading, but there is a short period where the domain validation remains active for your Let’s Encrypt account key. However, by the time an issued certificate expires, the domain validation will have expired and you’ll need to re-validate.

If your server is not public, but the DNS name is, you can use the dns-01 verification method. This method involves adding a TXT record to your DNS zone to prove ownership. There are several clients that work with Let’s Encrypt and this challenge, some even supporting APIs for common DNS providers. For example, acme.sh supports this exact scenario.

1 Like
3

certbot also supports this now :smiley:

Andrei

4

Certbot has limited support - acme.sh supports significantly more DNS APIs.

Also, that bit about the authorized key pairs is referring to not needing to create additional account keys for renewal. You still need to pass domain validation. (Lest someone get certs for a ton of domains that they could continue to renew long after the domain expires.)

The dns-01 challenge is definitely a solid way to handle this scenario, otherwise you’ll need to either punch temporary holes or offload the validation to a public-facing server and script logic to install the certificates on the restricted one. If the firewall modifications can be scripted from the renewing server, the pre-hook and post-hook options on certbot would let you execute commands to punch and close those holes automatically during renewal.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.