On Fri, May 31, 2024 at 1:27 PM Chuck Lever III <[email protected]> wrote:
>
>
>
> > On May 31, 2024, at 1:23 PM, Olga Kornievskaia <[email protected]> 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 protected],CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
> > Arbor,ST=MI,C=US', issuer
> > `[email protected],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
>
>
> On May 31, 2024, at 1:40 PM, Olga Kornievskaia <[email protected]> wrote:
>
> On Fri, May 31, 2024 at 1:27 PM Chuck Lever III <[email protected]> wrote:
>>
>>
>>
>>> On May 31, 2024, at 1:23 PM, Olga Kornievskaia <[email protected]> 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 protected],CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann
>>> Arbor,ST=MI,C=US', issuer
>>> `[email protected],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