On 03/03/2017 09:42 AM, Paul Wouters wrote:
On Fri, 3 Mar 2017, Robert Relyea wrote:
[offlist]
redirected back to the list, since the item I was concerned about is not
a concern.
Thanks for the info. I looked at it and have two questions and one
concern (which is why this is offlist)
I'm not sure what list this was from. I don't remember seeing the
thread.
dev-tech-crypto@lists.mozilla.org
- Why not export this NSS function for everyone?
Which function?
Sorry, I was referring to:
cert_VerifySubjectAltName(const CERTCertificate *cert, const char
*name);
Certainly as named, we would export it, but we could wrap the function
as CERT_VerifySubjectAltName()
and export that function.
Basically in IKE you can set an ID different from a DN. So if someone
sets ID_FQDN (eg vpn.example.com) then we want to lookup and ensure that
the certificate is really matching that ID. IKE also allows specifying
email addresses and IP's. So we need to look for:
- email= in the DN
- subjectAltName of type DNSname
- subjectAltName of type IP
- subjectAltName of type email address.
It looks that CERT_GetFirstEmailAddress() and CERT_GetNextEmailAddress()
gets me the email= from the DN and all email address in the first
subjectAltName section, but not in subsequent subjectAltName sections.
Yes, NSS only looks at the first subjectAltName section. That section
can and should hold all the alt names (That's certainly the case with
SSL certificates).
I think you may be confused with the openSSL API. When openSSL says:
Please make sure the following details are correct before proceeding any
further.
CommonName: server1.example.com
subjectAltName: DNS:server1.example.com
subjectAltName: DNS:mail.example.com
subjectAltName: DNS:www.example.com
subjectAltName: DNS:www.sub.example.com
subjectAltName: DNS:mx.example.com
subjectAltName: DNS:support.example.com
No additional information will be included on certificates because it can not
be automatically checked by the system.
It will create a single subjectAltName with all those names in it:
X509v3 Subject Alternative Name:
DNS:server1.example.com, othername:<unsupported>, DNS:mail.example.com,
othername:<unsupported>, DNS:www.example.com, othername:<unsupported>, DNS
:www.sub.example.com, othername:<unsupported>, DNS:mx.example.com, othername:<un
supported>, DNS:support.example.com, othername:<unsupported>
Are you sure the certificate you have actually has multiple
subjectAltName sections?
The same is true for cert_VerifySubjectAltName() which seems to only
look at the first subjectAltName section as well.
The certificates I use for testing use this openssl/python code:
- add_ext(cert, 'subjectAltName', False, dnsname)
+ if cnstr == "east.testing.libreswan.org":
+ dnsname = "%s,%s"%(dnsname , "DNS:east.alias")
+ add_ext(cert, 'subjectAltName', False, "IP:
192.1.2.23")
+ add_ext(cert, 'subjectAltName', False, dnsname)
+ add_ext(cert, 'subjectAltName', False, "email:
user1@%s"%cnstr)
So there are 3 subjectAltName sections.
Hmm Are you sure these aren't being colapsed into a single
subjectAltName section with multiple subjectAltNames in it?
In general NSS tends to be stingy by default on the functions it
exports,
I completely understand that :)
I believe Kai has already exported several functions upstream for you
that will go into RHEL 7.
Yes, and we've already updated libreswan to make use of this in upstream
and fedora rawhide! Thanks!
The code I see in NSS seems to assume there is only one SAN section? I
checked and it does not create one big list of all the SAN extensions,
because I don't see my IP address SAN in the above example.
It doesn't. For most of NSS we usually are looking for a specific SAN
(like a particular DNS name, or an email address.), so it loops
through them all.
I'm surprised the SAN processing isn't exported since applications
that override the SSL name check would need it.
You do export CERT_VerifyCertName() which uses this function. So maybe I
was trying to use the wrong function. But it seems this function also
does not process multiple subjectAltName sections.
CERT_VerifyCertName() verifies against either the SAN or the CN (SSL
processing). it supports multiple subjectAltNames, but they all are
expected to be in the same section.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
