On Wed, Jun 26, 2024 at 9:29 AM Calum Mackay <calum.mackay@xxxxxxxxxx> wrote: > > On 26/06/2024 2:04 am, Rick Macklem wrote: > > On Tue, Jun 25, 2024 at 12:48 PM Calum Mackay <calum.mackay@xxxxxxxxxx> wrote: > >> > >> On 25/06/2024 6:31 pm, Olga Kornievskaia wrote: > >>> On Fri, Jun 21, 2024 at 1:39 PM Calum Mackay <calum.mackay@xxxxxxxxxx> wrote: > >>>> > >>>> On 21/06/2024 4:33 pm, Olga Kornievskaia wrote: > >>>>> Hi Calum, > >>>>> > >>>>> My surprise was to find that having the DNS name in CN was not > >>>>> sufficient when a SAN (with IP) is present. Apparently it's the old > >>>>> way of automatically putting the DNS name in CN and these days it's > >>>>> preferred to have it in the SAN. > >>>>> > >>>>> If the infrastructure doesn't require pnfs (ie mounting by IP) then it > >>>>> doesn't matter where the DNS name is put in the certificate whether it > >>>>> is in CN or the SAN. However, I found out that for pnfs server like > >>>>> ONTAP, the certificate must contain SAN with ipAddress and dnsName > >>>> > >>>> Noted, thanks very much Olga, that's useful. > >>>> > >>>>> extensions regardless of having DNS in CN. I have not tried doing > >>>>> wildcards (in SAN for the DNS name) but I assumed gnuTLS would accept > >>>>> them. I should try it. > >>>> > >>>> Wildcard didn't seem to work for me in CN, but I may not have tried it > >>>> in SAN; I'll do that too. > >>> > >>> I have tried to use a wildcard in the SAN and that didn't work for me. > >>> How about you? Specifically, I tried in the SAN > >>> "DS:netapp*.linux.fake" and tried to mount netapp119.linux.fake which > >>> failed with "certificate owner unexpected" (meaning certificate didnt > >>> find anything match to netapp119.linux.fake. > > I don't know if this helps, but at least for the OpenSSL libraries, wildcards > > can optionally match a component in a DNS name or multiple components. > > For example: > > *.linux.fake could match netapp119.linux.fake, but not > > netapp119.subnet.linux.fake > > OR > > *.linux.fake could match both netapp119.linux.fake and > > netapp119.subnet.linux.fake > > OR > > *.linux.fake does not match anything. > > > > Which of the above is true depends on whether an argument to X509_check_host() > > is set to X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS, 0, or > > X509_CHECK_FLAG_NO_WILDCARDS. > > - I made X509_CHECK_FLAG_NO_WILDCARDS the default in FreeBSD, but it > > can optionally be set to either of the other values. > > > > I don't know if you guys use a similar call? rick > > Thanks Rick. > > The Linux handshake implementation (tlshd, in pkg ktls-utils) uses the > gnutls library, rather than openssl. gnutls does consider wildcards when > hostname matching by default, and tlshd doesn't disable that. > > > I've just noticed, in the gnutls docs: > > https://gnutls.org/manual/gnutls.html#X509-certificate-API > > gnutls_x509_crt_check_hostname2 > > … [wildcards] are only considered if the domain name consists of three components or more, and the wildcard starts at the leftmost position > > tlshd uses gnutls_certificate_verify_peers3() rather than > gnutls_x509_crt_check_hostname2(), and the …peers3() function does check > the hostname, so presumably the same restriction applies. Right. the man page for gnutls_certificate_verify_peers3 does say it follows RFC 6125 for hostname checking. > That would suggest that Olga's example ["netapp*.linux.fake"] wouldn't > be expected to work, since the wildcard isn't at the leftmost position. Interesting note! Thanks for getting it. I was looking at the rfc 6125 and it has this for the matching rules which to me seemed to mean that my netapp*.linux.fake should have been accepted (but it's a MAY in the RFC so there is that): The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). > However, my testing was using "*.dept.domain.com", which appears to > follow the rule above. I also tried having a cert with DNS: *.linux.fake and that worked. > gnutls doesn't seem to have quite the same level of option granularity > that you show above for openssl. > > > I'll test further later today. > > cheers, > calum. > > > > >> > >> hi Olga, yes, exactly the same here. Wildcards don't work for me in > >> either CN or SAN. > >> > >> What I've been doing in my testing, when the host full DNS name is > 64 > >> chars, is to use the simple hostname as the CN (for ease of > >> identification in e.g. "trust list") and the full DNS name in a SAN DNS: > >> extension, and that is working well. > >> > >> thanks, > >> calum. > >> > >> > > -- > Calum Mackay > Linux Kernel Engineering > Oracle Linux and Virtualisation >
