245609 - Mozilla not getting certificate issuer from Authority Information Access CA Issuers

Status: RESOLVED INVALID

(Core Graveyard :: Security: UI, enhancement)

Description

[Cesar Eduardo Barros]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514

When loading the site in Mozilla, it complains that it is signed by an Unknown
authority. This happens because the server returns only its own certificate,
expecting the browser to get the certificate's issuer in the Authority
Information Access CA Issuers field, download it, and use it to validate the chain.

Reproducible: Always
Steps to Reproduce:
1.Open the site
2.Look at the certificate chain
Actual Results:  
Mozilla complains about an unknown issuer, and the chain shows only the server's
certificate.

Expected Results:  
Mozilla should download the URL specified in the Authority Information Access CA
Issuers field of the certificate and use it to check the certificate chain, as
many times as needed. All of them should appear in the certificate chain in the
View Certificate dialog.

Original investigation of the bug and more information at
http://weblogs.asp.net/larryosterman/archive/2004/06/04/148612.aspx

Justification for major severity: IE parity, shows some trusted sites as untrusted.

Comment 1

[Daniel Mota Leite]

tested in mozilla windows and also the certificate check fails

firefox in linux and windows also fail

OS should be set to all, as seens that is a global problem in the mozilla/ssl code

Comment 2

[chris hofmann]

kai, dougt,  any chance at looking at this in the next couple of weeks to make
the firefox release train?

Comment 3

[Doug Turner (:dougt)]

from what I understand and have read, the Authority Information Access isn't
very well specified.  From RFC 2459 ("RFC 2459 - Internet X.509 Public Key
Infrastructure Certificate and CRL Profile"), section 4.2.2.1:

   When id-ad-caIssuers appears as accessInfoType, the accessLocation
   field describes the referenced description server and the access
   protocol to obtain the referenced description.  The accessLocation
   field is defined as a GeneralName, which can take several forms.
   Where the information is available via http, ftp, or ldap,
   accessLocation MUST be a uniformResourceIdentifier.  Where the
   information is available via the directory access protocol (dap),
   accessLocation MUST be a directoryName. When the information is
   available via electronic mail, accessLocation MUST be an rfc822Name.
   The semantics of other name forms of accessLocation (when
   accessMethod is id-ad-caIssuers) are not defined by this
   specification.

To me, the accessLocation could simply be a webpage that describes the
certificate -- a "description server".  

Also, assuming that this RFC is the most current, I think that microsoft might
be breaking the standard.  If a client doesn't honor this "description server"
as a url to an intermediate certificate, a secure connection can not be made --
a fatal and therefore critical error occurs.

According the the first paragraph of the RFC: "This extension may be included in
subject or CA certificates, and it MUST be non-critical".

I would suggest not copying Microsoft until there is clarification.  See
http://www.faqs.org/rfcs/rfc2459.html for the full RFC.

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

Are we getting a patch on this sometime soon? PR is on 8/17. 

Comment 5

[Kai Engert (:KaiE:)]

If I understand correctly, the bug claims that:

- the server sends only its own cert
- when using intermediate certificates, the server cert can be chained to a
certificate trusted by Mozilla.

If my understanding is correct, this issue has been discussed several times in
the past, most prominently with server certificates issued by Verisign.

The common sense in the past was, it's not a client bug, but a server
misconfiguration. The server is expected to include all intermediate
certificates required to chain up to the trusted root.

Verisign tells its client to install the intermediate cert on the server:

====[ Quote from http://www.verisign.com/support/install/apache/v00g.html ]====
Since this is a Global ID, you will need to install a chain certificate
(intermediate certificate) in order for browsers to trust your certificate.
Click below to get this intermediate certificate. 
====[ End of Quote ]====

Also see the Apache FAQ:

====[ Quote from http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html ]====
Question: After I have installed my new Verisign Global ID server certificate,
the browsers complain that they cannot verify the server certificate?

Answer: That is because Verisign uses an intermediate CA certificate between the
root CA certificate (which is installed in the browsers) and the server
certificate (which you installed in the server). You should have received this
additional CA certificate from Verisign. If not, complain to them. Then
configure this certificate with the SSLCertificateChainFile directive in the
server. This makes sure the intermediate CA certificate is send to the browser
and this way fills the gap in the certificate chain.
====[ End of Quote ]====

Because of this, I don't agree we have "major" bug.

I'm resolving this bug as a duplicate to bug 141612.


However, should you suggest to dynamically fetch intermediate certificates from
the web, this would be a new feature, and please file a feature request bug.

The Mozilla feature would probably have to be implemented as an extension to the
NSS crypto library, the library we use for SSL services. This would be further
complicated by the fact that NSS would have to make use of the browser's proxy
settings to access web sites, something it's not doing currently.

*** This bug has been marked as a duplicate of 141612 ***

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

RFC 2246 says:

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

So, for RFC-cxompliant servers, there is no need for clients to fetch any
certs, because the SSL/TLS server suppliees them all (save the root, 
which the client already possesses).

Comment 7

[Cesar Eduardo Barros]

The RFC you quoted is TLS 1.0. SSL 2.0 don't even mention it, and SSL 3.0 is
ambiguous.

Reopening as enhancement as requested, and clearing blocking flags. No need to
file a new bug, since only the severity was wrong.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

http://wp.netscape.com/eng/ssl3/draft302.txt, the SSL 3.0 specification says:

     certificate_list  This is a sequence (chain) of X.509.v3
                       certificates, ordered with the sender's
                       certificate first followed by any certificate
                       authority certificates proceeding sequentially
                       upward.

SSL 2.0 does not allow cert chains, and requires server certs to be
issued by the root CA, which is yet another reason it is obsolete.

For SSL 3.0 and TLS, Any server that does not send its certificate
chain is misconfigured, and not in conformance with the relevant
specification.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 252745 has been marked as a duplicate of this bug. ***

Comment 10

[Ryan Flint [:rflint] (ping via IRC for reviews)]

*** Bug 350480 has been marked as a duplicate of this bug. ***

Comment 11

[ljbmailprotect-mozilla]

I recently received the 'website certified by an unknown authority' error message while browsing:
http://support.microsoft.com/kb/282599

After reading this bug chain apparently all of MS support servers are 'misconfigured'!

There is also very good docuemntation of this issue from the SANS Institute at:
http://isc.sans.org/diary.php?storyid=1230

After reading related Bug 141612 (Versisign's not issuing intermediate certificates) I think someone from Mozilla needs to contact GTE Root CA also to tell them they need to do the same and contact all their server admins.  That way MS would be contacted by GTE and told they need to correct the configuation of certificates on their servers.

Comment 12

[Elan Shudnow]

I don't see how this is a server mis-configuration.  I worked on an Exchange server where we installed the Verisign root certificate as well as the Verisign Intermediate certificate.  The root certificate was installed in the root store and the intermediate certificate was installed in the intermediate store just like the Verisign documentation states.  The mobile devices did not connect properly till it had a copy of the intermediate certificate on it (the mobile device did have the root certificate).  When connecting to OWA via IE, it worked just fine and IE automatically fetched the Intermediate certificate.  Firefox would spit out certificate errors such as the one presented in this bug report. 

Comment 13

[Daniel Mota Leite]

Please check:

http://mv.asterisco.pt/cat.cgi?1000%20Euro%20Firefox%20Bounty

there is a bounty to fix this (and maybe another) bug

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Let me be very clear about this.  With respect to https (SSL/TLS) servers' 
certificates this is NOT A BUG.  RFC 2246 requires SSL/TLS servers to send 
a complete cert chain.  SSL/TLS servers that do not send a complete cert 
chain are not in conformance with RFC 2246.  Nothing in RFC 3280 relieves
an https server of its obligation to send a complete cert chain.  This 
complaint is not an exploitable security flaw, and hence does not qualify 
for a bug bounty.

Comment 15

[Nuno Silva [:njsg]]

I am not an expert in SSL and TLS technologies, so apolozige if I'm understanting it wrongly.

I read the article at <http://blogs.msdn.com/larryosterman/archive/2004/06/04/148612.aspx>

And the conclusions I got after reading the comments here and that article are:
1- The servers must give the complete chain
2- Microsoft wasn't giving the complete chain (now it is, or at least Firefox is able to trust the connection)

In the blog, the only certificate given is:
0 s:/C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority

But now, the given chain is:
(I used the command mentioned in the linked blog)
0 s:/C=US/ST=Washington/L=Redmond/O=WHDC (Old WHQL)/OU=Microsoft/CN=winqual.microsoft.com
  i:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority

1 s:/DC=com/DC=microsoft/DC=corp/DC=redmond/CN=Microsoft Secure Server Authority
  i:/CN=Microsoft Internet Authority

2 s:/CN=Microsoft Internet Authority
  i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root

If I got it correctly, 0 is verified using 1 which is verified using 2, which is verified by a trusted certificate bundled with Firefox.

Then, I checked the problematic portuguese site (<https://private.eu2007.pt/>):
 0 s:/C=PT/ST=Lisboa/L=Lisboa/O=Ministerio dos Negocios Estrangeiros/OU=Missao Presidencia/CN=private.eu2007.pt
   i:/C=PT/O=SCEE/OU=ECEstado/CN=ECCE

 1 s:/C=PT/O=SCEE/OU=ECEstado/CN=ECCE
   i:/C=PT/O=SCEE/CN=ECRaizEstado

 2 s:/C=PT/O=SCEE/CN=ECRaizEstado
   i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root

So Firefox has no reason not to trust this site, right?

IMHO: This is *another* problem and should be reported as a separate bug. I don't know why the (rude) announcement message for the bug bounty mentions this bug. The standard is clear about this (rfc2246), and changing this in Firefox should never be done just "to work like the others".

Comment 16

[Mario Valente]

>I don't know why the (rude) message for the bug bounty 

  I'm the author of the bounty and I dont know what you find rude about
 the message. Except for the word 'stupid'.


>So Firefox has no reason not to trust this site, right?

  Thanks for noting that. 


> IMHO: This is *another* problem 

  I said as much in my post. We think its related to character
 encodings.


> I don't know why the (rude) announcement message for the bug bounty mentions
> this bug

  Because it was the only one related to the type of issue. I never
 said that it was the problem. See above. It was a reference for
 people to read and use as a starting point and try to find out more.


> The standard is clear about this (rfc2246)

  The standard is also clear that using the AIA field MUST
 NOT be critical. So if Firefox chooses not to follow it, then
 it shouldnt come up with a "certificate not trusted" dialog.
  I restate the "rude" part: its stupid.

  Like you said, there's no reason for FF not to trust the site
 and were trying to help Firefox and provide as much information
 about the issue as possible so as to see it solved.

  -- MV

Comment 17

[Mario Valente]

For the record here's aditional information.

It seems that FF is not building the certificate chain adequately,
probably (the only that we are able to see) because of encoding
differences between certificate 0 and 1 above (namely between the issuer
DN in the first one and the subject DN in the second one)

You'll be able to see the (possible) problem using openssl:

            openssl asn1parse -in file_cert.crt -inform DER -text

The ASN structure of the two certificates show some differences.

Is this the problem? Once again, its not happening in IE.
Is this a new bug or one that was reported previously? If it is
a new bug I'm more than glad to file it. I just dont to want to
list an already existent or solved problem.

  -- MV

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

https://private.eu2007.pt/ is only sending out the first two certs in its
chain (the certs identified as 0 and 1 in comment 15).  It's an incomplete
chain.  It does not chain to a trusted root.  The cert identified as cert 2
in comment 15 is missing.  FireFox does not have a cert for that missing CA.
That missing CA is unknown to Firefox.  So Firefox cannot determine that 
the chain comes from any known root CA.  FireFox can only see that the 
final cert in the chain was issued by "CN=ECRaizEstado,O=SCEE,C=PT", which
is an unknown issuer (to FireFox).  

No TLS client is required to understand and process AIA extensions.  
RFC 2246 requires a complete chain precisely to ensure that clients are
NOT required to handle AIAs.  They *may* do so, but are not required to 
do so.  This also follows from the fact that AIA extensions MUST NOT be
critical.  

The implication of AIA extensions not being critical is NOT that a client
must trust an incomplete cert chain, but rather is that a client may 
validate a complete cert chain without having to know anything about AIAs.

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

It appears that my comment 18 was mistaken, and that private.eu2007.pt 
*IS* sending out 3 certs.  One of my tools (created specifically to 
diagnose problems with servers' cert chains) is only displaying the 
first 2 of the 3, and that mislead me.  I'll have to look a little
further into this.  

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

The issuer name in cert "1" is C=PT,O=SCEE,CN=ECRaizEstado where 
PT is encoded as a PrintableString and the other two attributes are 
encoded as UTF8String.

All 3 attributes in the subject name in cert "2" are encoded as 
PrintableString.  

So, NSS does not find the two names to match.  This is permitted by
RFC 3280, which says:

   This specification requires only a subset of the name comparison
   functionality specified in the X.500 series of specifications.
   Conforming implementations are REQUIRED to implement the following
   name comparison rules:

      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

Note that RFC 4630, which udpates RFC 3280, changes the rules regarding
the encoding of DirectoryNames.  Among other things, it says:

      Since name comparison assumes that attribute values encoded in
      different types (e.g., PrintableString and UTF8String) are assumed
      to represent different strings, any name components that appear in
      both the subject field and the issuer field SHOULD use the same
      encoding throughout the certification path.

In other words, the fact these two certs (2 and 3) that attempt to encode
the name with different encodings runs afoul of the RFC recommendations.
Failures for those certs should be anticipated.

This subject really belongs in a different bug, but it would get the same
resolution as this one.

Comment 21

[Marcos Marado]

Nelson,

The RFC says "SHOULD", not "MUST", so, while the cert isn't doing what it "SHOULD" do, the browser has to still to behave as expected when the name compoments use different character encodings.

Anyway, this belongs to another bug report.

Comment 22

[Mario Valente]

  To all who contributed to aditional diagnosis of the
 problem my heartfelt thanks.

  We have now confirmed our initial suspicion (see my
 first post) that the problem was most probably related
 to character encodings and not to some server side
 configuration problems. This has been confirmed thanks
 to Nelson Bolyard:

  https://bugzilla.mozilla.org/show_bug.cgi?id=245609#c20

  Unfortunately although we have the diagnostic, we
 do not have a solution. I mean, sure its relatively easy
 for the state agencies involved to go and reissue the 
 certificates with matching encodings. But I must say that
 it pains me to see the standards (RFC3280 and RFC4630)
 implemented in a reasonable way (comparing strings as
 they should be; keep in mind that both RFCs state MAY
 and SHOULD, there's no MUST) in other browsers and FF
 displaying a wrongful message just because of the lack
 of some string conversion code.

  So, until it is obvious that no solution is
 forthcoming and that we might as well reissue the
 certificates, the bounty still stands for anyone that
 submits the feature/bug/whatever to Bugzilla and comes
 up with the code/patch to back it up. Although if, like
 Nelson says, the bug will get the same resolution as this
 one (RESOLVED INVALID), I dont know if we'll have any luck.

  By now, even a quick look at the code will show that 
 PrintableString was planned to be converted but isnt/wasnt
 and that FF is lacking in relation to other browsers.
 
  http://lxr.mozilla.org/mozilla1.8/source/security/nss/lib/certdb/secname.c#606

  -- MV

Comment 23

[Marcos Marado]

I've opened a bug regarding the encoding issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=386871

Comment 24

[pabstraud]

(In reply to comment #15)

winqual.microsoft.com might give a chain now, however, (1) the validity of the intermediates ended on end of February 2007 (2) the validity of the server certificate started on begin of February 2007 (3) the first intermediate does not match as you can see in the certificate of AIA. The server sends a certificate with serial number 61:04:82:78:00:02:00:00:00:10 instead of the current one with 61:2B:00:A4:00:03:00:00:00:14. Although there is a chain now, the chain is not correct. Download the certificate behind the AIA and install it. The website will load correctly after changing your data and time settings to mid February 2007.

private.eu2007.pt might give a chain, however, the last certificate in the send chain (ECRaizEstado) is serial number 07:27:14:77 instead of 42:EA:5B:0A:51:11:26:7C:D8:27:74:B7:DF:7F:71 which can be obtained at <http://www.ecce.gov.pt/index.php?certificados>. Again, download and install that one manually and you will see the certificate chain validates.

As far as I understand, both examples are examples of very bad configured servers as the chain is not only missing, but a wrong chain is send! Consequently, I recommend to close this bug. Furthermore, I recommend to close all bugs branching from here until someone has a valid example which does not work but sends correct chains.

Send (the correct!) chain of certificates. Consult your server documentation how to do import such intermediates. Contact your issuing authority where to obtain your intermediates.

Comment 25

[pabstraud]

(In reply to comment #24)

I stand corrected as private.eu2007.pt validates in openssl
openssl s_client -connect private.eu2007.pt:443 -showcerts -CAfile GTE.pem
and I have to guess, perhaps they do some intelligent cross certification…sorry.