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 dnsNameNoted, 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.
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.
However, my testing was using "*.dept.domain.com", which appears to follow the rule above.
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
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
