CA installed and working for OpenSSL but fails with Email app [answered]

Question

8

CA installed and working for OpenSSL but fails with Email app [answered]

asked 2014-09-16 15:09:05 +0200

nik
178 ●4 ●7 ●13

updated 2014-09-16 17:26:31 +0200

Hi,

I am trying to get my email to work without having to accept untrusted certificates. I have installed my root CA cert as described here.

Testing the root CA cert with openssl verify returns OK. Testing with openssl s_client -connect myserver.net -CApath /etc/pki/tls/certs is successful as well - connection established and the cert checks return no error codes. Still, when I try to set up the email account, it fails and asks me to 'Check certificate' There seem to exist multiple cert storages on the jolla, possibly I need to add the root certs elsewhere as well? Is it documented anywhere what is the purpose of having what seems to be identical certs in /etc/ssl/certs and /etc/pki/tls/certs?

Edit: Ultimately (and much more briefly put) the question is what cert store does the Email app use?

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by VDVsx
close date 2014-09-25 16:58:40.288273

Comments

+! I have the same problem

ortylp ( 2014-09-16 21:21:57 +0200 )edit

Are you sure entire chain is trusted ? Check with:

echo '' | openssl s_client -connect YOUR_MAILSERVER:YOUR_ACESS_PORT | openssl x509 -fingerprint -text

VDVsx ( 2014-09-19 15:30:00 +0200 )edit

I use self signed cert so there is not really a chain. I have imported the same cert into Android (on SG Note with CM) and it worked there.

I think the best policy is what each SSH client uses, and wha t K9 implements in regards to certificates: show the certificate to the user for confirmation on first use and then trust it until configuration changes or gets cleared.

ortylp ( 2014-09-19 18:30:46 +0200 )edit

It seems my work email provider has distributed server system, where not all servers in their workload farm send also the intermediate certificate during TLS handshake. This was easy to confirm by repeatedly performing curl -kIv1 https://example.com and getting either SSL certificate verify ok. or SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

The only way to get rid of email app cover error message (check account or something close to that, I use Finnish) was to actually add the often-missing certificate to /etc/pki/tls/certs/ca-bundle.crt

The other certificates in that file include the "verbal" part too, but that's just for the humans reading the file, right?

Direc ( 2015-06-27 21:27:44 +0200 )edit

+! I have the same problem
ortylp ( 2014-09-16 21:21:57 +0200 )edit
Are you sure entire chain is trusted ? Check with:
echo '' | openssl s_client -connect YOUR_MAILSERVER:YOUR_ACESS_PORT | openssl x509 -fingerprint -text
VDVsx ( 2014-09-19 15:30:00 +0200 )edit
I use self signed cert so there is not really a chain. I have imported the same cert into Android (on SG Note with CM) and it worked there.
I think the best policy is what each SSH client uses, and wha t K9 implements in regards to certificates: show the certificate to the user for confirmation on first use and then trust it until configuration changes or gets cleared.
ortylp ( 2014-09-19 18:30:46 +0200 )edit
It seems my work email provider has distributed server system, where not all servers in their workload farm send also the intermediate certificate during TLS handshake. This was easy to confirm by repeatedly performing curl -kIv1 https://example.com and getting either SSL certificate verify ok. or SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.

The only way to get rid of email app cover error message (check account or something close to that, I use Finnish) was to actually add the often-missing certificate to /etc/pki/tls/certs/ca-bundle.crt

The other certificates in that file include the "verbal" part too, but that's just for the humans reading the file, right?
Direc ( 2015-06-27 21:27:44 +0200 )edit

Accepted Answer

2

answered 2014-09-25 16:17:29 +0200

nik
178 ●4 ●7 ●13

I got this working, finally.

My CA setup has a root-ca cert and a sub-ca.cert, the second issuing the mail server cert. For a good while I was struggling with a chicken-and-egg problem, where if I supply the whole cert chain at the server side, I get a "self signed certificate in certificate chain" error. If I don't, then I get a "unable to get issuer certificate" error. Found it confusing that openssl seemed to expect a chain that did not end with a self-signed cert when clearly any chain has to end with one if you trace it to the end. Anyway, it seems that in this context "unable to get issuer certificate" is the error we should be after and a sign of a good set up ... The first (self-signed) cert should not be provided with the cert chain.

To prevent courier and postfix from sending the whole chain I had to make sure the root cert is NOT trusted on my mail server, but the sub is. Otherwise even if I did not concatenate it onto the server cert or configure it as part of the cert chain, it got sent nevertheless, and resulted in the "self-signed certificate in the certificate chain" error which seems to break things.

To answer my original question, I added the certificates to be trusted to /etc/ssl/certs and then created a symlink to them as described elsewhere.

edit flag offensive delete publish link

CA installed and working for OpenSSL but fails with Email app [answered]

The question has been closed for the following reason "the question is answered, an answer was accepted" by VDVsx
close date 2014-09-25 16:58:40.288273

Comments

1 Answer

Question tools

Stats

Related questions

CA installed and working for OpenSSL but fails with Email app [answered]

The question has been closed for the following reason "the question is answered, an answer was accepted" by VDVsx close date 2014-09-25 16:58:40.288273

Comments

1 Answer

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "the question is answered, an answer was accepted" by VDVsx
close date 2014-09-25 16:58:40.288273