Thread: How to setup chained CA?

How to setup chained CA?

From
ChoonSoo Park
Date:
Greetings,

I'm trying to setup SSL enabled postgresql environment. (PG: 9.1.6)
With a single root CA, everything works fine.

Machine 1: Create a self signed root certficate. Generate server certificate (server.crt) & client certificate (postgresql.crt) signed by the root certificate.
Machine 2 (Postgresql server): Copy root certificate, server.crt and server.key (0600) 
Machine 3 (Postgresql client): Copy root certificate, postgresql.crt and postgresql.key (0600)

This works perfect as written in the documentation.

Then I tried to test more complex thing - chained CA.

Scenario 1. Postgresql having server.crt signed by Root CA and one of clients having postgresql.crt signed by intermediate CA.

Machine 1: Created a new intermediate CA (ra.crt) signed by root certificate. Created a new client certificate signed by the intermediate CA.
                 Concatenated root CA & intermediate CA using 
                            openssl x509 -text -in root.crt > newroot.crt
                            openssl x509 -text -in ra.crt >> newroot.crt
Machine 2: Replace root.crt with newroot.crt and use existing server.crt/key and restart the postgresql
Machine 3: Replace root.crt with newroot.crt and use existing postgresql.crt/key.
Machine 4: Copy newroot.crt to root.crt and copy the new client certificate file.

Test Result:
Machine3 can successfully login (using psql) to the postgresql server.
Machine4 can't login (using psql) and error message: psql: SSL error: tlsv1 alert unknown ca

Scenario 2. Postgresql having server.crt signed by intermediate CA and all clients having postgresql.crt signed by intermediate CA.
All machines: concatenated root CA certificate from scenario1. 

Test Result:
Nothing can login to the postgresql. Same error message.

In the postgresql documentation (http://www.postgresql.org/docs/9.1/static/ssl-tcp.html), it is written as

"In some cases, the server certificate might be signed by an "intermediate" certificate authority, rather than one that is directly trusted by clients. To use such a certificate, append the certificate of the signing authority to the server.crt file, then its parent authority's certificate, and so on up to a "root" authority that is trusted by the clients. The root certificate should be included in every case where server.crt contains more than one certificate."

It sounds like concatenating server.crt and intermediate CA is the solution to my scenario#2. I tried to follow the way described in the document but it didn't work either.

Did I miss something or Anyone knows how to configure "chained CA (root & intermediate)" in postgresql?

Thank you,
Choon Park

Re: How to setup chained CA?

From
Tom Lane
Date:
ChoonSoo Park <luispark@gmail.com> writes:
> Then I tried to test more complex thing - chained CA.

> Scenario 1. Postgresql having server.crt signed by Root CA and one of
> clients having postgresql.crt signed by intermediate CA.

> Machine 1: Created a new intermediate CA (ra.crt) signed by root
> certificate. Created a new client certificate signed by the intermediate CA.
>                  Concatenated root CA & intermediate CA using
>                             openssl x509 -text -in root.crt > newroot.crt
>                             openssl x509 -text -in ra.crt >> newroot.crt

Not an SSL expert, but my recollection is that the order of the certs in
the file is significant, and this order is the wrong one: root cert goes
last.  Moreover, root.crt should basically only contain the trusted root
cert.  The chains of intermediate certs (plus a copy of the root cert)
belong in server.crt and the client-side postgresql.cert.  Not terribly
good design, probably, but you'd have to take that up with the openssl
folk not us.

FWIW, I *have* tested chained certs, and they do work for me per the
documentation; or at least did the last time I tried it about two years
ago.

            regards, tom lane


Re: How to setup chained CA?

From
ChoonSoo Park
Date:
Hello Tom,

Per your recommendation, I tried to append reverse order of certs.
1. On postgresql server side
1) create a self-signed root certificate
2) create an intermediate cert signed by root certificate
3) create a server.crt signed by the intermediate cert
4) append the intermediate cert to server.crt
5) append the root cert to server.crt
6) start up postgresql server

2. On postgresql client side
1) copy the self signed root.crt from postgresql server
2) create a postgresql.crt signed by root.crt
3) tried to connect to the postgresql server using psql
4) STILL FAILED with same error.

I tried "server.crt signed by root.crt and postgresql.crt signed by the intermediate cert and appending intermediate certs and root.crt to postgresql.crt". This didn't work either.

Anything wrong or missing in these steps?

Thank you,
Choon Park

On Tue, Oct 30, 2012 at 7:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
ChoonSoo Park <luispark@gmail.com> writes:
> Then I tried to test more complex thing - chained CA.

> Scenario 1. Postgresql having server.crt signed by Root CA and one of
> clients having postgresql.crt signed by intermediate CA.

> Machine 1: Created a new intermediate CA (ra.crt) signed by root
> certificate. Created a new client certificate signed by the intermediate CA.
>                  Concatenated root CA & intermediate CA using
>                             openssl x509 -text -in root.crt > newroot.crt
>                             openssl x509 -text -in ra.crt >> newroot.crt

Not an SSL expert, but my recollection is that the order of the certs in
the file is significant, and this order is the wrong one: root cert goes
last.  Moreover, root.crt should basically only contain the trusted root
cert.  The chains of intermediate certs (plus a copy of the root cert)
belong in server.crt and the client-side postgresql.cert.  Not terribly
good design, probably, but you'd have to take that up with the openssl
folk not us.

FWIW, I *have* tested chained certs, and they do work for me per the
documentation; or at least did the last time I tried it about two years
ago.

                        regards, tom lane