Re: Allow matching whole DN from a client certificate - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Allow matching whole DN from a client certificate
Date
Msg-id fd96ae76-a8e3-ef8e-a642-a592f5b76771@dunslane.net
Whole thread Raw
In response to Re: Allow matching whole DN from a client certificate  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Allow matching whole DN from a client certificate  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On 1/29/21 10:10 AM, Andrew Dunstan wrote:
> On 1/28/21 5:10 PM, Andrew Dunstan wrote:
>>> (I'd still recommend switching to use the RFC
>>> flag to OpenSSL, to ease future improvements.) There should be a bunch
>>> of warning documentation saying not to do anything more complex unless
>>> you're an expert, and that the exact regular expression needed may
>>> change depending on the TLS backend.
>> I'll play around with the RFC flag.
>>
>>
>>> If you want to add UTF-8 support to the above, so that things outside
>>> ASCII can be matched nicely, then the ASN1_STRFLGS_ESC_MSB flag should
>>> be removed from the _print_ex() call per OpenSSL documentation, and we
>>> should investigate how it plays with other non-UTF-8 database
>>> encodings. That seems like work but not a huge amount of it.
>> How about if we remove ASN1_STRFLGS_ESC_MSB when the server encoding is
>> UTF8? That should be an extremely simple change.
>>
>>
>>
> Of course, we don't have any idea what the database is at this stage, so
> that wasn't well thought out.
>
>
> I'm inclined at this stage just to turn on RFC2253. If someone wants to
> deal with UTF8 (or other encodings) at a later stage they can.
>
>

Here's a version of the patch that does it that way. For fun I have
modified the certificate so it has two OU fields in the DN.

Finding out how to generate the new cert without regenerating everything
else was also fun :-) Here's what I did in a pristine source with patch
applied, but where configure hasn't been run:

    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
    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?


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com


Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: WIP: BRIN multi-range indexes
Next
From: Peter Eisentraut
Date:
Subject: Re: Is it worth accepting multiple CRLs?