Unable to renew cert recently

Help
1

I am having this issue as well, I also know that LE is hitting my server, however certbot is not responding to those requests (I have the same logs as the OP). Firewalld and iptables are both disabled

18:55:27.665640 IP outbound1.letsencrypt.org.64706 > my.domain.here.http: Flags [S], seq 332691291, win 64240, options [mss 1460,sackOK,TS val 4067247405 ecr 0,nop,wscale 7], length 0

I am using certbot 1.11.0, on Centos 7 with the yum version.

Interestingly, when I use the docker version it works fine.

2

Hi @AddoSolutions and welcome to the LE community forum :slight_smile:
I've moved your post to a separate topic in order to provide you with specific solutions to your problem.
That said, we really need more information before we can do that.

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

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

3 Likes
3

Thanks!

My domain is: addosolutions.com

I ran this command: certbot renew

It produced this output:
IMPORTANT NOTES:

My web server is (include version):
Standalone

The operating system my web server runs on is (include version):
CentOS Linux release 7.9

My hosting provider, if applicable, is:
DigitalOcean

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):
certbot 1.11.0

1 Like
4

You must have a functional HTTP site before you can secure it (via HTTP authentication).
Note: LE validation servers are located throughout the Internet and their IPs can change at any moment.

I get:

curl -Ii http://addosolutions.com/
curl: (56) Recv failure: Connection reset by peer
3 Likes
5

I am running in standalone mode, so I am disabling my apache server when I am renewing (which is probably when you hit the server).

[renewalparams]
authenticator = standalone
account = xxxx
server = https://acme-v02.api.letsencrypt.org/directory
6

Whyever would you be doing that? Just use the apache authenticator instead of the standalone authenticator. At the very least use the webroot authenticator.

3 Likes
7

Agreed!
webroot authentication is much less intrusive and disruptive to your system.

3 Likes
8

Because I have a fairly complex set of servers, proxies, etc all running through that web server via containers. On this particular server, it's actually not too bad. Webroot would actually be wildly complex to include with all the different applications running on it

2 Likes
9

Makes sense. With the apache authenticator you would typically write an apache Location directive to specially handle the http-01 challenge files requested under /.well-known/acme-challenge/ such that those requests are not proxied. However, if the server running the ACME client (certbot) is not the one terminating SSL (serving the SSL certificate to the requester), this can pose challenges. I'm going to phone-a-friend here who is very experienced with complex setups to get his recommendations.

@jvanasco

Penny for your thoughts here.

3 Likes
10

While waiting for griffin's friend, you could try this:

sudo certbot --standalone certonly -d (domain) --dry-run --debug-challenge -v

I know you are doing renew, this is just example. The --debug-challenge will pause the --standalone server while it waits for you to press enter. You can then "poke" it with something like:

curl -i (domain)

Might help identify what is blocking access to the --standalone server

3 Likes
11

Just to clarify, this worked when I use docker (which you can see now works when you hit the domain), it's NOT working with the yum installed package.

At this point, the cert is all renewed, all good, my point is that I think there may be an issue with the certbot/centos combo (as per the original thread that I posted this on, which never got resolved) when in standalone mode.

I am happy with my setup as is, it worked up until this last renewal, however I believe the yum package was updated. It's just odd that standalone isn't working

2 Likes
12

Certbot offers the flag --http-01-port, which will run the standalone webserver on a higher port you specify.

I suggest using that flag to run Certbot on a random high port, and then proxy all traffic from your apache server in /.well-known/acme-challenge/ onto that port.

Doing so will accomplish two things:

  • You won't have to disrupt services for future renewals
  • You can spin up a quick webserver to test the proxypass, ensuring it works

Since you're running Certbot, you have Python on your system. One quick commandline can run a python webserver on a high port, just to test the proxypass. See: Serving Files with Python's SimpleHTTPServer Module

Edit: Issues like this are common on complex setups involving containers and proxies. IMHO, it's easiest to set things up to use a proxy because that creates a public facing route you can test reliably from external networks.

4 Likes
13

Does the docker use a different IP?
Where do the HTTP inbound connections get routed to?

4 Likes
14

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