[BlueOnyx:19623] Re: Possible bug installing certificates for gui/sendmail

[Michael Stauber]

Hi Maurice,

> I think I have found a bug when installing a certificate for the server
> gui on 5209R. This certificate is also to be used for sendmail.
> 
> However, sendmail only presents the certificate itself and not the
> intermediates.
> 
> If I copy the file
> /etc/admserv/certs/ca-certs
> over
> /usr/share/ssl/certs/ca-bundle.crt
> and restart sendmail
> all works well and sendmail is, just like admserv, presenting the
> intermediates + certificate.
> 
> Can anyone confirm?

I can confirm this. I recently looked into it and encountered the same.
I was looking at the issue in relation to "Let's Encrypt" certificates.
When you install an SSL cert for the GUI, it's also used for Email.

However: The LE certificate also has one intermediate and Sendmail isn't
using that, as it pulls the intermediates from
/usr/share/ssl/certs/ca-bundle.crt where the LE intermediate isn't present.

Now with respect to that there are two problems. One is as far as the LE
certificates are concerned: I appended it's intermediate to
ca-bundle.crt and tested it. That uncovered one sad truth: The LE SSL
certificates will not work for email, because it's only certified for
Web and a couple of other purposes which specifically exclude usage for
email. So even with the intermediate in place any SSL cert check against
Sendmail will still fail, as the cert isn't valid for email usage. So
same as with a self-signed cert (or one with missing intermediate): The
connection will still use SSL, but will throw a cert validation
error-message.

As far as other certs with intermediates are concerned: I do have very
strong gripes with replacing ca-bundle.crt or appending anything to it
as this has some long term security implications.

On CentOS 5 & 6 there is one particular problem with this: Once you edit
or replace ca-bundle.crt, it will no longer be automatically updated
during OS updates that would usually update this file. So once
intermediates get pulled or updated, you'll be missing these updates.
This is a potentially bad situation and there really is no good solution
to this.

As far as fully updated CentOS 6 and CentOS 7 are concerned: RedHat has
finally recognized this as a culprit and has provided a new mechanism
that allows you to add your own root certificates in a way that it
doesn't bust the update mechanism. On CentOS 6 this needs to be
specifically activated first time around and on CentOS 7 it's already
active since initial release. But hardly used, as people usually don't
know about it.

The new feature is called "Shared System Certificates". With that
system, the correct method is to place the certificate to be trusted (in
PEM format) in /etc/pki/ca-trust/source/anchors/ and run
"update-ca-trust". If the certificate is in OpenSSL’s extended BEGIN
TRUSTED CERTIFICATE format, place it in /etc/pki/ca-trust/source
instead. On CentOS 6, you have to activate the system with
"update-ca-trust enable" after installing the update, which isn't needed
on CentOS 7 where it's already active.

See:
https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/

So we finally have a usable mechanism to deal with SSL certs that have
one or more intermediates. I'll update base-ssl for 5207R, 5208R and
5209R accordingly once I have caught up with a couple of other fixes
that are currently in the pipe.

-- 
With best regards

Michael Stauber