On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > > On 08/28/2014 07:28 PM, Alexey Klyukin wrote: >> >> On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas < >> hlinnakan...@vmware.com> wrote: >> >>> On 08/24/2014 03:11 PM, Alexey Klyukin wrote: >>> >>>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas < >>>> hlinnakan...@vmware.com> wrote: >>>> >>>>> The patch doesn't seem to support wildcards in alternative names. Is >>> >>> that on purpose? >> >> >> Not really, we just did not have any use case for them, but it seems that >> RFC 5280 does not disallow them: >> >> " Finally, the semantics of subject alternative names that include >> wildcard characters (e.g., as a placeholder for a set of names) are >> not addressed by this specification. Applications with specific >> requirements MAY use such names, but they must define the semantics." >> >> I've added support for them in the next iteration of the patch attached to >> this email. > > > Hmm. So wildcards MAY be supported, but should we? I think we should follow > the example of common browsers here, or OpenSSL or other SSL libraries; what > do they do?
Yes, they seem to be supported. The function you've mentioned above (X509_check_host) specifically mentions wildcards in SANs at https://www.openssl.org/docs/crypto/X509_check_host.html: 'X509_check_host() checks if the certificate Subject Alternative Name (SAN) or Subject CommonName (CN) matches the specified host name, which must be encoded in the preferred name syntax described in section 3.5 of RFC 1034. By default, wildcards are supported and they match only in the left-most label; but they may match part of that label with an explicit prefix or suffix. For example, by default, the host name ``www.example.com'' would match a certificate with a SAN or CN value of ``*.example.com'', ``w*.example.com'' or ``*w.example.com''.' > > RFC 6125 section 6.4.4 Checking of Common Names says: > >> As noted, a client MUST NOT seek a match for a reference identifier >> of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, >> URI-ID, or any application-specific identifier types supported by the >> client. > > > So, to conform to that we shouldn't check the Common Name at all, if an > alternative subject field is present. While the RFC indeed says so, the OpenSSL implementation includes X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT flag (which, as far as I can see, is set to 1 by default), which makes it check for the CN even if DNS names in SAN are present. I'm not sure what is the reason behind section 6.4.4, and I think it makes sense to check CN as well, since it does not lead to the case of false matches. > > > Yeah, I think a certificate without CN should be supported. See also RFC > 6125, section 4.1. "Rules" [for issuers of certificates]: > >> 5. Even though many deployed clients still check for the CN-ID >> within the certificate subject field, certification authorities >> are encouraged to migrate away from issuing certificates that >> represent the server's fully qualified DNS domain name in a >> CN-ID. Therefore, the certificate SHOULD NOT include a CN-ID >> unless the certification authority issues the certificate in >> accordance with a specification that reuses this one and that >> explicitly encourages continued support for the CN-ID identifier >> type in the context of a given application technology. > > > Certificates without a CN-ID are probably rare today, but they might start to > appear in the future. Ok, I will change a patch to add support for this clause. > > > BTW, should we also support alternative subject names in the server, in > client certificates? And if there are multiple names, which one takes effect? > Perhaps better to leave that for a separate patch. Good question. The RFC 5280 section 4.2.1.6 does not restrict the certificates to be used only server-side, so the same rules should be applicable to the client certs. I'm wondering if there is an equivalent of RFC 6125 for the clients? PostgreSQL, however, checks different things on the backends and the clients, the formers are checked against the DNS name, while on the clients only the user name is checked. For this, I think, a SAN section with some custom identity type should be issued (the 4.2.1.6 does not list user names as a pre-defined identify type). Note that PostgreSQL can already support clients with multiple names via the user maps, so support for SAN is not that urgent there. On the other hand, should we, in addition to verification of client user names, verify the client names supplied during connections against the DNS entries in their certificates? Are there use cases for this? I do agree this should be the subject of a separate patch. Regards, Alexey -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
