ktls-utils: question about certificate verification

ktls-utils: question about certificate verification

[Calum Mackay]

hi Olga,

A few weeks ago you and Chuck were discussing duplication requirements 
of the hostname in the CN field versus SAN extension in the certificate:

	https://lore.kernel.org/linux-nfs/CAN-5tyENK71L1C=6NwdB4mkxxf1qYZ2-4e-p8FQM=SmA3tMT_g@mail.gmail.com/


For what it's worth, my own testing showed that the SAN DNS: element 
doesn't need to duplicate the CN.

This is especially relevant in the case where the full DNS name is > 64 
chars, which is not strictly allowed as a CN (and openssl for example 
enforces that limit).

In that case, it works to put the short hostname in the CN, and the full 
DNS name in a SAN DNS: extension. There is no need to duplicate the CN 
entry in the SAN extension.

I also noted that using a wildcard CN (e.g. "*.acme.com") does not work.


I've yet to test mounting by IP, but will do so soon.


best wishes,
calum.

Re: ktls-utils: question about certificate verification

[Olga Kornievskaia]

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

Re: ktls-utils: question about certificate verification

[Calum Mackay]

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.

thanks again,
calum.

Re: ktls-utils: question about certificate verification

[Olga Kornievskaia]

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.

> thanks again,
> calum.
>

Re: ktls-utils: question about certificate verification

[Calum Mackay]

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.

Re: ktls-utils: question about certificate verification

[Rick Macklem]

On Tue, Jun 25, 2024 at 12:48 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>
> 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.
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

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

Re: ktls-utils: question about certificate verification

[Calum Mackay]

[-- Attachment #1.1: Type: text/plain, Size: 3886 bytes --]

On 26/06/2024 2:04 am, Rick Macklem wrote:
> On Tue, Jun 25, 2024 at 12:48 PM Calum Mackay <calum.mackay@oracle.com> wrote:
>>
>> 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.
> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: ktls-utils: question about certificate verification

[Olga Kornievskaia]

On Wed, Jun 26, 2024 at 9:29 AM Calum Mackay <calum.mackay@oracle.com> wrote:
>
> On 26/06/2024 2:04 am, Rick Macklem wrote:
> > On Tue, Jun 25, 2024 at 12:48 PM Calum Mackay <calum.mackay@oracle.com> wrote:
> >>
> >> 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.
> > 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
>

ktls-utils: question about certificate verification

[Olga Kornievskaia]

Hi Chuck,

I've ran into the following problem while trying to mount on RHEL9.4
client using xprtsec=tls. After some debugging I have determined that
the reason mount by DNS name was failing is because gnutls insisted on
having in SubjectAltName=DNS:foo.bar.com. Having a certificate that
has a DNS name in the "CN" and then had "SubjectAltName=IP:x.x.x.x"
was failing. But when I created a certificate with
"SubjectAltName:IP:x.x.x.x:DNS:x.x.x.x" then I could mount (or just
having DNS: works too but in that case mounting by IP doesn't work).

Here's the output from tlshd when it fail (with SubjectAltName "IP")::

tlshd[260035]: gnutls(3): self-signed cert found: subject
`EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
Arbor,ST=MI,C=US', issuer
`EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
Arbor,ST=MI,C=US', serial 0x751ad911565945cce5d29d1c206450538f496b90,
RSA key 2048 bits, signed using RSA-SHA256, activated `2024-05-31
15:07:53 UTC', expires `2024-06-30 15:07:53 UTC',
pin-sha256="Efzu7ftve1SHxBVAIwf81jwAasQ0M3j5qWbEVuM8X8I="
tlshd[260035]: gnutls(3): ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:111
tlshd[260035]: gnutls(3): ASSERT: x509.c[get_alt_name]:2011
tlshd[260035]: gnutls(3): ASSERT:
verify-high.c[gnutls_x509_trust_list_verify_crt2]:1615
tlshd[260035]: gnutls(3): ASSERT: auto-verify.c[auto_verify_cb]:51
tlshd[260035]: gnutls(3): ASSERT: handshake.c[_gnutls_run_verify_callback]:3018
tlshd[260035]: gnutls(3): ASSERT:
handshake-tls13.c[_gnutls13_handshake_client]:139
tlshd[260035]: Certificate owner unexpected.

Question: is ktls-utils requirement for IP presence in SubjectAltName
now requires both?

Re: ktls-utils: question about certificate verification

[Chuck Lever III]

> On May 31, 2024, at 1:23 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> Hi Chuck,
> 
> I've ran into the following problem while trying to mount on RHEL9.4
> client using xprtsec=tls. After some debugging I have determined that
> the reason mount by DNS name was failing is because gnutls insisted on
> having in SubjectAltName=DNS:foo.bar.com. Having a certificate that
> has a DNS name in the "CN" and then had "SubjectAltName=IP:x.x.x.x"
> was failing. But when I created a certificate with
> "SubjectAltName:IP:x.x.x.x:DNS:x.x.x.x" then I could mount (or just
> having DNS: works too but in that case mounting by IP doesn't work).
> 
> Here's the output from tlshd when it fail (with SubjectAltName "IP")::
> 
> tlshd[260035]: gnutls(3): self-signed cert found: subject
> `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
> Arbor,ST=MI,C=US', issuer
> `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
> Arbor,ST=MI,C=US', serial 0x751ad911565945cce5d29d1c206450538f496b90,
> RSA key 2048 bits, signed using RSA-SHA256, activated `2024-05-31
> 15:07:53 UTC', expires `2024-06-30 15:07:53 UTC',
> pin-sha256="Efzu7ftve1SHxBVAIwf81jwAasQ0M3j5qWbEVuM8X8I="
> tlshd[260035]: gnutls(3): ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:111
> tlshd[260035]: gnutls(3): ASSERT: x509.c[get_alt_name]:2011
> tlshd[260035]: gnutls(3): ASSERT:
> verify-high.c[gnutls_x509_trust_list_verify_crt2]:1615
> tlshd[260035]: gnutls(3): ASSERT: auto-verify.c[auto_verify_cb]:51
> tlshd[260035]: gnutls(3): ASSERT: handshake.c[_gnutls_run_verify_callback]:3018
> tlshd[260035]: gnutls(3): ASSERT:
> handshake-tls13.c[_gnutls13_handshake_client]:139
> tlshd[260035]: Certificate owner unexpected.
> 
> Question: is ktls-utils requirement for IP presence in SubjectAltName
> now requires both?

I'm not sure I understand.

If you want to mount by DNS name, the certificate has to have
a matching DNS name in it.

If you want to mount by IP address, the certificate has to have
a matching IP address in it.

The reason for this is to avoid any potential interaction with
a DNS server which might be compromised.

--
Chuck Lever

Re: ktls-utils: question about certificate verification

[Olga Kornievskaia]

On Fri, May 31, 2024 at 1:27 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>
>
>
> > On May 31, 2024, at 1:23 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > Hi Chuck,
> >
> > I've ran into the following problem while trying to mount on RHEL9.4
> > client using xprtsec=tls. After some debugging I have determined that
> > the reason mount by DNS name was failing is because gnutls insisted on
> > having in SubjectAltName=DNS:foo.bar.com. Having a certificate that
> > has a DNS name in the "CN" and then had "SubjectAltName=IP:x.x.x.x"
> > was failing. But when I created a certificate with
> > "SubjectAltName:IP:x.x.x.x:DNS:x.x.x.x" then I could mount (or just
> > having DNS: works too but in that case mounting by IP doesn't work).
> >
> > Here's the output from tlshd when it fail (with SubjectAltName "IP")::
> >
> > tlshd[260035]: gnutls(3): self-signed cert found: subject
> > `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
> > Arbor,ST=MI,C=US', issuer
> > `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
> > Arbor,ST=MI,C=US', serial 0x751ad911565945cce5d29d1c206450538f496b90,
> > RSA key 2048 bits, signed using RSA-SHA256, activated `2024-05-31
> > 15:07:53 UTC', expires `2024-06-30 15:07:53 UTC',
> > pin-sha256="Efzu7ftve1SHxBVAIwf81jwAasQ0M3j5qWbEVuM8X8I="
> > tlshd[260035]: gnutls(3): ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:111
> > tlshd[260035]: gnutls(3): ASSERT: x509.c[get_alt_name]:2011
> > tlshd[260035]: gnutls(3): ASSERT:
> > verify-high.c[gnutls_x509_trust_list_verify_crt2]:1615
> > tlshd[260035]: gnutls(3): ASSERT: auto-verify.c[auto_verify_cb]:51
> > tlshd[260035]: gnutls(3): ASSERT: handshake.c[_gnutls_run_verify_callback]:3018
> > tlshd[260035]: gnutls(3): ASSERT:
> > handshake-tls13.c[_gnutls13_handshake_client]:139
> > tlshd[260035]: Certificate owner unexpected.
> >
> > Question: is ktls-utils requirement for IP presence in SubjectAltName
> > now requires both?
>
> I'm not sure I understand.
>
> If you want to mount by DNS name, the certificate has to have
> a matching DNS name in it.
>
> If you want to mount by IP address, the certificate has to have
> a matching IP address in it.
>
> The reason for this is to avoid any potential interaction with
> a DNS server which might be compromised.

DNS name is already present in the CN field. Why should it be
duplicated in the SubjectAltName? The point of the extension is to
have "also known by" alternatives. But now the certificate must have
"CN=foo.bar.com, SubjectAltName:IP=,DNS=foo.bar.com". That seems
cucumbersome.

Is this requirement new and done by GnuTLS or is this new by ktls-utils?
.
>
> --
> Chuck Lever
>
>

Re: ktls-utils: question about certificate verification

[Chuck Lever III]

> On May 31, 2024, at 1:40 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> On Fri, May 31, 2024 at 1:27 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>> 
>> 
>> 
>>> On May 31, 2024, at 1:23 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
>>> 
>>> Hi Chuck,
>>> 
>>> I've ran into the following problem while trying to mount on RHEL9.4
>>> client using xprtsec=tls. After some debugging I have determined that
>>> the reason mount by DNS name was failing is because gnutls insisted on
>>> having in SubjectAltName=DNS:foo.bar.com. Having a certificate that
>>> has a DNS name in the "CN" and then had "SubjectAltName=IP:x.x.x.x"
>>> was failing. But when I created a certificate with
>>> "SubjectAltName:IP:x.x.x.x:DNS:x.x.x.x" then I could mount (or just
>>> having DNS: works too but in that case mounting by IP doesn't work).
>>> 
>>> Here's the output from tlshd when it fail (with SubjectAltName "IP")::
>>> 
>>> tlshd[260035]: gnutls(3): self-signed cert found: subject
>>> `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
>>> Arbor,ST=MI,C=US', issuer
>>> `EMAIL=kolga@netapp.com,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
>>> Arbor,ST=MI,C=US', serial 0x751ad911565945cce5d29d1c206450538f496b90,
>>> RSA key 2048 bits, signed using RSA-SHA256, activated `2024-05-31
>>> 15:07:53 UTC', expires `2024-06-30 15:07:53 UTC',
>>> pin-sha256="Efzu7ftve1SHxBVAIwf81jwAasQ0M3j5qWbEVuM8X8I="
>>> tlshd[260035]: gnutls(3): ASSERT: x509_ext.c[gnutls_subject_alt_names_get]:111
>>> tlshd[260035]: gnutls(3): ASSERT: x509.c[get_alt_name]:2011
>>> tlshd[260035]: gnutls(3): ASSERT:
>>> verify-high.c[gnutls_x509_trust_list_verify_crt2]:1615
>>> tlshd[260035]: gnutls(3): ASSERT: auto-verify.c[auto_verify_cb]:51
>>> tlshd[260035]: gnutls(3): ASSERT: handshake.c[_gnutls_run_verify_callback]:3018
>>> tlshd[260035]: gnutls(3): ASSERT:
>>> handshake-tls13.c[_gnutls13_handshake_client]:139
>>> tlshd[260035]: Certificate owner unexpected.
>>> 
>>> Question: is ktls-utils requirement for IP presence in SubjectAltName
>>> now requires both?
>> 
>> I'm not sure I understand.
>> 
>> If you want to mount by DNS name, the certificate has to have
>> a matching DNS name in it.
>> 
>> If you want to mount by IP address, the certificate has to have
>> a matching IP address in it.
>> 
>> The reason for this is to avoid any potential interaction with
>> a DNS server which might be compromised.
> 
> DNS name is already present in the CN field. Why should it be
> duplicated in the SubjectAltName? The point of the extension is to
> have "also known by" alternatives.

RFC 5280 Section 4.2.1.6 describes the SubjectAltName
extension. There appear to be allowable variations where
this field lists alternatives to the CN, or must be
inclusive of all possible alternatives.

I haven't recently refreshed myself on the entire RFC.


> But now the certificate must have
> "CN=foo.bar.com, SubjectAltName:IP=,DNS=foo.bar.com". That seems
> cucumbersome.
> Is this requirement new and done by GnuTLS or is this new by ktls-utils?

Parsing the certificates is done by the library. Have a
look at the source code and docs for GnuTLS to see if
there's a way to tune the behavior.

I'm afraid I'm not that familiar with the use of SAN
information by typical TLS consumers. It's possible that,
because the RFC does not mandate one semantic or the
other, including all alternatives in the SAN field is
simply good practice to ensure interoperation.

In any event, I have scripted the addition of both for
bake-a-thon certificates, so it's not a bother.

--
Chuck Lever