Hello all,
I’ve got a question regarding the file ‘cacert.pem’ located at https://curl.haxx.se/docs/caextract.html. It may contain all CA certificates and I did not find the Let’s Encrypt entry in this file.
The main issue is that the application ‘ocsinventory’ (see https://www.ocsinventory-ng.org) that we use in our structure requires to check CA certificate before establishing a SSL connexion between client and server, and checks this certificate from the cacert.pem file, and cannot do it because it does not find any reference to Let’s Encrypt in it.
Any information about this file, and the presence or absence of Let’s Encrypt CA certificate in this file is welcome !
I haven’t examined it, but it should.
Let’s Encrypt certificates normally chain to IdenTrust’s DST Root CA X3, which has been in Mozilla’s trust store for like a decade.
You can instead use Let’s Encrypt’s ISRG Root X1, which has been in it for… a year? Give or take?
Unless the curl file excludes them for some reason, they’ll be included.
Maybe the server is configured incorrectly? Could you provide more information about it?
Thank you mnordhoff,
I’ve found 2 entries in the cacert.pem file which correspond to ‘IdenTrust’, I found 1 entry which correspond to ‘ISRG’, no entry specific to Let’s Encrypt.
I shall try again to use this cacert.pem fil for authentication and come back with the results.
Apart from that the server is presumably correctly configured as it works for 90% of our park (SSL connexion problems with only 10% of clients)
Works for what clients?
If, for example, the server's certificate chain wasn't correct, browsers can usually handle it, but more basic clients usually can't.
I'm getting ahead of things, though. I'm not familiar with OCS Inventory. and without more information, I can only guess at what might be wrong. 
What's OCS Inventory doing? What error message does it report? How is it configured? How is the other software configured?
You may need to ask OCS Inventory's support, if no one here has expertise with it and we aren't able to figure it out.
It’s worth pointing out that the ISRG root is the Let’s Encrypt root. ISRG (Internet Security Research Group) is the name of the organization behind Let’s Encrypt.
That being said, the default intermediate certificate currently in use chains back to the IdenTrust root. If the connection attempts fail anyway, that points to either a configuration problem on the web server (missing intermediate certificate) or a bug in the path validation algorithm of that software.
1 Like
Hello mnordhoff, thanks for your time 
OCS inventory reports machine configuration towards aggregation server, via SSL connexion. Our OCS server is configured with Let's Encrypt certificate. This configuration works fairly well for a selection of machines (90% of our park), but on some machines (likely some Windows 7, 8 and 10) we get an error like :
Failed to send prolog <Problem with the SSL CA cert (path? access rights?)>
I discovered that, when I provide the client conf on the faulty machine, with the cacert.pem file (the one which can be downloaded at https://curl.haxx.se/docs/caextract.html to which I have manually added the certificate 'cert.pem' that I find in /etc/letsencrypt/live/domain.net/cert.pem on the OCS server, then it works.
Of course this solution is not viable as I would have to change the cacert.pem on each client machine every 3 months...
I will try to add this 'intermediate certificate' onto the OCS server and come back. No idea of how to proceed at this time but I'll find 
Ah, that’s not the intermediate. That’s your certificate.
Let me briefly explain how this works, as I think it can help you fix what’s wrong if we’re right about the problem.
A trust store like cacert.pem is a set of “root” CAs which are trusted absolutely. In a toy system, or in the very old days, the root CAs would directly sign a certificate for somebody like you or me, a “leaf” certificate. This is like if you grow carrots, you can see leaves come straight out of the root.
So, bigger Public Key systems, including any the modern Web PKI have one or more steps between the root and the leaf called Intermediates, like the way a tree has branches between the roots and the leaves. The root signs the Intermediate, the Intermediate might sign another smaller Intermediate, and eventually an Intermediate signs your leaf certificate.
To achieve trust, it is necessary to follow the path from the root to the leaf, your cacert.pem file has the DST Root CA X3 root in it, and your server is presenting its leaf certificate, but you need to arrange to present also the certificates for the Let’s Encrypt Authority X3 which is between the two. This may be in a file named chain.pem, depending on exactly which software you used to obtain a Let’s Encrypt certificate. If you software has an option to configure a separate “chain” or “intermediate” you should tell it to use chain.pem for that. If the software only has one place to put a certificate, you should see if it’s possible to use fullchain.pem, which is a file containing your leaf certificates AND the intermediate together, many programs can accept this.
1 Like
Many thaks tialaramex 
I’m using certbot to get the servers’ certificates. This gives me 4 files every 3 months:
- cert.pem
- chain.pem
- fullchain.pem
- privkey.pem
Following your very pedagogic explanations, in my Apache configuration, I replaced ‘cert.pem’ by ‘fullchain.pem’, and now, everything works fine ! I get 100% of my park of machines sending reports to OCS server 
Cheers
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.