Unable to renew certificate

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. https://crt.sh/?q=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: alt.sysnet.ucsd.edu

I ran this command: certbot renew (and with -v)

It produced this output:

[Mon Jul 21 16:25:22] root@alt:/etc/apache2/sites-available# certbot renew -v
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/alt.sysnet.ucsd.edu.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate for alt.sysnet.ucsd.edu
Performing the following challenges:
http-01 challenge for alt.sysnet.ucsd.edu
Waiting for verification...
Challenge failed for domain alt.sysnet.ucsd.edu
http-01 challenge for alt.sysnet.ucsd.edu

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
  Domain: alt.sysnet.ucsd.edu
  Type:   serverInternal
  Detail: During secondary validation: Secondary validation RPC failed

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Cleaning up challenges
Failed to renew certificate alt.sysnet.ucsd.edu with error: Some challenges have failed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewals failed. The following certificates could not be renewed:
  /etc/letsencrypt/live/alt.sysnet.ucsd.edu/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 renew failure(s), 0 parse failure(s)
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
[Mon Jul 21 16:31:35] root@alt:/etc/apache2/sites-available#

My web server is (include version): apache2

Server built:   2025-07-14T16:22:22

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

My hosting provider, if applicable, is: n/a

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): straight up terminal

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

More notes:
I can run certbot certificate just fine (which tells me my cert has expired). I've checked my firewall and it lets http/https through. I've tested offsite and the website does show the default apache index.html page once you get thru firefox's scare tactics when no cert is available. I've renewed hundreds of times on my various servers, so I'm perplexed on this one. I did have an ldap authenticator on this which I initially assumed clocked the autorenew, but even after taking it out (and testing that it wasn't stopping access to the basic website as per testing the firewall) I'm still getting this error.

I do note that there's a service status disruption but I can't tell if that would stop a renewal from processing or not since it doesn't list the results of the disruption. If so, let me know and I can just wait for that service status notice to go away, tho it's very annoying to not be able to get into this particular site :expressionless_face: Otherwise, any hints would be greatly appreciated.

Thanks for your response!

1 Like

This is likely due to the reported outage. Please try again once it resolves.
It is not practical to try other things until this outage is resolved.

4 Likes

The same problem with me. There are many such mistakes today.
Can the official check whether there are any problems on the server?
{
"type": "http-01",
"url": "https://acme-v02.api.letsencrypt.org/acme/chall/1444426426/556884043901/uHo_ug",
"status": "invalid",
"validated": "2025-07-22T02:00:27Z",
"error": {
"type": "urn:ietf:params:acme:error:serverInternal",
"detail": "During secondary validation: Secondary validation RPC failed",
"status": 500
},
"token": "s-PSGG2FGD45lp1GpnwGgk5JDbJSJP1K_l3t3dwTsGs",
"validationRecord": [
{
"url": "http://vsdjg-regvfd-thgf-bwerg.yongydntureiwqhdjs.com/.well-known/acme-challenge/s-PSGG2FGD45lp1GpnwGgk5JDbJSJP1K_l3t3dwTsGs",
"hostname": "vsdjg-regvfd-thgf-bwerg.yongydntureiwqhdjs.com",
"port": "80",
"addressesResolved": [
"151.243.130.164"
],
"addressUsed": "151.243.130.164"
}
]
}

Yes, there is an active outage incident. It should be noted in a large red box at the top of the forum. It is also noted here: https://letsencrypt.status.io/

Please try again once the outage is resolved. Thanks.

The most recent post by staff is in the (current) second thread: Any updates on the current outage please? - #2 by JamesLE

4 Likes

Thanks very much. :+1:

1 Like

It was indeed the service outage; certbot renew ran just fine this morning. My bad luck on timing, I guess.

I wonder if it's possible to tinker a bit with certbot to have it check the operational status and note that in the output as well? That would have been useful to me. I didn't actually read the red flag across the top at first, oops. Too focused on subject topics looking for my problem...

1 Like

You'd have to post that request at the EFF's github: GitHub - certbot/certbot: Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.

Certbot is one of many ACME Clients. Let's Encrypt is one of a comparatively small group of ACME Servers.

For failures requesting Let's Encrypt certs I suppose they could check LE op status and report any issues. Assuming the comms is working properly on the requesting system (which is not always the case).

But, you said in your first post that you noted the service outage but wasn't sure it applied to you. So, not sure how helpful that would have been anyway. Certbot wouldn't see any more details than you did. It sometimes takes experience to know which ones might be related. Which is why we are here :slight_smile:

3 Likes

True, true; tho I noted the outage after I started the help request but not previously while trying to search on a match to my error message from certbot. The outage didn't go on to list "this would affect..." but as you note, acme serves more than just letsencrypt...

Ah well... thanks for your commentary!

1 Like

Usually, any error of type urn:ietf:params:acme:error:serverInternal means that the problem is on the CA's end and not yours. I think there's been discussion around here at times how it'd be good for certbot (and other clients) to do a little more parsing of that error code to help the user understand whether it's something they have control over.

3 Likes