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: let's start without it first
I ran this command: certbot renew, or certbot certonly --force-renew -d [domain name]
It produced this output: (typing!!! ->): How would you like to authenticate with the ACME CA? --> I select 1) Apache
An RSA certificate named [domain name] already exists. Do you want to update its key type to ECDSA? --> I select (K)eep existing key type
Certbot failed to autehnticate some domains (authenticator: apache). The Certificate Authority reported these probles:
Domain: xxx
Type: connection
Detail: [my IPv6 by my dynDNS-Service]: Fetching http://xxx/.well-known/acme-challenge/blablabla: Timeout during connect (likely firewall problem)
My web server is (include version): Apache 2.4.58
The operating system my web server runs on is (include version): UBUNTU SERVER 24.04
My hosting provider, if applicable, is: dyn dns
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 2.9.0
My question ist, what is now best practice after the expiration? Delete everything from certbot and start all over again, or something else?
This will (almost) never help you. It's to tell certbot to get another certificate even though it isn't close to expiration, not to tell the CA that you're really upset that you can't prove control over the domain.
This is describing you problem, that the CA can't connect to your domain for you to prove that you control it. In order for the way you're currently trying to get a certificate to work (which is the most common way), your domain webserver needs to be publicly accessible. (If it's intentionally limited to only some connections, but you want to use a public name, it's possible to use DNS authentication instead, but that's often more challenging to set up.)
No, just get your domain working again, and then certbot renew should be able to renew on its own.
Ok, I have also used the "certbot renew" command in the last few days (and right now again) and the result/output was the same.
About the accessibility... ok, firstly, I also tried with ufw disabled, nothing changed.
Then, my server was accessible in the last 2 years also outside of my local network (for example with my cell phone). And the certificate was automatically renewed multiple times in these 2 years. I have no idea, what have changed. The upgrade to Ubuntu 24 was done, after I noticed, that the certificate renewal failed. So, no problems with dyn DNS, which is communicated with a ddclient.
Well, even if it's working from where you are, the error indicates that Let's Encrypt can't connect to it.
If you're not willing to share your domain name here, but are willing to type it into some online tools, these ones might help you see where one can and can't connect from:
But ultimately to get proper (or any IMO) support, you need to provide the hostname. It's also what the questionnaire says:
you must provide your domain name to get help
It might be as "simple" as that your IPv6 doesn't work, but your IPv4 does, where Let's Encrypt prefers IPv6 Currently we're just guessing and frankly you're pretty much on your own now with some of the tools provided by Peter. But most of the time everything is way quicker if one simply provides the hostname.
So your HTTPS on port 443 works. I'm seeing some Nextcloud thing.
However, port 80 (HTTP) seems to be blocked on the host itself. A TCP traceroute for port 80 reaches the penultimate IPv6 address 2a02:908:d00:2::1f8b, but no responses after that. (While the port 443 TCP traceroute works perfectly.)
So it seems something is blocking access to just port 80.
You said you already disabled ufw, but is that the only firewall present? Perhaps something changed with your router?
During the renewal process in the last days I disabled sometimes the ufw firewall, but now it is enabled.
It's the only firewall I have.
I haven't changed anything in the router, maybe my Internet Provider... I'll check it.
Thank you for your help!
AAAANotWorking
Error
clouds.dedyn.io has an AAAA (IPv6) record (2a02:908:d26:4fa0::2cb3) but a test request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address. You should either ensure that validation requests to this domain succeed over IPv6, or remove its AAAA record.
A timeout was experienced while communicating with clouds.dedyn.io/2a02:908:d26:4fa0::2cb3: Get "http://clouds.dedyn.io/.well-known/acme-challenge/letsdebug-test": context deadline exceeded
Trace:
@0ms: Making a request to http://clouds.dedyn.io/.well-known/acme-challenge/letsdebug-test (using initial IP 2a02:908:d26:4fa0::2cb3)
@0ms: Dialing 2a02:908:d26:4fa0::2cb3
@10000ms: Experienced error: context deadline exceeded
IssueFromLetsEncrypt
Error
A test authorization for clouds.dedyn.io to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.
2a02:908:d26:4fa0::2cb3: Fetching http://clouds.dedyn.io/.well-known/acme-challenge/_8d3WOhcQU51G5MZh2afxuySnYxVJqEo1jy39J7Lbew: Timeout during connect (likely firewall problem)
And
7>curl -k -Ii http://clouds.dedyn.io/.well-known/acme-challenge/sometestfile
curl: (28) Failed to connect to clouds.dedyn.io port 80 after 75259 ms: Could not connect to server
So, I changed something in the router and now I get this:
All OK!
No issues were found with clouds.dedyn.io. If you are having problems with creating an SSL certificate, please visit the Let's Encrypt Community forums and post a question there.
Currently I don't see your Apache webserver using the new cert though.. Did you reload it? Maybe add a --deploy-hook where it gets reloaded automatically after a successful renewal.
Currently we're just guessing and frankly you're pretty much on your own now with some of the tools provided by Peter. But most of the time everything is way quicker if one simply provides the hostname.
