> On May 31, 2024, at 1:40 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Fri, May 31, 2024 at 1:27 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> >> >>> On May 31, 2024, at 1:23 PM, Olga Kornievskaia <aglo@xxxxxxxxx> 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@xxxxxxxxxx,CN=rhel94.nas.lab,OU=NFS,O=Netapp,L=Ann >>> Arbor,ST=MI,C=US', issuer >>> `EMAIL=kolga@xxxxxxxxxx,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
