On Mon, Mar 29, 2021 at 10:57:00AM +0900, Michael Paquier wrote:
> + switch (port->hba->clientcertname)
> + {
> + case clientCertDN:
> + peer_username = port->peer_dn;
> + break;
> + default:
> + peer_username = port->peer_cn;
> + }
>
> This does not
On Fri, Mar 26, 2021 at 09:34:03AM -0400, Andrew Dunstan wrote:
> OK, here's a new patch. I hope to commit this within a few days.
Thanks!
+ switch (port->hba->clientcertname)
+ {
+ case clientCertDN:
+ peer_username = port->peer_dn;
+ break;
+ default:
+
On 3/24/21 12:54 AM, Michael Paquier wrote:
[numerous useful comments]
OK, here's a new patch. I hope to commit this within a few days.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index b4204
On Fri, Mar 05, 2021 at 04:01:38PM -0500, Andrew Dunstan wrote:
> Yeah, fixed this, added a bit more docco, and got rid of some bitrot.
I had a look at this patch. What you have here looks in good shape,
and I have come comments.
> + This option is probably best used in conjunction with a
On 3/4/21 2:16 PM, Joel Jacobson wrote:
> On Sat, Jan 30, 2021, at 22:18, Andrew Dunstan wrote:
>> ssl-match-client-cert-dn-v3.patch
>
> Spelling error of "conjunction":
> + This option is probably best used in comjunction with a
> username map.
>
>
Yeah, fixed this, added a bit more docc
On Sat, Jan 30, 2021, at 22:18, Andrew Dunstan wrote:
> ssl-match-client-cert-dn-v3.patch
Spelling error of "conjunction":
+ This option is probably best used in comjunction with a username map.
/Joel
On Wed, Mar 3, 2021 at 3:03 AM Jacob Champion wrote:
> On Fri, 2021-02-26 at 15:40 -0500, Andrew Dunstan wrote:
> > I think the thing that's principally outstanding w.r.t. this patch is
> > what format we should use to extract the DN.
>
> That and the warning label for sharp edges.
>
> > Should w
On Fri, 2021-02-26 at 15:40 -0500, Andrew Dunstan wrote:
> I think the thing that's principally outstanding w.r.t. this patch is
> what format we should use to extract the DN.
That and the warning label for sharp edges.
> Should we use RFC2253,
> which reverses the field order, as has been sugges
On Sat, Jan 30, 2021 at 04:18:12PM -0500, Andrew Dunstan wrote:
> @@ -610,6 +610,19 @@ hostnogssenc database
> user the verification of client certificates with any authentication
> method that supports hostssl entries.
>
> +
> + On any record using client cer
On 2/26/21 2:55 PM, Jacob Champion wrote:
> On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
>> 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
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> 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
> wi
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
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> 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.
> diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
> [...]
> + Common Name (C
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
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 expressi
On 1/29/21 8:18 AM, Daniel Gustafsson wrote:
>> On 28 Jan 2021, at 23:10, Andrew Dunstan wrote:
>> On 1/28/21 11:39 AM, Jacob Champion wrote:
>>> Unfortunately I don't really know what that solution should look like.
>>> A DSL for filtering on RDNs would be a lot of work, but it could
>>> potent
> On 28 Jan 2021, at 23:10, Andrew Dunstan wrote:
> On 1/28/21 11:39 AM, Jacob Champion wrote:
>>
>> Unfortunately I don't really know what that solution should look like.
>> A DSL for filtering on RDNs would be a lot of work, but it could
>> potentially allow LDAP to be mapped through pg_ident a
On 1/28/21 11:39 AM, Jacob Champion wrote:
> On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
>> I'm not sure where we want to go with the present patch. Do we want to
>> go with what we have and document the limitations more, or try to do
>> something more elaborate? If so, exactly what?
On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
> I'm not sure where we want to go with the present patch. Do we want to
> go with what we have and document the limitations more, or try to do
> something more elaborate? If so, exactly what?
After sleeping on it:
I think that if you expec
On 1/27/21 3:14 PM, Jacob Champion wrote:
> On Tue, 2021-01-26 at 18:43 +, Jacob Champion wrote:
>> On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
>>> The OpenSSL X509_NAME_cmp function use RFC 5280 section 7.1 and RFC 4517
>>> section 4.2.15 (which in turn reference RFC 4514 for
On Tue, 2021-01-26 at 18:43 +, Jacob Champion wrote:
> On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> > The OpenSSL X509_NAME_cmp function use RFC 5280 section 7.1 and RFC 4517
> > section 4.2.15 (which in turn reference RFC 4514 for the DN string format).
> > libnss has CERT_Asc
On Tue, 2021-01-26 at 13:49 +0100, Daniel Gustafsson wrote:
> Reading more on this it seems we would essentially have to go with RFC 4514,
> as
> it's the closest to a standard which seems to exist. Having done a lot
> research on this topic, do you have a gut feeling on direction?
Yeah, if we'r
> On 20 Jan 2021, at 20:07, Jacob Champion wrote:
>
> On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
>> + /* use commas instead of slashes */
>> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
>> I don't have strong opinions on whether we s
On Wed, 2021-01-20 at 19:07 +, Jacob Champion wrote:
> I think you'll want to be careful to specify the format as much as
> possible, both to make sure that other backend TLS implementations can
> actually use the same escaping system and to ensure that user regexes
> don't suddenly start match
On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
> + /* use commas instead of slashes */
> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
> I don't have strong opinions on whether we shold use slashes or commas, but I
> think it needs to be do
I've circled back to this and tested/read it more, and I'm still of the opinion
that it's a good feature addition. A few small comments on the patch:
+ is the default, the username is matched against the certificate's
In the docs we use "user name" instead of "username" in descriptive text.
> On 18 Nov 2020, at 19:01, Andrew Dunstan wrote:
> OK, here's a new patch, including docco and tests.
Looks good on a quick skim, the only thing that stood out was:
+ This option is probably best used in comjunction with a username map.
s/comjunction/conjunction/
Will do more testing an
On 11/12/20 4:21 PM, Andrew Dunstan wrote:
> On 11/12/20 8:37 AM, Daniel Gustafsson wrote:
>>> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
>>> If people like this idea I'll add tests and docco and add it to the next CF.
>> Sounds like a good idea, please do.
>>
>> Can this case really happen
On 11/12/20 8:37 AM, Daniel Gustafsson wrote:
>> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
>> If people like this idea I'll add tests and docco and add it to the next CF.
> Sounds like a good idea, please do.
>
> Can this case really happen in non-ancient OpenSSL version?
> + i
> On 11 Nov 2020, at 21:44, Andrew Dunstan wrote:
> If people like this idea I'll add tests and docco and add it to the next CF.
Sounds like a good idea, please do.
Can this case really happen in non-ancient OpenSSL version?
+ if (!x509name)
Doesn't this returnpath need a pfree(p
Greetings,
* Andrew Dunstan (and...@dunslane.net) wrote:
> Currently we only match the Common Name (CN) of a client certificate
> when authenticating a user. The attached patch allows matching the
> entire Distinguished Name (DN) of the certificate. This is enabled by
> the HBA line option "client
31 matches
Mail list logo
