There have been various posts regarding Tomcat's inability to successfully
complete client authentication, particularly with Microsoft's IE. We've
discovered the answer to Tomcat's problem. It turns out that as part of the
client-cert request in the standard SSL protocol, the server side sends a
_stringified_ version of each trusted certificate. The string version is a
standard representation of the distinguished name of the signer of a trusted
certificate, such as <CN=Templar Corporation, OU=Software Development> and
so on.
Now, it appears that IE does a simple string comparison of its trusted certs
against this list to figure out what certificates are trusted. IE doesn't
look at the certificates themselves (which are also included in the SSL
handshake) during this initial screen - it looks simply at the stringified
version of the signer. This means that if there's any difference between the
way that the server stringifies the signer and the way IE stringifies the
signer, IE's match fails, and IE will never recognize the trusted
certificate.
With this background, the problem turns out to be the following:
(1) The Microsoft certificate authority allows an email address in the root
certificate's distinguished name. This isn't exactly standard (my reading of
the DN standard is that only an X501 item can appear in the DN and there
isn't a clear item for email address) but it is very common.
(2) When Microsoft stringifies a certificate's signer, it uses "E=" as the
marker for the email address.
(3) When Tomcat stringifies a certificate's signer, it uses "EmailAddress="
as the marker for the email address.
(4) Since IE and Tomcat don't agree on the stringified version of the email
address, IE's string match fails to recognize a root certificate that
includes an email address.
The fix: we re-installed the Microsoft cert authority and specified a
distinguished name for the authority that did not include an email address.
After re-installing the certs in both Tomcat and IE, the two were able to
exchange a client cert without a problem.
I speculate that Netscape looks for trusted roots in the SSL handshake
differently, which is why we were able to get client authentication working
with Netscape, even with the email address in the root.
