[Alpine-info] Solaris 10: failure validating the SSL/TLS certificate

[Mark Crispin]

If it makes you feel better, you're not the only person to be confused by 
all this -- we are too!

There are as many as three directories involved:

[1] The location of CA certificates, set by the OpenSSL library
[2] The location of server certificate public keys, set by SSLCERTS in
     the IMAP build.
[3] The location of server certificate private keys, set by SSLKEYS in
     the IMAP build.

In the basic installation, all three directories are the same.  However, 
some people feel that [3] should be separated out into a protected 
directory (rather than just protected files), hence the separate SSLKEYS 
setting.  They may be right.

That leaves [1] and [2].  The original idea behind the SSLCERTS setting is 
that it be set to the same setting as [1].  SSLCERTS exists because the 
imapd/ipop3d server code needs to sniff in that directory outside of 
OpenSSL.

On the other hand, for maintenance/management purposes it may be that some 
sites would want to separate their CA certificates (which came from 
elsewhere) from their internal server certificates.

On Mon, 11 Feb 2008, Gary Mills wrote:

> On Sun, Feb 10, 2008 at 05:40:12PM -0800, Mark Crispin wrote:

>> On Sun, 10 Feb 2008, Gary Mills wrote:

>>> The individual CA certificates can be extracted from that file into

>>> text format with the `keytool' command.  I initially specified:

>>>   --with-ssl-certs-dir=/usr/local/alpine/certs

>>> with alpine's configure command and put all of the extracted CA

>>> certificates in that directory.

>>

>> That parameter sets the location of SSL/TLS *server* (imapd and ipop3d)

>> private certificates.  It has nothing to do with the location of SSL/TLS

>> CA certificates, which is defined by the OpenSSL library.

>

> It must have been `./configure --help' that fooled me then.  It just

> said `Path to SSL certificate directory'.  That must be for the

> server, not the client.  However, `strings alpine' shows many

> instances of that path.

>

>>> Doing a `truss' on alpine, I found that it was actually looking for:

>>>   /etc/sfw/openssl/certs/c33a80d4.0

>>> That is the correct hash, but it's in the wrong place.

>>

>> Actually, that is the right place; it is what is defined by the OpenSSL

>> library.  Unlike private certificates, CA certificates are public and

>> global for all applications.

>

> Okay, so it's the library that defines the location for the CA

> certificates.  That makes sense.  I'll put them there.

>

>>> `/etc/sfw/openssl/certs' is an empty directory on Solaris 10.  This

>>> certificate path comes from /usr/sfw/lib/libcrypto.so.0.9.7, with

>>> which alpine is linked.

>>

>> It might be worth asking SUN why that is an empty directory instead of

>> being populated with CA certificates.  I have never received a

>> satisfactory answer to that question from SUN (or any other vendor).

>

> I'll see if I can file a bug report.

>

>>> Apparently, alpine never tells the SSL layer

>>> to look in /usr/local/alpine/certs

>>

>> Nor should it.  There is no reason for Alpine to have its own private

>> store of CA certificates.  There should be one, global, public, set of CA

>> certificates for all applications on the system.

>>

>> If you think about it -- suppose your organization has its own CA for

>> internal systems.  Do you really want to have to install a separate copy

>> of that CA certificate for every dinky program that runs on your system?

>> Do you want to have to worry about the protections of one of those

>> duplicated CA certificate stores, so that some attacker can set up a MITM

>> attack without it ever being detected because there's a fake CA

>> certificate falsely assuring the victim that the site has been CA

>> certified?

>

> Sounds good to me.  I just needed to find the right place.

>

> --

> -Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-

>


-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.