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.
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.
