Обсуждение: [GENERAL] Configuring ssl_crl_file
Hi, I was trying to set up PostgreSQL to use a certificate revocation list so I could revoke client certificates, but was unable to get it to work. I was following [this tutorial][1] to create root and intermediate CA certificates, then producing certificates for the PostgreSQL server and client. I have created a [Dockerfile][2] which shows the problem. The short story is that with the CRL I’ve created in PEM format, a client certificate is rejected with error “psql: SSL error: tlsv1 alert unknown ca”. If I don’t set ssl_crl_file, the client certificate is accepted. I tested on 9.4-9.6. I tried to find examples about using ssl_crl_file but wasn’t able to find anything. I found [this message][3] from 2014 without any replies. [1]: https://jamielinux.com/docs/openssl-certificate-authority/index.html [2]: https://github.com/RazerM/postgres_crl_test [3]: https://postgrespro.com/list/thread-id/1163456 Kind regards, Frazer McLean
I found a solution to the problem, which I’l send here to help those who find the original email via search. The intermediate CRL file must be concatenated to CRL files going back to the root CA. On 26 Feb 2017, at 15:42, Frazer McLean wrote: > Hi, > > I was trying to set up PostgreSQL to use a certificate revocation list > so I could revoke client certificates, but was unable to get it to > work. > > I was following [this tutorial][1] to create root and intermediate CA > certificates, then producing certificates for the PostgreSQL server > and client. > > I have created a [Dockerfile][2] which shows the problem. The short > story is that with the CRL I’ve created in PEM format, a client > certificate is rejected with error “psql: SSL error: tlsv1 alert > unknown ca”. If I don’t set ssl_crl_file, the client certificate > is accepted. > > I tested on 9.4-9.6. I tried to find examples about using ssl_crl_file > but wasn’t able to find anything. I found [this message][3] from > 2014 without any replies. > > [1]: > https://jamielinux.com/docs/openssl-certificate-authority/index.html > [2]: https://github.com/RazerM/postgres_crl_test > [3]: https://postgrespro.com/list/thread-id/1163456 > > Kind regards, > > Frazer McLean > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general
On Mon, Feb 27, 2017 at 12:11:47AM +0100, Frazer McLean wrote:
> I found a solution to the problem, which I’l send here to help those who
> find the original email via search.
>
> The intermediate CRL file must be concatenated to CRL files going back to
> the root CA.
I have researched this and will post a blog and and document the fix in
the next few months. The reason you have to supply the entire
certificate chain to the root CA on the client is because you have not
used the "-extensions v3_ca" flag to openssl when creating the CA x509
request. You have to mark the certificates as CAs so they are passed
from the server to the client. You are looking for the CA certificates
to say:
X509v3 Basic Constraints:
CA:TRUE
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
On 28 Feb 2017, at 21:51, Bruce Momjian wrote:
> I have researched this and will post a blog and and document the fix
> in
> the next few months. The reason you have to supply the entire
> certificate chain to the root CA on the client is because you have not
> used the "-extensions v3_ca" flag to openssl when creating the CA x509
> request. You have to mark the certificates as CAs so they are passed
> from the server to the client. You are looking for the CA
> certificates
> to say:
>
> X509v3 Basic Constraints:
> CA:TRUE
>
My `ca.cert.pem` file has
X509v3 Basic Constraints: critical
CA:TRUE
The `intermediate.cert.pem` has
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
This intermediate cert was generated using the `v3_intermediate_ca`
extension defined in [1]. I wouldn’t expect *not* to have to give the
full certificate chain to the client, since both were created by me.
To summarise my problem and solution: the connection worked fine until
`ssl_crl_file` was enabled. I was trying to use a CRL generated from the
intermediate CA, assuming PostgreSQL would trust it since it knows about
the full CA chain in `ssl_ca_file`. Apparently, it must be a CRL
generated from the root concatenated to a CRL generated from the
intermediate, and then it works.
[1]:
https://github.com/RazerM/postgres_crl_test/blob/dd9ef3ac4dd74d1cdfc6403899a09d954fd9622a/intermediate-config.txt#L99
Kind regards,
Frazer McLean
On Tue, Feb 28, 2017 at 10:50:02PM +0100, Frazer McLean wrote: > On 28 Feb 2017, at 21:51, Bruce Momjian wrote: > >I have researched this and will post a blog and and document the fix in > >the next few months. The reason you have to supply the entire > >certificate chain to the root CA on the client is because you have not > >used the "-extensions v3_ca" flag to openssl when creating the CA x509 > >request. You have to mark the certificates as CAs so they are passed > >from the server to the client. You are looking for the CA certificates > >to say: > > > > X509v3 Basic Constraints: > > CA:TRUE > > > > My `ca.cert.pem` file has > > X509v3 Basic Constraints: critical > CA:TRUE > > The `intermediate.cert.pem` has > > X509v3 Basic Constraints: critical > CA:TRUE, pathlen:0 > > This intermediate cert was generated using the `v3_intermediate_ca` > extension defined in [1]. I wouldn’t expect *not* to have to give the full > certificate chain to the client, since both were created by me. > > To summarise my problem and solution: the connection worked fine until > `ssl_crl_file` was enabled. I was trying to use a CRL generated from the > intermediate CA, assuming PostgreSQL would trust it since it knows about the > full CA chain in `ssl_ca_file`. Apparently, it must be a CRL generated from > the root concatenated to a CRL generated from the intermediate, and then it > works. Oh, OK, that is beyond my understanding. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +