Bug 1737910

Summary:	Name Constraints validation: CN treated as DNS name even when syntactically invalid as DNS name [rhel-7.9.z]
Product:	Red Hat Enterprise Linux 7	Reporter:	Fraser Tweedale <ftweedal>
Component:	nss	Assignee:	Bob Relyea <rrelyea>
Status:	CLOSED ERRATA	QA Contact:	Alicja Kario <hkario>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	7.7	CC:	asosedki, cheimes, dconsoli, ddas, dueno, ekeck, hkario, jreznik, pkulkarn, rrelyea, szidek, thoger, tscherf
Target Milestone:	rc	Keywords:	Triaged, ZStream
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	nss-3.53.1-3.el7_9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1825270 (view as bug list)		Environment:
Last Closed:	2020-09-29 21:18:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1804262
Bug Blocks:	1825270

Description Fraser Tweedale 2019-08-06 11:31:11 UTC

Description of problem:

Client certificate verification, where client cert has "CN=IPA RA,O=IPA.LOCAL", EKU with id-kp-serverAuth and id-kp-clientAuth, and no SAN. Issuer has DNS Name Constraint permittedSubtree of "ipa.local".


Actual results:

Certificate verification fails due to name constraint violation.


Expected results:

This bug is on similar lines to https://bugzilla.mozilla.org/show_bug.cgi?id=1523484 / https://bugzilla.redhat.com/show_bug.cgi?id=1670239, but a different issue. The CN is syntactically not a valid DNS name. Therefore the "treat CN as a DNS name" heuristic should not apply in this case. Certificate verification should succeed.


Additional info:

Upstream BZ: https://bugzilla.mozilla.org/show_bug.cgi?id=1571677

Comment 2 Alicja Kario 2019-08-06 14:24:51 UTC

Reproducer:
# get a helper library
git clone https://github.com/redhat-qe-security/certgen.git
. certgen/certgen/lib.sh
# generate the certificates
x509KeyGen ca
x509KeyGen server
x509KeyGen client
x509SelfSign --ncExclude '.com' --ncPermit localhost ca

x509CertSign --CA ca server
x509CertSign --CA ca -t webclient \
--extendedKeyUsage serverAuth,clientAuth,emailProtection client
# print the generated certificates
x509DumpCert ca
x509DumpCert server
x509DumpCert client

# set up the NSS databases for client and server
mkdir nssdb-srv
mkdir nssdb-clnt
certutil -N -d nssdb-srv/ --empty-password
certutil -N -d nssdb-clnt --empty-password
certutil -A -n ca -i $(x509Cert ca) -t 'cTC,cTC,' -a -d nssdb-srv
certutil -A -n ca -i $(x509Cert ca) -t 'cTC,cTC,' -a -d nssdb-clnt
pk12util -d nssdb-srv -i $(x509Key --with-cert --pkcs12 server) -W ''
pk12util -d nssdb-clnt -i $(x509Key --with-cert --pkcs12 client) -W ''

# start server that requires client certificates
NSS_ENABLE_PKIX_VERIFY=1 /usr/lib64/nss/unsupported-tools/selfserv -d nssdb-srv -p 4433 -V tls1.2: \
-H 1 -n server -rr -v

#!! run in separate console, same directory
# client that will trust the server cert and has a certificate trusted by 
# server:
SSL_DIR=nssdb-clnt curl https://localhost:4433
# or using tstclnt:
tstclnt -d nssdb-clnt -h localhost -p 4433 -n client <<<"GET / HTTP/1.0

"

Comment 4 Fraser Tweedale 2019-08-07 04:26:00 UTC

I've tested Bob's patch, it works correctly.

Comment 7 Bob Relyea 2019-08-07 20:09:55 UTC

Builds with fix: nss-3.44.0-5.el7
https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=945972

I'm not sure who handles the hotfix portion of this..

bob

Comment 48 errata-xmlrpc 2020-09-29 21:18:42 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: nss and nspr security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:4076