Installing lets encrypt through VPN

I'm familiar with installing let's encrypt. I'm facing a problem, I want to know if letsencypt is working in a VPN setup.

I found this concern in github ::
I was trying to renew a cert for one of my servers:

./certbot certonly --standalone -d <my-domain-here>

..and I kept seeing a failure that looked like this:

certbot urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

To fix these errors, please make sure that your domain name was entered correctly and the DNSA/
AAAA record(s) for that domain contain(s) the right IP address.
Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client.
If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided.

At first I found this error a bit odd but then it occurred to me that I had a VPN up on the box where I was issuing the ./certbot renewal request and I didn't when I originally created the cert some time ago. At this point the error made sense (it being related to my IP address not being recognized by the remote challenge response server), I dropped the VPN, re-attempted the renewal and it worked without an issue.

My question is: is it possible to make renewal work without having to drop the VPN tunnel?

was this resolved?

Is there any proper approach to use letsencrypt in a local server?

Hi @reeforelaxo, and welcome to the LE community forum :slight_smile:

As I read the details as you have described them, I would think that it won't be able to respond "correctly" to those HTTP-01 authentication requests [through the VPN tunnel].
Your only choices are:
[most require the tunnel to be dropped/reconfigured - but not all - do read on]

  • drop the VPN tunnel during renewal process
    This may be possible to automate with hooks
  • exclude very large parts of the Internet from the VPN tunnel
    presently all AWS networks - but it might be even larger than that in the future
  • exclude HTTP requests, and their replies, from the VPN tunnel
    sounds simple enough - but might not even be possible to configure
  • use an indirect authentication method
    There is only one that fits that requirement: DNS-01 authentication
    [which is not as simple to automate - requiring a DSP that supports DNS zone updates via API]

That said, I'm a bit confused as to how one could even use such a cert.
[when the path to the IP resolved from the FQDN is NOT accessible from the Internet while the VPN tunnel is in use - which seems to be most, if not all, of the time]


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