My issue is not old device compatibility. It is that sites we host are tested by our customers using ssllabs and they see the following: (in path #2) Sent by server ISRG Root X1 Fingerprint SHA256: 6d99fb265eb1c5b3744765fcbc648f3cd8e1bffafdc4c2f99b9d47cf7ff1c24f Pin SHA256: C5+lpZ7tcVwmwQIMcRtP…

but systems which don't trust the "ISRG Root X1" root are out now in any case. Shipping the DST issued ISRG Root X1 was only helpful for those old devices as long as the DST was not expired. Now the DST issued ISRG Root X1 is causing trust errors even on devices that DO trust the ISRG Root X1 root…

[image] bjacke: Shipping the DST issued ISRG Root X1 was only helpful for those old devices as long as the DST was not expired. That is incorrect. The old Android devices that the default long chain is intended to address do not care that the DST root is expired. It's a quirk of those impleme…

Our clients know we do not support older devices or browsers for the sites we host for them. So then regarding my post/question about our clients that look at the ssllabs results - and Nessus vulnerability scan results - both of which flag an issue... I have to go into great detail about the cause a…

If your sites do not need the old Android support provided by the long default chain, you can use the shorter alternate chain that does not have anything to do with the expired DST Root CA X3. I'm not sure what Nessus shows for sites serving the short chain, but SSL Labs shows no chain related error…

Using certbot on Ubuntu and Nginx to generate certs, how do I specify or force to use only the short chain. tried certbot --preferred-chain "ISRG Root X1", but without success.

[image] kmconklin: tried certbot --preferred-chain "ISRG Root X1", but without success. Can you be more specific about what you mean by "without success"? Was there an error? Did everything seem to work but your site is still serving the long chain? What versions of certbot, Ubuntu, and Nginx…

This is what I mean by without success: $ sudo certbot --preferred-chain "ISRG Root X1" usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ... Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing …

Welcome to the Let's Encrypt Community, Kevin :slightly_smiling_face: Your certbot version (0.31.0) is very old and doesn't support the --preferred-chain parameter.

--preferred-chain was introduced into certbot at version 1.12.0.

Not sure what is going on then... $ sudo apt-get install --only-upgrade certbot Reading package lists... Done Building dependency tree Reading state information... Done certbot is already the newest version (0.31.0-2~deb10u1+ubuntu18.04.1+certbot+3). 0 upgraded, 0 newly installed, 0 to remove …

Warnings in Qualys SSL Server Test - caused by long chain?

Help

griffin October 7, 2021, 10:49pm 16

Sounds to me like some auditors need some training. Just my 2¢.

They can start here:

Topic		Replies	Views
--preferred-chain not taking effect Help	36	10631	December 17, 2021
Can not connect using ISRG root X1 Issuance Tech	21	2001	September 25, 2021
Questions regarding "Shortening the Let's Encrypt Chain of Trust" Help	92	8165	June 10, 2024
Long (default) and Short (alternate) Certificate Chains Explained Issuance Policy	2	13528	November 15, 2021
Questions re: OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates Issuance Tech	55	10328	September 7, 2021

Warnings in Qualys SSL Server Test - caused by long chain?

Related topics