Linux distro compatibilty as client

Hi,

On https://letsencrypt.org/docs/certificate-compatibility/ there are compatibility for Distro of linux. Currently only Debian and Ubuntu are shown. I use Fedora and can install a Centos without issue, but :
It’s not OpenSSL compatibility to take ? Linux distro don’t directly do SSL connexion, they use OpenSSL for such purpose.

Else : what is the test to do for a distribution (i have a old fedora 19 somewhere).

Denis

I guess you mean "certificate", not "Centos"?

Anyway, the list you're refering to is a list for client compatibility, i.e., browsers. Not certificate installation compatibility.

Also, OpenSSL doesn't provide the certificates for a Linux distribution. These are separate packages, most of the time anyway as far as I know. Combined with the used client of course.

[quote="Osiris, post:2, topic:26487"]
I guess you mean "certificate", not "Centos"?[/quote]No i mean a Centos to testing it if it was LE compatible

[quote="Osiris, post:2, topic:26487"]
Anyway, the list you're refering to is a list for client compatibility, i.e., browsers. Not certificate installation compatibility.
[/quote]I mean OS client here : look at the list properly :

I see on the global topic Fedora 22 is compatible, but no test on lesser fedora version or on CentOs (surely CentOs 7 is compatible but unsure for 6 or 5).

You spoke for client : then using libcrypto and libssl : this 2 lib are part of openSSL : a lot of client on linux distro use this lib for all ssl/tls negotiation. wget is compatible but wget don't validate the certificate (i think) : then How Debian and Ubuntu are added in client : what test is done ?

Denis
PS: i spoke for Fedora/CentOs , but anyone can ask for Suse/Arch/Gentoo/Mageia .....

There are two concerns:

  1. Can the TLS library (such as OpenSSL or GnuTLS) parse Let's Encrypt certificates?

    The answer is virtually always "yes", because the last backwards incompatible change (SHA-256) to common certificates was a while ago and virtually everything has either upgraded or died since then.

    (Besides, every CA is affected by that.)

    (Let's Encrypt's older intermediates also had some problems on Windows XP due to a software limitation, but that was resolved by the current ones.)

  2. Does the OS (such as Debian or Fedora) or software (such as Java or Firefox) include a list of trusted CAs, and is Let's Encrypt included?

    OSes generally do come with a CA trust store. Several programs, notably Mozilla software and Oracle Java, do as well. Linux distributions usually copy Mozilla's.

    As documented on the Chain of Trust page, Let's Encrypt's intermediates are cross-signed by the CA called IdenTrust using their DST Root CA X3 root certificate. That root should be included nearly everywhere, probably for many years.

    Debian, for example, added it to their (Mozilla-derived) ca-certificates package in 2008. (I've read the changelog.)

    I know Gentoo's equivalent package (derived from Debian) also supports it. I don't know precisely when it was added, but it's been there since at least 2009. (I looked at the oldest list of files on the Gentoo package website.)

    Fedora's equivalent package (also derived from Mozilla's list) also supports it. I have no idea when it was added, but it was probably years ago. (I only checked the most recent package sources.)

    As documented at the above link, Let's Encrypt also has their own root called ISRG Root X1, but they only created it recently (of course), and trust stores have only recently started to add it. It is, however, supported by recent versions of Debian, Fedora, Gentoo and Firefox. But it's not very practical to use yet.

It usually should.

$ wget -O /dev/null https://helloworld.letsencrypt.org/
--2017-01-27 00:26:55--  https://helloworld.letsencrypt.org/
Resolving helloworld.letsencrypt.org (helloworld.letsencrypt.org)... 52.9.173.94
Connecting to helloworld.letsencrypt.org (helloworld.letsencrypt.org)|52.9.173.94|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5313 (5.2K) [text/html]
Saving to: ‘/dev/null’

/dev/null                                 100%[=====================================================================================>]   5.19K  --.-KB/s    in 0s      

2017-01-27 00:26:55 (703 MB/s) - ‘/dev/null’ saved [5313/5313]

$ wget -O /dev/null https://untrusted-root.badssl.com/
--2017-01-27 00:27:18--  https://untrusted-root.badssl.com/
Resolving untrusted-root.badssl.com (untrusted-root.badssl.com)... 104.154.89.105
Connecting to untrusted-root.badssl.com (untrusted-root.badssl.com)|104.154.89.105|:443... connected.
ERROR: cannot verify untrusted-root.badssl.com's certificate, issued by ‘CN=BadSSL Untrusted Root Certificate Authority,O=BadSSL,L=San Francisco,ST=California,C=US’:
  Unable to locally verify the issuer's authority.
To connect to untrusted-root.badssl.com insecurely, use `--no-check-certificate'.

If you want, you can check the current versions of different software and OSes, and research the history of their CA trust store packages, but that's it for my personal knowledge.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.