Re: Allow matching whole DN from a client certificate

From: Jacob Champion <pchampion(at)vmware(dot)com>
To: "daniel(at)yesql(dot)se" <daniel(at)yesql(dot)se>, "andrew(at)dunslane(dot)net" <andrew(at)dunslane(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow matching whole DN from a client certificate
Date: 2021-02-22 18:00:51
Message-ID: 7701f747665ca337e982851cc26dbcd3c789e1c8.camel@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> cd src/test/ssl
> touch ../../Makefile.global
> rm -f ssl/client-dn.crt ssl/client-dn.key
> touch ssl/root_ca-certindex
> echo 01> ssl/root_ca.srl

Note that, on my machine at least, the root_ca serial counter is at 03
after running `make sslfiles`. 1 and 2 are already assigned to
server_ca and client_ca, respectively.

Speaking of which, what's the reason you need to recreate the root_ca
machinery when it's the client_ca that issues the new certificate?

> make ssl/client-dn.crt
> rm -rf ssl/*certindex* ssl/root_ca.srl ssl/new_certs_dir
> rm ../../Makefile.global
>
> Making incremental additions to the certificate set easier wouldn't be a
> bad thing.
>
> I wonder if we should really be setting 1 as the serial number, though.
> Might it not be better to use, say, `date +%Y%m%d01` rather like we do
> with catalog version numbers?

You could also check in the CA state files.

--Jacob

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-02-22 18:01:00 Re: Extensibility of the PostgreSQL wire protocol
Previous Message Markus Wanner 2021-02-22 17:34:13 Re: [HACKERS] logical decoding of two-phase transactions