Renew issue, google compute engine pre-hook

Help
1

Running ubuntu on google compute engine, apache 2.4 server.
We normally run with http off. When attempting to renew a certificate, we turn on http via a pre-hook, and turn it back off with a post-hook. However, this doesn't seem to work. Is this a timing issue? Does certbot wait for the pre-hook to complete before attempting to renew? I have verified that the pre-hook does indeed turn http on.

My domain is:xbiologix.net

I ran this command:
cd /etc/letsencrypt/ && /usr/bin/certbot renew --pre-hook "gcloud compute instances add-tags my-vm-name --zone us-west1-b --tags http-server" --post-hook "gcloud compute instances remove-tags my-vm-name --zone us-west1-b --tags http-server; apache2ctl -k graceful" &>> /var/log/letsencrypt/renew.log

It produced this output:
2023-05-11 21:54:31,475:INFO:certbot.auth_handler:Performing the following challenges:
2023-05-11 21:54:31,476:INFO:certbot.auth_handler:http-01 challenge for www.xbiologix.net
2023-05-11 21:54:31,476:INFO:certbot.auth_handler:http-01 challenge for xbiologix.net
2023-05-11 21:54:34,878:INFO:certbot.auth_handler:Waiting for verification...
2023-05-11 21:54:45,383:INFO:certbot.auth_handler:http-01 challenge for www.xbiologix.net
2023-05-11 21:54:45,383:INFO:certbot.auth_handler:http-01 challenge for xbiologix.net
2023-05-11 21:54:45,384:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: www.xbiologix.net
Type: connection
Detail: 35.230.53.86: Fetching http://www.xbiologix.net/.well-known/acme-challenge/5suGsYwRKZeJEXWFK4K7z8XIRhTXxSOjyPeEB2ok_qE: Timeout during connect (likely firewall problem)

My web server is (include version):apache 2.4.41

The operating system my web server runs on is (include version):ubuntu 20.04.1

My hosting provider, if applicable, is:google compute engine

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

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

2

Yes, it will wait for the gcloud process to complete.

However, there may be a delay between the command completing, and Google Cloud's networking fabric to picking up the change and permitting traffic. It may be worthwhile trying to see whether adding a delay makes a difference.

Also, don't forget that certbot-dns-google exists - it could provide a way for you to avoid tinkering with firewalls rules at all.

6 Likes
3

Or just leave HTTP open, there's not really a good reason to close it anyway:

4 Likes
4

Or use the google domains/google cloud DNS plugin (whichever is relevant for your domain) to do DNS validation, skipping the need to touch the network config at all.

3 Likes
5

Thanks, it appears to be the propagation issue. Inserting a delay causes it to work, at least on a --dry-run.

2 Likes
7

I'm not sure what your design goal is.
But if it aims to minimize the HTTP interaction with your active web server [Apache], then why use it at all?
I mean, certbot can run a temporary web service to satisfy the challenge request [--standalone].
And if you are paranoid about any possible vulnerability that the certbot web service might have...
[I love the paranoid!]
Then you can use some other web service [like nginx] on port 80 - as a proxy.
Set it to simply proxy everything to HTTPS - except the ACME challenge request.
Those can be proxied to some unused other local port [like: 8000].
Then you can run certbot in --standalone and set it to use port 8000.
[and for the ones paying attention - you can set nginx to try 8000 and if that's off, then return 404]
So...
All bases are covered!

  • You don't have to turn anything on and off
  • You don't have to risk exposing your web server to HTTP [not that it is much of a risk]
  • You don't have to worry about random script kiddies knowing when you are running certbot
  • You don't have to directly expose the certbot web service

The paranoid can sleep at night!
unless... I missed something!
[now I can't sleep - LOL]

2 Likes
8

Since http is never used on this system, and the dns-google plugin requires installing additional packages and requires permissions not normally present in the service account, I don't see any advantage to that in terms of overall management. Mucking with dns records seems more mistake likely, and has more install requirements, than simply turning http on and back off. We only check the cert once a week.

9

If the certs aren't yet due for renewals... why turn on the HTTP web server [once a week]?

3 Likes
10

Maybe I'm missing something, but it was my understanding the pre-hook only got executed if the cert was due for renewal. Is that not the case?

1 Like
11

User Guide — Certbot 2.6.0 documentation (eff-certbot.readthedocs.io)
You may be right.

3 Likes
12

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