Re: Allow matching whole DN from a client certificate
От | Andrew Dunstan |
---|---|
Тема | Re: Allow matching whole DN from a client certificate |
Дата | |
Msg-id | fd96ae76-a8e3-ef8e-a642-a592f5b76771@dunslane.net обсуждение исходный текст |
Ответ на | Re: Allow matching whole DN from a client certificate (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Allow matching whole DN from a client certificate
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: