First off, Debian 9 is EOL. But as the clients may not be under your control, you may of course want to try to cater to them in this breakage.
I assume that while the question only mentions certbot, that it's really specifically about Letsencrypt.
(The tool certbot itself is an ACME protocol client which is also used with other ACME-based CAs, so there is ...
Warning! Please plan OS upgrade path. The below advice should be applied only in emergency situation to quickly fix a critical system.
Below solution works on Debian Jessy 8 and should on Stretch 9 missing updates too. I just tested it on docker run -it debian:jessie bash, apt-get update && apt-get install curl.
# curl -I https://hu.dbpedia....
DST Root CA X3 root certificate expired on Sep 30 14:01:15 2021 GMT. It was used as one of certification paths for Let’s Encrypt certificates Older cURL version has a bug that will cause expired root to fail connection instead of trying other roots in local ca store.
As of 30 september 2021 ca store for curl (https://curl.se/docs/caextract.html) still ...
I've just had this problem with a Docker image based on Debian Stretch. The solution has been easy, I suppose Debian has patched libssl1.0.2 to fix the chain selection issue Håkan has mentioned. In my case, updating just the certificates and libssl1.0.2 by running apt install -y libssl1.0.2 ca-certificates (with apt update for containers beforehand) has been ...
Your problem stems from the fact that your web server is not sending any chain certificates with your leaf certificate. This is what the SSL Labs test is trying to tell you when it says, "This server's certificate chain is incomplete".
Browsers and other clients have to guess how to verify the certificate you're sending and some are more capable/...
You are generating the certificates yourself, of course nobody else is going to trust them; that's the whole point of certificates.
You should get a certificate from a public Certification Authority (or use a free solution like Let's Encrypt).
Disable "DST Root CA X3" the certificate on your server. Run:
sudo dpkg-reconfigure ca-certificates
On the first screen that prompts "Trust new certificates from certificate authorities?" choose "yes". On the next screen press the down arrow key on your keyboard until you find mozilla/DST_Root_CA_X3.crt, press the space bar to ...
Since you can't control your clients then the safest way would be to start using some other CA issued certificates.
One possible CA would be ZeroSSL (https://zerossl.com). They offer also certificates via ACME protocol without any fee like Let's Encrypt (https://zerossl.com/letsencrypt-alternative/) and have a pretty good compatibility with older devices (...
For Debian 8 and 9, I just do that for updating cert on host and no longer have the error 60: SSL certificate problem: certificate has expired :
Just run, it should work :
wget -O - https://raw.githubusercontent.com/xenetis/letsencrypt-expiration/main/letsencrypt-expiration.sh | bash
For Kibana, you can easily use Trusted CA Signed SSL Certificates, for example Let's Encrypt, by placing them in cert/kibana_http/
cp /etc/letsencrypt/live/<site-address>/privkey.pem certs/kibana_http/key.pem
cp /etc/letsencrypt/live/<site-address>/fullchain.pem certs/kibana_http/cert.pem
For internal communications between the different Wazuh ...
It is recommended to use ACM for storing (or issuing certificates), but as per my comment above in case ACM is not supported within a region then you can upload the certificate to IAM.
Such a certificate could then be used in an Application Load Balancer or Network Load balancer or by setting up a Custom SSL in your CloudFront distribution.
MySQL SSL connection are not just a standard SSL connection with MySQL connection inside.
When establishing such connection, MySQL client first handshake with server using MySQL plaintext protocol, (if both side agree using SSL) then start SSL connection on same TCP connection.
OpenSSL or other general purpose SSL client can't understand MySQL plaintext ...
Finally resolved the issue by just trial and error:
Get root CA from: https://support.cloudflare.com/hc/en-us/articles/218689638-What-are-the-root-certificate-authorities-CAs-used-with-Cloudflare-Origin-CA-
For example, in RSA format:
Cloudflare Origin CA
And you have your own Certificate as: