SSL Certificate Renewal Resulted in Connection Issues with Legacy Devices on Apache2

Help
1

Hello everyone,

I've been using Let's Encrypt SSL certificates on my AWS EC2 instance running Ubuntu 18.04 with Apache2 for several years without any issues. Recently, after a routine certificate renewal, I encountered connection problems with some legacy devices, specifically USR3200 devices.

Before the renewal, the SSL certificate root was DST Root X3, and everything worked fine. However, after the renewal, the root changed to ISRG Root X1, causing SSL errors on the USR3200 devices, preventing them from connecting to the server's APIs.

As I cannot change the certificate on the USR3200 devices, I'm looking for guidance on how to resolve this issue on the server side, particularly with Apache2. Are there any configuration changes or adjustments I can make to accommodate the new certificate root without breaking compatibility with these legacy devices?

Any assistance or advice would be greatly appreciated.

Thank you.

1 Like
2

Hi @vignesh-ak,

You might want to look at

Basically, the old chain is no longer automatically provided, but it can still be requested manually for one more renewal and it will be invalid after September. Let's Encrypt will no longer have an active chain of trust to DST Root X3 after September.

If the client devices can't be made to accept new roots, you might have to switch to a different CA. Bear in mind that all CA roots eventually expire at some point!

See also Chains of Trust - Let's Encrypt (you can download the cross-signature certificate there if you want to manually add it to your chain file, bearing in mind that this will only work until September).

4 Likes
3

This change was also announced in Shortening the Let's Encrypt Chain of Trust back in July 2023.

For any system admin using Let's Encrypt, it's a good idea to subscribe to the API Announcements category so you'll get a notification when a new thread is posted and you're up to date with any upcoming change. In the end this was a preventable problem you're facing right now, as one had more than half a year worth of time for preparations.

4 Likes
4

Thank you for response,

I'm fairly new to managing SSL certificates and Apache configurations, and I'm seeking guidance on how to update the SSL certificate chain on my Apache server to address this issue. Here are the specifics of my setup:

  • Server: AWS EC2 instance
  • Operating System: Ubuntu 18.04
  • Web Server: Apache2

I have obtained the cross-signature certificate isrg-cross-signed-x1.pem from Let's Encrypt, but I'm unsure of how to proceed with updating the SSL configuration.

Could someone please provide step-by-step instructions or guidance on how to update the SSL certificate chain on my Apache server to include the cross-signature certificate? Any assistance or advice would be greatly appreciated.

Thank you in advance!

1 Like
5

Your certificate chain is probably a text file somewhere on your system that your Apache configuration refers to. (If you're using Certbot, it's something like /etc/letsencrypt/live/example.com/fullchain.pem.) If you can find that text file, you should be able to edit it and add the cross-signature to the bottom, and then reload your web server, whereupon your web server should begin to serve it.

1 Like
6

The prefered route is to have your ACME client handle the choice and managment of the chain.

However, as you haven't filled out the questionnaire which was presented when opening a thread in the Help section, you've not provided us with enough information to guide you adequately.

4 Likes
7

Thank you for the help. But still the root is ISRG. The client is getting SSL handshake failed error in logs.

1 Like
8

Please give us some more detail about your domain name, web server configuration, file locations, etc.

5 Likes
9

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:

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
10

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: www.demo.com

I ran this command: Nothing

It produced this output: Nothing

My web server is (include version): AWS EC2

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

My hosting provider, if applicable, is: Amazon

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

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

Hello everyone,

I have an SSL certificate installed on my current server, but unfortunately, it has expired. I'm in the process of migrating to a new server with the same domain name and would like to renew the SSL certificate for it.

What is the best approach to renew the SSL certificate for the new server while ensuring continuity of service? Can I use the same expired certificate, or do I need to obtain a new one? If I need to obtain a new certificate, are there any steps I should take to ensure a smooth transition without any disruptions in service?

Any insights or advice on this matter would be greatly appreciated!

Thank you.

11

An expired certificate is worth as much as all the non-winning lottery tickets.

You should forget that cert exists and start down the path of obtaining a new cert and ensuring that it renews automatically.

It doesn't help to state an actual domain name that you don't control.
If you are not actually using this Internet domain name:

please write "example.com" instead.

4 Likes
12

I don't understand the question...
If the cert is actually expired, then all the services that use that cert are already disrupted.

3 Likes
13

I understand the importance of obtaining a new, valid SSL certificate. However, due to specific circumstances with my setup, it's critical for me to retain the current certificate. The SSL certificate is stored in a USR3200, and changing it could disrupt connectivity.

While I appreciate the recommendation to obtain a new certificate and ensure automatic renewal, for my current situation, maintaining the existing certificate is necessary. Any further guidance on how to proceed with transferring or renewing the existing certificate would be greatly appreciated.

Thank you for your understanding.

14

Let me merge this topic with the recent related one [that is still open].
--done--

2 Likes
15

It sounds like the USR3200 devices are actually clients and the cert is on "the API server" [whatever that may be].

If so, then you may need to better understand how, and why, the clients are no longer trusting that cert.
If the cert is actually expired, then you can just renew it [on the server].
If the cert is not expired, then the clients simply require a trusted chain.
You might be able to breathe some life into those very old clients by using a cert from another CA.
[a CA that has an older trusted root (anchor)].

4 Likes
16

OTHERWISE...
[in the meantime]

You might want to rereview this post:

4 Likes
17

Thank you fir the help. After adding that i have tested the SSL.

Additional Certificates (if supplied)
Certificates provided 2 (2658 bytes)
Chain issues Incomplete
#2
Subject ISRG Root X1
Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f
Pin SHA256: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
Valid until Mon, 30 Sep 2024 18:14:03 UTC (expires in 4 months and 16 days)
Key RSA 4096 bits (e 65537)
Issuer DST Root CA X3
Signature algorithm SHA256withRSA

this is the test result i am getting.

18

How did you test this? Note that many online test sites are actually quite incompetent.

1 Like
19

I have tested in www.whynopadlock.com and www.ssllabs.com

ssllabs is showing the above result.
whynopadlock is showing
Invalid Intermediate

You have an invalid or missing intermediate (bundle) certificate. This may not break your padlock on all browsers, but will on others. Please contact your SSL Vendor for assistance with this error.

20

When you use a certificate with any service you typically tell the service to use the certificate using a certificate file and an private key file (the other common option is a p12/pfx/keystore archive combining both).

Certificate files can either be just your certificate covering your domain, or they can also include the intermediate certificates the CA used to issue your cert (called the "full chain"). Generally you will need to use the full chain file instead of just your single certificate.

4 Likes