Closed Bug 245609 Opened 21 years ago Closed 20 years ago

Mozilla not getting certificate issuer from Authority Information Access CA Issuers

Categories

(Core Graveyard :: Security: UI, enhancement)

Product:
Core Graveyard
Component:
Security: UI
Version:
Other Branch
Platform:
x86
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: cesarb, Assigned: KaiE)

References

(
URL
)

Details

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.
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
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
kai, dougt, any chance at looking at this in the next couple of weeks to make the firefox release train?
Flags: blocking-aviary1.0RC1?
Flags: blocking-aviary1.0RC1-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
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.
Are we getting a patch on this sometime soon? PR is on 8/17.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
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 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
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).
Flags: blocking-aviary1.0PR?
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.
Severity: major → enhancement
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Flags: blocking-aviary1.0+
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.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → INVALID
*** Bug 252745 has been marked as a duplicate of this bug. ***
Product: PSM → Core
*** Bug 350480 has been marked as a duplicate of this bug. ***
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.
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.
Please check: http://mv.asterisco.pt/cat.cgi?1000%20Euro%20Firefox%20Bounty there is a bounty to fix this (and maybe another) bug
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.
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".
>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
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
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.
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.
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.
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.
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
I've opened a bug regarding the encoding issue: https://bugzilla.mozilla.org/show_bug.cgi?id=386871
(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.
(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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.