[Bug]: Let's Encrypt root CA isn't working properly

[leonekmi]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Electron Version

15.0.0
Reproduced on Electron 12, 13, 14

What operating system are you using?

Other Linux

Operating System Version

Arch Linux rolling

What arch are you using?

x64

Last Known Working Electron version

No response

Expected Behavior

The request to https://letsencrypt.org (or any Let's Encrypt secured website) should work in the main process as the certificate chain seems valid.

Actual Behavior

It doesn't work in the main process. However, it works in the renderer (with standard Fetch API) or in Node 16.5 REPL (also with Axios).

Testcase Gist URL

https://gist.github.com/fc9cc8d91df7d02f211698f9aceb0087

Additional Information

I think it's probably related to the recent expiry of DST Root CA X3 but strangely enough, it's working properly on the renderer and in a single Node app?

My understanding is that by default, Node.js uses a capture of the Mozilla trust CA, could it be that the Electron one is unsynced?

[StephenSorriaux]

Hi,

Exact same problem since the DST Root CA X3 expiration today.

[paulr113]

Hello,
I'm experiencing the exact same problem. This seems to be an urgent issue.

[shdunning]

Ditto.

[MangoPreme]

Experiencing the same issue right now.

[michalmajkalexogrine]

Same here.

[franelj]

Same on Electron 11

[guldil]

Same problem with an old electron 8.0 app, we didnt change anything since one year and it stop working today :

$ (node:17196) UnhandledPromiseRejectionWarning: Error: certificate has expired
    at TLSSocket.onConnectSecure (_tls_wrap.js:1317:34)
    at TLSSocket.emit (events.js:200:13)
    at TLSSocket._finishInit (_tls_wrap.js:792:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:606:12)
(node:17196) UnhandledPromiseRejectionWarning: Error: certificate has expired
    at TLSSocket.onConnectSecure (_tls_wrap.js:1317:34)
    at TLSSocket.emit (events.js:200:13)
    at TLSSocket._finishInit (_tls_wrap.js:792:8)
    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:606:12)
(node:17196) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:17196) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:17196) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:17196) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
$

i try to renew my certifcate on server, no luck.

[BarryCarlyon]

Same issue on Windows node v14.18.0
electron v10.1.0 and v15.0.0 tested

Also regenerated the server cert. No joy

[laurent22]

Is there any alternative to Let's Encrypt that could be used while the problem is being worked on?

[mchiron]

For those that have this problem and control of the server, you might want to change to your certificate for one that is still valid. If your acme client allows you to change CA, you can try ZeroSSL ACME Certs to replace your current LetsEncrypt. Since ZeroSSL signing certificate has not changed, it might work where your current LetsEncrypt one won't (Note that I did not test this).

[leonekmi]

One dirty workaround I found was to create a CA array and add it to the ca array of the https, tls agent like this:

export const ISRGCAs = [`-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----`];

// Then further in the code

import {Agent} from 'https';

const agent = new Agent({ca: ISRGCAs});

// Use it in your https wrapper like got, axios, etc.

Note that you cannot expand with tls.rootCertificates unless you remove some certs that cofuses resolution

[aaclayton]

Related thread with some findings on the LE forum, no solution yet: https://community.letsencrypt.org/t/issues-with-electron-and-expired-root/160991

The guidance from LE is to regenerate the certificate using the --preferred-chain advanced option to request a shorter certificate chain. For example certbot certonly -d <domain> --preferred-chain="ISRG Root X1". Unfortunately this does not seem to be working as expected.

[aaclayton]

Follow up on my prior message, the proposed approach there has worked properly with two modifications: removing the = in the --preferred-chain argument and doing a hard restart of nginx (rather than a reload) to force the new certificate live (I don't know why reload did not work in this case).

sudo certbot certonly --nginx -d <domain> --preferred-chain "ISRG Root X1"
sudo service nginx restart

Hope this solution helps others to obtain a valid shortened certificate chain until the long term issue is resolved at the Electron level.

[doesdev]

Well, this is a particularly disastrous bug. Certificate chain is completely valid by every metric and using every client... except Electron. Problem is the same in 16.0.0-alpha.2 even. Node client is fine, all browsers we've tried on Windows and Mac, OpenSSL, every SSL checker I've run it through reports all is healthy and good across the certificate chain. All certificates freshly re-generated.

We're pretty much dead in the water at the moment.

[laurent22]

Thanks @aaclayton, that fix seems to work fine for us.

[nathanlesage]

I tried @aaclayton's fix but my Electron app still refuses. I'm on Electron 14.0.0 and the server is using an Apache. I just force-renewed the certificates using the ISRG root as a preferred chain root, incl. restart and all that yadda yadda, but unfortunately unsuccessful.

[jviotti]

We (Postman.com) have a potential fix. Running some further tests and sending a PR if it all goes fine.

[khypsos]

For those who still have the problem.

We were using the fullchain.cer containing the certificate, the R3 and the new ISRG Root X1

We just removed the X1 from the fullchain.cer and like pure magic electron is back on again :)

Hope it helps

[benmordecai]

Here is the official Let's Encrypt statement: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

I tried using this solution...

Follow up on my prior message, the proposed approach there has worked properly with two modifications: removing the = in the --preferred-chain argument and doing a hard restart of nginx (rather than a reload) to force the new certificate live (I don't know why reload did not work in this case).

sudo certbot certonly --nginx -d <domain> --preferred-chain "ISRG Root X1"
sudo service nginx restart

Hope this solution helps others to obtain a valid shortened certificate chain until the long term issue is resolved at the Electron level.

... but my version of certbot (0.31.0) does not support the --preferred-chain option. Since I am running debian 10, 0.31.0 is the latest version.

[jviotti]

Here is the PR: #31213. It seems to work fine for us but if you could also give it a spin, that would be great!

[leonekmi]

As suggested here, removing the last certificate present in fullchain and reloading/restarting the webserver seems to work as a quick'n'dirty fix.
Tested on Apache and Nginx.

[nathanlesage]

@benmordecai Yeah they stopped shipping Certbot updates via APT a while ago, I had to notice as well. They now offer snap packages. Just follow their instructions here to update to the newest version

[MrPrimate]

FYI If you're using Caddy the following worked for me:

domain.com {
    reverse_proxy localhost:3000
    tls {
        issuer acme {
            preferred_chains {
                root_common_name "ISRG Root X1"
            }
        }
    }
}

I had to remove my current certificates, and restart caddy.

[Ciberusps]

If u use axios for requests temporary workaround might be just to disable SSL temporary, works fine for us as a temporary solution until fix

const agent = new https.Agent({
  rejectUnauthorized: false,
});

axios.defaults.httpsAgent = agent;

P.S. same problem with certs on electron@11.4.3
UPD also problem with another app on electron@8.2.5 cert 100% valid & also reproduces with https://letsencrypt.org

[guldil]

I solved the problem by buying a $15 certificate after two and a half hours of fruitless searching. Users of my application have been blocked for too long... Now i can wait one year for a fix !

[sudhamab]

replacing the cert worked for us also

[s-a]

was this issue closed by commit? pretty interested in if this is already fixed. Btw I figured out that this is not an issue in nodejs apps

[Derkades]

was this issue closed by commit? pretty interested in if this is already fixed. Btw I figured out that this is not an issue in nodejs apps

#31213

[s-a]

@Derkades ty very much for your help! can you help me to figure out on what releases this fix was deployed. i am struggling find that in release notes. already migrated to v15 latest version but error resist. topic is pretty urgent in my company :/

[TitanRob16]

Totally annoying. I've tried every command in this thread to no avail. I've still got the "unrecognized arguments: --preferred_chain=ISRG Root X1" error from certbot on a Debian system.

[s-a]

You can skip it with process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'; (not recommended but perhaps temporary)

[Nicd]

Please don't suggest process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'; without explaining that it will completely disable TLS certificate validation. This means that any TLS connection you make is insecure, which may be fine only in very specific circumstances. (Many people will just copy whatever workaround they find mentioned in the comments without finding out what the implications are.)

[datacosmos]

@s-a : electron 15.1.2 works for me. Did you try to remove node_modules dir and npm install?
@TitanRob16 : you'll need to install the newest certbot version on your system.
But beware: when you use this workaround (or the other one just deleting the last cert in the keychain.pem) older android devices and operating systems will instead have a certificate error!

IMHO the best solution is using temporarly trustSSL (they have also a free 30 day cert, with quick email validation), fix the electron app and return to let's encrypt.
HTH

[s-a]

@datacosmos Yes, but nevertheless you are right! I am stupid. Thanks for confirmation 😅

[alielmajdaoui]

For those who still have the problem.

We were using the fullchain.cer containing the certificate, the R3 and the new ISRG Root X1

We just removed the X1 from the fullchain.cer and like pure magic electron is back on again :)

Hope it helps

works well!

Please consider removing the same cert from the chain.pem file as well to prevent this error:

Renewal configuration file /etc/letsencrypt/renewal/example.com.conf produced an unexpected error: fullchain does not match cert + chain for example.com!. Skipping.

[cappicard]

One dirty workaround I found was to create a CA array and add it to the ca array of the https, tls agent like this:

export const ISRGCAs = [`-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----`];

// Then further in the code

import {Agent} from 'https';

const agent = new Agent({ca: ISRGCAs});

// Use it in your https wrapper like got, axios, etc.

Note that you cannot expand with tls.rootCertificates unless you remove some certs that cofuses resolution

This suggestion is what I am using. In my case, it's with the version of Electron provided by Expo.

[jaovitubr]

On a few computers when I try to load my site, I get the error ERR_CERT_DATE_INVALID, and when I configure it to ignore certificate errors, I get the error ERR_TIMED_OUT
I'm thinking that the problem is with the Let's Encrypt certificates, when I try to access for example https://letsencrypt.org/ or https://www.nginx.com/ it doesn't load, but when I try to access https://www.mozilla.org/ or https://www.google.com/ loads fine!

Electron 22.3.4