Re: ktls-utils: question about certificate verification

[Calum Mackay <calum.mackay@oracle.com>]

On 25/06/2024 6:31 pm, Olga Kornievskaia wrote:
> On Fri, Jun 21, 2024 at 1:39 PM Calum Mackay <calum.mackay@oracle.com> 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.

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.