Issues with certificates after renewal

Help
1

My domain is:
tak00.dtak.link

I ran this command:
sudo certbot renew --force-renewal

I had to renew ahead of time due to when the server was going to be used.

It produced this output:
Success and new certificates

My web server is (include version):
Apache 2.4.14

The operating system my web server runs on is (include version):
Ubuntu 22.04.3 host machine
Docker 25.0.1 to Ubuntu 22.04.1 SMP in the container

My hosting provider, if applicable, is:
AWS

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 5.2.2

After my most recent renewal, some ISPs are blocking the site with the error SSL_ERROR_RX_RECORD_TOO_LONG.

I have not made any changes to either my apache or server configuration between these and manage a second server, tak52.dtak.link which uses the same configuration which does not have this issue.

I've inspected the certificates and path as much as I can, all that I've found is that when the error appears, the certificate does not appear to have an Owner or Verified By.

When checking with openssl using the following, the only big difference between the certs which I can tell appears to be subdomain on the CA issuer.

openssl s_client -connect tak00.dtak.link:443 <<< "" | openssl x509 -noout -text

In httpd.conf I have the following configured for all VirtualHosts and have verified that the certs in the container match those outside of it.

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/auth.dtak.link/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/auth.dtak.link/privkey.pem

Some hosts run through a proxy.

Is there something obvious I'm missing to resolve the issue?

2

What info do you see on that certificate?

This does not look like a cert error but more like some kind of comms error. Maybe for some reason the HTTPS (port) traffic is sometimes getting routed to an HTTP port.

The first thing I thought of was that the Apache that terminates HTTPS had an old (and incorrect) child process still running. But, usually when that is the problem you can see the faulty response just by making many requests in sequence. Alas, I did not see that but if you haven't yet you could check all the pids related to Apache and make sure their parent pid is correct.

My last guess is that a firewall is blocking the request rather than passing it through to your Apache. Either at the failing requester or maybe on your inbound side.

SSL Labs also reports valid cert for both your tak00 and auth subdomains (as tak00 sometimes redirects to auth I saw). My own tests show the same (as did yours). I'd focus on firewalls and comms routing.

Hopefully that was a typo otherwise you may want to check why this is in your response headers

server: Apache/2.4.65 (Unix) OpenSSL/3.0.16

2 Likes
3

For the browsers which fail, they claim there is no cert.

Pids all look good from my current check.

Good catch on the typo, that was the first version we had, but have since updated apache.

4

Then whatever is replying must be "speaking" HTTP rather than HTTPS (TLS)

Are you able to reproduce that using curl? Using curl -i https://... will show the response headers and might be a clue what is replying. Maybe not even an Apache.

4 Likes
5

curl -i is giving me identical results when run on a network where browsers are working and one where they're failing.

6

Then inspect your Apache logs.

For such things I like to have a unique log for each possible VHost that will answer

Then check which log gets updated after success and failures.

Check the error log too for clues.

4 Likes
7

Unfortunately, the logs have not provided any new information.

What I receive is this when attempting to connect

[Wed Jan 07 20:12:38.152949 2026] [auth_openidc:error] [pid 9:tid 90] [client 34.140.188.44:45076] oidc_authenticate_user: the URL hostname (tak00.dtak.link) of the configured OIDCRedirectURI does not match the URL hostname of the URL being accessed (160.1.160.159): the "state" and "session" cookies will not be shared between the two!
34.140.188.44 - - [07/Jan/2026:20:12:38 +0000] "GET / HTTP/1.1" 500 535
[Wed Jan 07 20:16:32.338951 2026] [mpm_event:notice] [pid 1:tid 1] AH00492: caught SIGWINCH, shutting down gracefully
[Wed Jan 07 20:21:33.991030 2026] [ssl:warn] [pid 1:tid 1] AH01873: Init: Session Cache is not configured [hint: SSLSessionCache]
[Wed Jan 07 20:21:34.118553 2026] [auth_openidc:warn] [pid 1:tid 1] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCProviderMetadataURL SHOULD be "https" for security reasons!
[Wed Jan 07 20:21:34.118580 2026] [auth_openidc:warn] [pid 1:tid 1] oidc_check_config_openid_openidc: the URL scheme (http) of the configured OIDCProviderMetadataURL SHOULD be "https" for security reasons!
[Wed Jan 07 20:21:34.120695 2026] [mpm_event:notice] [pid 1:tid 1] AH00489: Apache/2.4.65 (Unix) OpenSSL/3.0.16 configured -- resuming normal operations

The first error also appears on the working server. That's the IP of the site.

8

Doesn't that exactly fit the problem you are seeing? You say browser connections are failing without showing any cert. That is, a connection used HTTP (no cert) when the browser expected HTTPS. That can happen when an HTTPS(port 443) request is mistakenly sent to port 80. Or a proxy routes requests wrong. Or, similar kind of problems.

This isn't a cert problem which we already knew because so many tools work correctly. Something is wrong in your packet routing or network config.

A site or support group specializing in Apache or networks is a better place. Maybe even a browser forum. A google search for the error I quoted gives a good explanation and some steps to try. This is even something one of the AI LLMs might help with.

This is pretty far off from anything to do with Let's Encrypt. I've tried to be helpful anyway but a different venue is your better option going forward.

3 Likes
9

I figured as such. Thanks for trying!

1 Like