Is your DV certificate root certificate expired, causing client errors? Here's a solution!

　　Many users of DV certificates have encountered this situation: their website has just been renewed and the certificate is still valid, yet some users report "connection insecure" or "certificate expired." The first reaction is often, "Is there a problem with the certificate?" But after checking, the certificate itself seems fine. In reality, the root of the error isn't in your certificate, but in the client's root certificate trust store.

　　HTTPS trust is chained: server certificates are issued by intermediate certificates, and intermediate certificates are issued by root certificates. When a client browser or app verifies a certificate, it searches up this chain, ultimately finding a root certificate it trusts. If this root certificate has expired or been removed from the client's trust store, the entire trust chain breaks, and the error occurs.

　　DV certificates are widely used because of their low application threshold, fast issuance, and fact that they are mostly free. However, precisely because they often use automated CAs like Let's Encrypt, the frequency and impact of root certificate renewals are also greater. In recent years, several large-scale root certificate expiration events have had the widest impact on DV certificate users.

　　Recent Major Events Regarding "Root Certificate Expiration"

　　Let's Encrypt: DST Root CA X3 Expired

　　Let's Encrypt's certificates initially relied on the DST Root CA X3 cross-root certificate for widespread trust—because ISRG Root X1 was not yet built into all operating systems at the time. After DST Root CA X3 expired on September 30, 2021, Let's Encrypt's certificates had to rely on ISRG Root X1 for verification.

　　The problem is: ISRG Root X1 is only built-in trusted in newer operating systems. Users of older systems (such as Windows XP SP3 and below, macOS 10.12.1 and below, Android 7.1.1 and below, and Java 8u141 and below) still only recognize DST Root CA X3 and not ISRG Root X1. Therefore, these users will encounter errors when accessing any website using Let's Encrypt certificates.

　　DigiCert: G1 Root Certificate to be Discontinued Soon

　　DigiCert's situation is similar. According to Mozilla's new trust policy, trusted root certificates need to be replaced every 15 years after generation. DigiCert's old root (G1 root) will be gradually distrusted by Mozilla: the DigiCert Global Root CA will expire on April 15, 2026.

　　DigiCert DV certificates issued after December 1, 2024, will be issued using the new G2 root. The new certificates will work fine on mainstream PC browsers, but in non-browser environments such as apps, IoT devices, and older operating systems, where the G2 root certificate may not be pre-installed, verification will fail.

　　GlobalSign: Intermediate CA Change Causes Renewed Certificates to Be Untrusted

　　On May 27, 2019, GlobalSign updated the intermediate CA used to issue SSL certificates—switching from the old R1 root to the R3 root. As a result, DV and OV certificates renewed on this date may not be trusted on older systems because the R3 root is not present in those systems.

　　What kind of error message appears? How to identify it?

　　Client-side error messages vary depending on the environment:

　　Browser-side:

　　Chrome/Edge: Displays "Your connection is not private," NET::ERR_CERT_AUTHORITY_INVALID

　　Firefox: Displays "Warning: A potential security risk has been detected," SEC_ERROR_UNKNOWN_ISSUER

　　The certificate details may indicate "Unable to verify this certificate to a trusted certificate authority."

　　Command-line tools (e.g., wget/curl):

ERROR: cannot verify example.com's certificate, issued by '/C=US/O=Let's Encrypt/CN=R3':
Issued certificate has expired.

　　Java Application: Throws an SSLHandshakeException, indicating PKIX path building failed or unable to find valid certification path to requested target.

　　Key Judgment Principles:

　　Your certificate itself is valid (check openssl x509 -in yourcert.pem -noout -dates).

　　The error only occurs on some older devices; it works normally on newer devices.

　　The error message points to the root certificate or intermediate certificate.

　　It is almost certainly a problem with the client's root certificate truststore, not your server certificate.

　　Solutions: Choose according to the scenario.

　　Solution 1: Upgrade the client system (fundamental solution).

　　This is the cleanest and most long-term solution. Update the system's CA certificate package so that the new root certificate is automatically added to the truststore, and similar CA changes in the future will be automatically adapted.

　　Practical Operation (taking a Linux server as an example):

# CentOS / RHEL
yum upgrade openssl gnutls ca-certificates

# Ubuntu / Debian
apt upgrade openssl libgnutls30 ca-certificates

　　After the upgrade is complete, restart the service.

　　Option Two: Manually Import the Missing Root Certificate

　　If the system version is too old, cannot be upgraded, or the upgrade cost is too high, you can manually import the missing root certificate into the client's trust store.

　　The root certificate that Let's Encrypt users need to import: ISRG Root X1 (PEM format, available from the Let's Encrypt official website download link).

　　Windows Operation:

　　Press Win+R, type certmgr.msc to open the Certificate Manager. Locate "Trusted Root Certification Authorities" → "Certificates". Right-click → All Tasks → Import, select the downloaded root certificate file. Follow the prompts to complete the import.

　　Linux (update-ca-certificates method):

　　Place the root certificate (.crt format) in /usr/local/share/ca-certificates/. Execute sudo update-ca-certificates. Restart the service.

　　Java Applications (using keytool to import the JVM trust store):

sudo keytool -import -alias isrgrootx1 -keystore $JAVA_HOME/lib/security/cacerts -file ISRG_Root_X1.pem -storepass changeit

　　Option 3: Remove Expired Old Root Certificates

　　In some scenarios, both old and new root certificates exist in the system. The client may prioritize the expired old root certificate, causing verification failure, even if the new root certificate is already in the trust store.

　　The solution is to explicitly disable or delete the expired old root certificate.

　　Linux (using DST Root CA X3 as an example):

vi /etc/ca-certificates.conf

!mozilla/DST_Root_CA_X3.crt

update-ca-certificates

cp /etc/pki/ca-trust/extracted/cadir/DST_Root_CA_X3.pem /etc/pki/ca-trust/source/blacklist/
update-ca-trust

　　Windows：

　　Open the Certificate Manager (certmgr.msc).

　　Search for DST Root CA X3 in both "Trusted Root Certification Authorities" and "Untrusted Certificates".

　　Delete the certificate.

　　Java：

sudo keytool -delete -alias dstrootcax3 -cacerts -storepass 'changeit'

　　Option 4: Replace with a Paid Certificate (Recommended for Production Environments)

　　If you don't want to be constantly dealing with the root certificate rotation cycle, switching to a paid certificate with broader compatibility is a hassle-free option. Paid certificate brands (such as DigiCert and Sectigo) usually have more mature and widely pre-built root certificate systems, offering more comprehensive compatibility coverage. Their validity period is also longer (one year), unlike Let's Encrypt, which requires renewal every 90 days.

　　Option 5: Temporary Bypass (For Debugging Only, Never Use in Production)

　　You can use `--no-check-certificate` to temporarily skip verification for testing. However, this approach is only suitable as a temporary measure when troubleshooting issues; enabling it in a production environment completely removes HTTPS protection.

wget --no-check-certificate https://Your domain

curl -k https://Your domain

　　Troubleshooting and Repair Process: Follow these steps

　　1. Confirm Problem Type: Check the error message and client environment to determine if the problem is caused by an expired root certificate.

　　2. Identify the Missing Root Certificate: Based on the CA information displayed in the error message (Let's Encrypt's ISRG Root X1, DigiCert's G2 root, GlobalSign's R3 root, etc.), locate the root certificate that needs to be supplemented or updated.

　　3. Select Repair Path:

　　System upgrade possible → Perform system update (Solution 1)

　　System manual import not possible → Import missing root certificate (Solution 2)

　　Interference from old root certificate present → Disable/delete old root certificate (Solution 3)

　　For production environment stability → Replace with a paid certificate (Solution 4)

　　4. Verify Repair: Re-access the client that originally reported the error to confirm that the error has been eliminated.

　　5. Monitoring: Pay attention to official announcements to understand root certificate or intermediate certificate change notifications and prepare in advance.

　　Remember this: an expired root certificate does not mean your website certificate is expired. The problem lies in the client's distrust of the top of the certificate issuance chain. You don't need to re-sign the certificate; you just need to make the client "recognize" the root certificate issuer.