Received-SPF: pass (google.com: domain of linux-nfs+bounces-3514-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CAN-5tyENK71L1C=6NwdB4mkxxf1qYZ2-4e-p8FQM=SmA3tMT_g@mail.gmail.com>
 <6A2D93D5-1603-4CB5-95BB-841163E20295@oracle.com>
In-Reply-To: <6A2D93D5-1603-4CB5-95BB-841163E20295@oracle.com>
From: Olga Kornievskaia <aglo@umich.edu>
Date: Fri, 31 May 2024 13:40:05 -0400
Message-ID: <CAN-5tyFcqZWEb0-LYvucr1nGho6LN6nUNhO1oZHZzZC4G6W2Ag@mail.gmail.com>
Subject: Re: ktls-utils: question about certificate verification
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, May 31, 2024 at 1:27=E2=80=AFPM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
>
>
> > On May 31, 2024, at 1:23=E2=80=AFPM, 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=3Dtls. After some debugging I have determined that
> > the reason mount by DNS name was failing is because gnutls insisted on
> > having in SubjectAltName=3DDNS:foo.bar.com. Having a certificate that
> > has a DNS name in the "CN" and then had "SubjectAltName=3DIP: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=3Dkolga@netapp.com,CN=3Drhel94.nas.lab,OU=3DNFS,O=3DNetapp,L=3DA=
nn
> > Arbor,ST=3DMI,C=3DUS', issuer
> > `EMAIL=3Dkolga@netapp.com,CN=3Drhel94.nas.lab,OU=3DNFS,O=3DNetapp,L=3DA=
nn
> > Arbor,ST=3DMI,C=3DUS', serial 0x751ad911565945cce5d29d1c206450538f496b9=
0,
> > 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=3D"Efzu7ftve1SHxBVAIwf81jwAasQ0M3j5qWbEVuM8X8I=3D"
> > tlshd[260035]: gnutls(3): ASSERT: x509_ext.c[gnutls_subject_alt_names_g=
et]: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_callba=
ck]: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=3Dfoo.bar.com, SubjectAltName:IP=3D,DNS=3Dfoo.bar.com". That seems
cucumbersome.

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