Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom CA Certs are ignored #257

Open
1 of 2 tasks
anatoli26 opened this issue Apr 22, 2020 · 11 comments
Open
1 of 2 tasks

Custom CA Certs are ignored #257

anatoli26 opened this issue Apr 22, 2020 · 11 comments
Labels
App Issue affects the standalone application bug

Comments

@anatoli26
Copy link

anatoli26 commented Apr 22, 2020

Prerequisites

  • Tried the most recent nightly build
  • Checked if your issue is already reported.

Is your feature request related to a problem?

There is an error message (subj) when the certificate chain of the server is self-signed, BUT the root CA is in the trusted store.

Describe the solution you'd like

To support self-signed trusted root CA certificates. I.e. there's a corporate root cert deployed on all machines. All programs recognize it, except Sieve.

Additional context

Ubuntu 16.04 in this case.

@thsmi
Copy link
Owner

thsmi commented Apr 22, 2020

Is this about the App or the WebExtension?

Can upload a screenshot or post the full error message which is displayed?

The validation error has to be one of the following strings https://github.com/openssl/openssl/blob/master/crypto/x509/x509_txt.c

@anatoli26
Copy link
Author

This is about the App.

cert

@thsmi
Copy link
Owner

thsmi commented Apr 22, 2020

The OpenSSL documentation says the following:

  X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: self signed certificate in certificate chain
  
      the certificate chain could be built up using the untrusted certificates but the root could not be found locally.

In short your chain is valid but the root's CA Cert is not installed on your machine or not available in the cert store.

A nice description can be can be found here
https://stackoverflow.com/questions/12180552/openssl-error-self-signed-certificate-in-certificate-chain

So this seems to me that it is an incomplete configuration. Especially since the verification is provided by the electron core. Which is mostly identical with the Chrome Browser's core. So it would be really strange if Chrome and everything which has the same base would not fail with the very same verification error.

@thsmi thsmi added the App Issue affects the standalone application label Apr 22, 2020
@anatoli26
Copy link
Author

Sure, the custom root CA certificate is installed. I don't have chrome to try it, but all other programs, even the CLI ones (wget, curl) work correctly. I guess the App doesn't check the root store paths of the system, but rather tries its own embedded public root CA certs.

@thsmi
Copy link
Owner

thsmi commented Apr 22, 2020

I did some research. It is as always way more complicated...

The fronted which is used for rendering uses the CA Store provided by the Chromium Framework which uses the default System store.

But the node server uses by default the bundled Mozilla CA Store instead of the OpenSSL's default CA Store. The Mozilla CA Store is the default, as the OpenSSL Store is only available on Linux. So the default behavior is identical to Firefox, which ignores the system CAs by default.

As the application's backed runs inside the node server, it should be theoretically possible to switch from the Mozilla CA Store to the OpenSSL Store via a commandline argument:
https://nodejs.org/api/cli.html#cli_use_bundled_ca_use_openssl_ca

But the sad news is, these command line switch are not supported on electron:
https://www.electronjs.org/docs/api/environment-variables#node_options

Which means there is currently no official support to change/extend the default CAs from Mozilla to OpenSSL. The following pins down the current situation quite nicely:
electron/electron#10257 (comment)

It might be worth a try to set NODE_EXTRA_CA_CERTS Environment Variable.
export NODE_EXTRA_CA_CERTS=[your CA certificate file path]
This seemed to work for some user.

Sadly this is a bug in the electron core without any workaround. Which makes this difficult to workaround it might be impossible.

The previously mentioned ticket also contains a workaround which looks promising (electron/electron#10257 (comment)).

So could you try the following?

First open the developer tools in the app so that you can inject javascript code.

You can do this by selecting the "View" in the Menubar and then "Toggle Developer Tools". In the developer tools switch to "Console" and ensure the scope is set to "Top". You can do this in the tiny dropdown left of the Eye Symbol.

Then paste the following code into the command line. And run it by pressing the enter key. But please adjust the path in the readFileSync so that it points to your ca cert.

(function(){
	try{
		var extraca = require("fs").readFileSync("/path/to/your/ca");
	}catch(e){
		return;
	}
	
	var NativeSecureContext = process.binding('crypto').SecureContext;
	var oldaddRootCerts = NativeSecureContext.prototype.addRootCerts;
	NativeSecureContext.prototype.addRootCerts = function(){
		var ret = oldaddRootCerts.apply(this,arguments);
		this.addCACert(extraca);
		return ret;
	};
})();

If case the code does not throw an error. It would be interesting to know if the validation error is now gone and if the ca was added persistently.

@thsmi thsmi changed the title Your mail server's authenticity cannot be verified! Custom CA Certs are ignored Apr 22, 2020
@thsmi thsmi added the bug label Apr 22, 2020
@anatoli26
Copy link
Author

Hi!

After adjusting the path in the code you provided and executing it in the console it said 'undefined', but no apparent error was returned. And after that I added a couple of accounts more on the same server and there was no error. Not sure if it caches somehow the first reply to proceed or what, but I haven't seen the error anymore.

Anyway, thanks for investigating the issue and providing a solution! Much appreciated!

@anatoli26
Copy link
Author

BTW, I specified the full cert path. And the folder where all certs (system and additional custom root CA certs) are located is: /etc/ssl/certs.

@jerrac
Copy link

jerrac commented Aug 21, 2020

I think I'm running into this issue via Thunderbird

After turning on debugging, this is the last message I see in the error console:

Error while validating Certificate SieveRequire.jsm:167

Before that are lines that look like sieve connecting to my managesieve dovecot server and trying to starttls.

This is in an Ubuntu 18.04 vm, Thunderbird 68.10.0. And version 0.5.0 of the addon from the github releases page.

I've created my own CA on the vm, and added it to the trusted CAs both in Ubuntu, and in Thunderbird. Thunderbird connects just fine to imap and smtp using the certs I signed with the CA.

The Mozilla CA Store is the default, as the OpenSSL Store is only available on Linux. So the default behavior is identical to Firefox, which ignores the system CAs by default.

This is where I get confused by this issue. Shouldn't adding my CA to Thunderbird via its Certificate Manager Authorities tab be pretty much the same as if it was in the Mozilla CA Store?

@thsmi
Copy link
Owner

thsmi commented Aug 23, 2020

The root cause for you confusion is, that this ticket is about the app and not about the webextension which are at this point completely different.

The application runs inside an electron which is a Chromium plus a Node.js. So you endup having two cert stores the one shipped with Chromium which uses the system store. And the other one is the Mozilla's CA store runtime compiled into the Node.js implementation.

The Webextension runs inside Thunderbird, which it uses the CA Store compiled into Thunderbird. Which uses the Mozilla CA store implementation.

The Mozilla CA Store implementation is a portable library which can be easily integrated into other products. But it is an isolated standalone implementation without any integration in to your OS's default store.

Could you please spin off a new ticket and provide some more log traces Enable the following settings.

image

@rtpt-alexanderneumann
Copy link

I have the same problem described here: We use a custom CA certificate for the mail server and it was not trusted by the app. Running the function once (with the right file containing the CA certificate) was enough to connect to the server without a certificate verification error.

It was not persistent though. Closing the program and opening it again made it forget the CA certificate.

@rtpt-alexanderneumann
Copy link

I've patched the code for now, here's my patch:

diff -aur sieve.orig/resources/app/libs/libManageSieve/SieveClient.mjs sieve/resources/app/libs/libManageSieve/SieveClient.mjs
--- sieve.orig/resources/app/libs/libManageSieve/SieveClient.mjs	2021-11-08 00:23:44.000000000 +0100
+++ sieve/resources/app/libs/libManageSieve/SieveClient.mjs	2022-12-16 07:52:25.924691556 +0100
@@ -17,6 +17,24 @@
 const net = require('net');
 const tls = require('tls');
 
+function add_ca_cert() {
+  const fs = require('fs');
+
+  console.log("load additional ca cert");
+
+  let extraca = fs.readFileSync("/path/to/ca.cert");
+
+  var NativeSecureContext = process.binding('crypto').SecureContext;
+  var oldaddRootCerts = NativeSecureContext.prototype.addRootCerts;
+  NativeSecureContext.prototype.addRootCerts = function(){
+    console.log("add ca cert");
+    var ret = oldaddRootCerts.apply(this,arguments);
+    this.addCACert(extraca);
+    return ret;
+  };
+}
+
+
 /**
  * Uses Node networking to realize a sieve client.
  */
@@ -68,6 +86,8 @@
     this.secure = secure;
     this.secured = false;
 
+    add_ca_cert();
+
     this.socket = net.connect(this.port, this.host);
 
     this.socket.on('data', async (data) => {

@thsmi Would you be willing to merge a PR which adds loading additional certs specified by an environment variable? Then I can submit such a PR...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
App Issue affects the standalone application bug
Projects
None yet
Development

No branches or pull requests

4 participants