Re: Trust intermediate CA for client certificates - Mailing list pgsql-hackers

From Ian Pilcher
Subject Re: Trust intermediate CA for client certificates
Date
Msg-id 513AF85B.6080202@gmail.com
Whole thread Raw
Responses Re: Trust intermediate CA for client certificates  (Craig Ringer <craig@2ndquadrant.com>)
Re: Trust intermediate CA for client certificates  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On 03/07/2013 12:42 PM, Ray Stell wrote:
> What Tom said works for me.  Here is a page that gives an example and I think it demonstrates that the root CA does
notallow everybody in the gate, the chain has to be in place: 
>  http://stackoverflow.com/questions/1456034/trouble-understanding-ssl-certificate-chain-verification

That page doesn't even mention PostgreSQL.

> You can use the "openssl verify" command to test that the root is not wide open on it's own.

The issue is the behavior of the PostgreSQL server.  "openssl verify" is
germane only in that it points to the source of the problem -- OpenSSL's
insistence on ultimately validating all certificates against a self-
signed root CA.  This requires that the root CA certificate be present
in root.crt, which causes the server to accept connections from all
clients that can present a certificate chain leading to that root CA.

If you don't believe me, test with the attached files, which implement
the following hierarchy.

                    +---------+
                    | Root CA |
                    +---------+
                        /\
                       /  \
                      /    \
                     /      \
                    /        \
                   /          \
                  /            \
                 /              \
          +-----------+    +-----------+
          | Server CA |    | Client CA |
          +-----------+    +-----------+
                /\                \
               /  \                \
              /    \                \
             /      \                \
            /        \                \
           /          \                \
          /            \                \
         /              \                \
  +----------+      +--------+       +--------+
  | postgres |      | "Bad"  |       | "Good" |
  | (server) |      | client |       | client |
  +----------+      +--------+       +--------+

The goal is to configure the server such that the "good" client will
be allowed to connect (because its certificate is signed by the Client
CA), but the "bad" client will not be allowed to connect (because its
certificate is not signed by the Client CA).

You will find the following:

1. You cannot simply use client-ca,crt as $PGDATA/root.crt.  OpenSSL
   will not validate a client certificate without access to the root CA
   certificate.

2. To enable client connections, you must add the root CA certificate
   to $PGDATA/root.crt -- "cat client-ca.crt root-ca.crt > root.crt".

3. Once the root CA certificate is trusted, however, the "bad" client
   can also connect by using a certificate chain that includes the
   Server CA certificate --"cat bad-client.crt server-ca.crt >
   ~/.postgresql/postgresql.crt".

After looking at be-secure.c and investigating the way that OpenSSL
validates certificates, I do not believe that there is any way of
achieving the desired behavior with the current codebase.

Adding pgsql-hackers to see if there is any interest in a patch to add
this functionality.

--
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.
========================================================================

Attachment

pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: Fix pgstattuple/pgstatindex to use regclass-type as the argument
Next
From: Dann Corbit
Date:
Subject: Re: Why do we still perform a check for pre-sorted input within qsort variants?