Bundling and Installing the ISRG Root X1 root certificates in Manageengine Desktop Central

Hi,
I(Ashwin) am from development team of ManageEngine Desktop central. We are using few domains whose ssl certificates are signed by Let's Encrypt CA(ISRG Root X1).

https://patchdb.manageengine.com/
https://patchdatabase.manageengine.com/

In some legacy machines, our Agent software is not able to establish secure communication with our server. Since the root certificate is missing in the machine's trust store.

These machines are not able to update the server certificates automatically (some of the reasons are mentioned below).

  1. Limited access to the internet (Windows not able to update root certificates via Windows Root Certificate Program).
  2. Missing windows update (Windows Root Certificate Program update not installed on the machine).

We are planning to detect the certificate error in our troubleshooting tool and install the missing root certificates.
On doing some research, we were able to find the following link which provides a direct download link for root certificates.

We have a few queries regarding installing the root certificates

  1. Can we install LetsEncrypt Root Certificates in customer machine that we manage?
  2. Do we need to get consent from our customer?
  3. Legally are we(ME) allowed to bundle and distribute the LetsEncrypt Root certificate?
  4. Is it recommended to download from the direct url instead of bundling?
  5. Please suggest us if there is any other way to overcome the root certificate missing cases.

Yes.

No clue, I'm not a lawyer. If you're already asking this, personally I wouldn't have much faith in a random, anonymous, non-lawyer nickname on the internet :wink:

Again, not a lawyer. You can find all the relevant statements here: Policy and Legal Repository - Let's Encrypt

I don't see a reason not to bundle. Root certificates have a long lifetime. I do think you'd need to have a plan for updating the root certificates in the future though. Even if that plan is "manually do the same thing in 10 years from now". :wink:

4 Likes

It's a public certificate, so by definition it's for public distribution and it's included in many things (like ca certificate bundles).

Certify The Web (https://certifytheweb.com) distributes this root cert, and other common ones, to machines (generally servers) it's installed on, and nobody has sued us yet :slight_smile: - they're welcome to try though! In general all software installs already have an adequate disclaimer regarding the fact the organisation installing the software is opting in to the functionality the software provides.

Really if someone doesn't want to trust a CA then they would just mark the root certs as specifically untrusted, that's up to them. I've yet to see a customer intentionally opting out of CA root updates for any good reason other than a few years ago windows didn't like having too many root certs so administrators commonly disabled the CA cert updates in group policy and forgot about it.

Personally I'd say just bundle it, include it clearly in your release notes and install it into Local Machine Trusted Root Certification Authorities. I've seen gaming mouse drivers that installed their own self-signed root cert, so in terms of correctness I think you are improving the continued functionality of the client machines, not impeding it. Currently those machines are unable to use many sites on the internet, and after your update they will be able to, so you're doing them a favour.

3 Likes

I do remember suggesting somewhere that someone should come up with a simple cross platform tool that updates trusted CA roots to sane defaults, but really this is primarily the job of the OS vendor, secondarily it's the job of the administrator, then if all else fails apps need to take things into their own hands (this is also exactly how common framework/software library updates happen, especially on Windows).

3 Likes

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