The issue stems from Debian 9's outdated certificate bundle. Let's Encrypt transitioned from using their own root certificate (DST Root CA X3) to ISRG Root X1 since September 2021. Debian 9's default CA certificates don't properly chain to the new root.

First, check which certificates your system trusts:

# List all trusted certificates
ls -l /etc/ssl/certs

# Check specific certificate chain
openssl s_client -showcerts -connect hu.dbpedia.org:443 -servername hu.dbpedia.org < /dev/null

Instead of copying certificates manually, use these steps:

# Install updated ca-certificates package
sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates

# Alternative method if above doesn't work
wget https://curl.se/ca/cacert.pem -O /usr/local/share/ca-certificates/cacert.crt
sudo update-ca-certificates

For applications using libcurl, you can specify a custom CA bundle:

// C/C++ example
CURL *curl = curl_easy_init();
if(curl) {
  curl_easy_setopt(curl, CURLOPT_URL, "https://hu.dbpedia.org/");
  curl_easy_setopt(curl, CURLOPT_CAINFO, "/etc/ssl/certs/ca-certificates.crt");
  curl_easy_perform(curl);
}

For Python scripts, you can specify the certificates file:

import requests

response = requests.get(
    'https://hu.dbpedia.org/',
    verify='/etc/ssl/certs/ca-certificates.crt'  # or path to updated bundle
)

After applying changes, verify with:

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /path/to/your/cert.pem

# Or test directly with curl
curl --cacert /etc/ssl/certs/ca-certificates.crt https://hu.dbpedia.org/

1. Consider upgrading to a supported Debian version (10+) if possible
2. For containers, use updated base images
3. Monitor certificate expirations with tools like certbot renew --dry-run

This issue occurs because Debian 9 (stretch) ships with an outdated root certificate store that doesn't include the newer ISRG Root X1 certificate that Let's Encrypt now relies on. When clients try to verify the certificate chain, they fail because they can't find a trusted root certificate.

First, let's examine the certificate chain to confirm the issue:

openssl s_client -showcerts -connect hu.dbpedia.org:443 -servername hu.dbpedia.org /dev/null | openssl x509 -noout -text | grep -A 1 "Issuer"

The correct approach is to properly update your CA certificates. Here's how to do it:

# First, install the necessary package
sudo apt-get install ca-certificates

# Then update the certificates
sudo update-ca-certificates --fresh

If this doesn't work (as in your case), you'll need to manually add the ISRG Root X1 certificate.

Download and install the missing ISRG Root X1 certificate:

# Download the certificate
sudo wget -O /usr/local/share/ca-certificates/isrgrootx1.crt https://letsencrypt.org/certs/isrgrootx1.pem

# Update the certificate store
sudo update-ca-certificates

For applications where you control both client and server, you could implement certificate pinning:

# Python example using requests with certificate pinning
import requests

session = requests.Session()
session.verify = '/path/to/your/certificate.pem'
response = session.get('https://hu.dbpedia.org')

After implementing any of these solutions, verify them with:

curl -v https://hu.dbpedia.org/

You should now see the connection establish successfully without certificate errors.

For production systems, consider:

• Setting up a proper certificate rotation mechanism
• Monitoring certificate expiration dates
• Automating certificate updates

Remember that the best long-term solution is to upgrade to a supported Debian version, as Debian 9 reached end-of-life in June 2022. This ensures you receive regular security updates and maintain system integrity.