John H.

Here is my analysis of the problem you described in this thread.

You have a "CAC" (a smart card) that contains a cert and private key.
You are attempting to use this cert/key to authenticate yourself
(your browser) to certain remote https web sites, one of which is
a webmail server in the .gov domain, and another is in the .mil domain.
You have success with the .mil domain but the webmail site behaves as
if you have not authenticated to the site.  The success with the .mil
site strongly suggests that your browser is properly configured to
authenticate with your CAC.  The question is why the other site fails.

When an https server asks a browser to authenticate itself with a
certificate, the server sends to the browser a list of names of
certificate issuers (CAs) whose certificates it (the server) is willing
to accept.  The browser looks through its list of "user certificates"
(that is, certificates for which it has the private key, as is the
case on your CAC), looking for certs issued directly or indirectly
by any of the CAs named by the server.

It is likely the case that the two https servers you are using are
sending out different lists of acceptable CA names to your browser.
Your browser is able to determine that the cert in your CAC is
issued by one of the CAs named in the list from the .mil site, but
is not able to determine that your CAC's cert was issued by any of
the CAs named in the .gov site's list.

I can think of at least 3 reasons why that might be.  They include:

1) The .gov site's trusted CA list does not include the name of
any CA that directly or indirectly issued your CAC's cert.

This would indicate that the site's administrators do not want or
do not expect any certs from the CA that issued your cert.
The only solution in this case is to have those site admins change
their list to include a direct or indirect issuer of your cert.

2) The .gov site's trusted CA list names an indirect issuer of your
cert, and your browser does not possess the certs necessary for it
to be able to determine the indirect issuer's relationship to your
card.  The solution to this problem is to download some missing
CA certificates into your browser.  Let me explain this.

Every cert has (at least) two names in it, the issuer's name, and
the "subject" name (e.g. your cert's subject name names you).  The
issuer of your cert also has a certificate that contains the name
of its issuer, and its subject name.  It's subject name is the same
as your cert's issuer name.  Each issuer may have another issuer,
forming a "chain" of issuers (much like a chain of command).
Pictorially this might look like:

     Your cert            direct issuer CA     indirect issuer CA
                          authority 1            authority 2
 --------------------   --------------------   -------------------
                                               issuer: authority 3  ...
                        issuer: authority 2 <- subject: authority 2
 issuer: authority 1 <- subject: authority 1
 subject: you

If the https server names your cert's direct issuer, then your browser
doesn't need any cert other than your cert to see that your cert is
issued by that issuer, because your cert has its direct issuer's name
in it.  But if the https server names (one of) your cert's indirect
issuers then your browser must have the certs for the CAs between your
cert and the named indirect issuer.

Example: Using the cert chain shown above, if the https server says
"give me a cert issued (directly or indirectly) by "authority 2", then
the browser will not determine that your cert was indirectly issued by
authority 2 UNLESS your browser also has the cert for authority 1 in it.
If your browser has the direct issuer cert, then it can find the chain
between your cert and authority 2 and can see that your cert was
indirectly issued by authority 2.  Without the authority 1 cert, it
cannot see that your cert was indirectly issued by authority 1.

Similarly, if the https server asked for a cert issued by authority 3,
your browser would need certs for both authority 1 and authority 2 in
order to be able to see the indirect issuance relationship between your
cert and authority 3.

I suspect that the site that worked for you requested certs issued by
your cert's direct issuer, and the site that did not work requested
certs issued by an indirect issuer.  If that is so, then the solution
is simply for you to download the CA certificates for your direct and
indirect issuers into your browser.

3) There is a third possibility, which is a variant of the second one above.
Perhaps one of your cert's direct or indirect issuers is a "bridge CA".
A bridge CA is a CA that has more than one certificate for itself.
Each certificate for itself has the same subject name as the others, but
each has a different issuer name.  In effect, that CA has multiple issuers.
The chain from your cert upwards forms a "Y".  Here is an illustration
using abbreviated names

                         bridge CA     indirect
                         indirect      issuers
            direct       issuer        I: CA101 ...
            issuer       I: CA100 <--- S: CA100
 Your cert  I: CA2 <-+-- S: CA2
 I: CA1 <-- S: CA1    \                I: CA201 ...
 S: you                \ I: CA200 <--- S: CA200
                         S: CA2

In this illustration, CA2 is a bridge CA and has two certs, each one
naming a different issuer.  The two issuers are CA100 and CA200.
There are 4 CAs in all shown here (with 2 more not shown to the right).

It could be that the two web sites you are using are naming CAs on
different sides of the Y.  Perhaps the .mil site is requesting a cert
issued directly or indirectly by CA101, and the .gov site is requesting
a cert issued directly or indirectly by CA201.  In this case, your
browser would need all the certs shown above to be able to see the
indirect issuance relationships between your cert and those two CAs.
I am not sure that mozilla/FireFox handle this case correctly.

One potential solution to the bridge CA problem is for the https servers
to be configured to name the bridge CA itself among the list of CA names
from which client certs are acceptable.  That solution may or may not be
acceptable to the web site administrators.

Without access to both of the https servers involved, I cannot tell you
which of the above 3 cases is responsible for the behavior you've
experienced.  In any case, your best bet is to ensure that your browser
has all the certificates in the chain (or chains) between your CAC cert
and the "root" CAs (the CAs whose certs are their own issuers, also known
as self-issued certs, or "trust anchors").

--
Nelson B
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to