Melelina wrote: > The cert is issued to www.microsoft.ipsos.com by Verisign.
Or it appears to be. > I want to use Fx at Microsoft sites and I am very tired of Fx problems with > Microsoft certs But you haven't yet shown any evidence of FF having a problem with a Microsoft site. The site you cited is NOT a Microsoft site. The cert for that server claims to have been issued to: O = IPSOS-REID Corporation L = Winnipeg ST = Manitoba C = US (Heh, I guess the US must have annexed Manitoba when I wasn't looking. :) If you DO have troubles with real Microsoft web sites, you can let me know. I have contacts among Microsoft web site admins, and when I report a problem with their servers, they often (not always) get fixed. They always reply, somewhat red faced, that they only tested with IE. I have no contacts in Manitoba. > and now there is the problem of Fx not having the new > Verisign intermediate cert Verisign's class 3 intermediate CA cert is not new. It was issued on April 16, 1997, 10 years ago (next month). It has been continuously in use by thousands of web sites all that time, with NO difficulty by mozilla browsers. Recently, Verisign discontinued issuing certs from their older "RSA security" root. Their customers (web site administrators) had been using server certs issued from the old RSA Security root for years, and had never in their lives ever installed an intermediate CA cert into their servers. Then, when they applied for renewed certs, they got certs issued by Verisign's class 3 intermediate CA. Verisign's web site explained to its subscribers the need to install the Intermediate CA cert into their servers. <http://www.verisign.com/support/advisories/page_029264.html> <http://www.verisign.com/support/advisories/page_040601.html> <http://www.verisign.com/support/advisories/page_040611.html> even in other languages (such as Japanese, here translated into English): <http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=ja_en&url=http%3A%2F%2Fwww.verisign.co.jp%2Fserver%2Fabout%2F2006rollover%2Fssid%2Findex.html> But many Verisign customers took no notice of those instructions. So, those web sites, operated by people who didn't read the notices, now have problems. The fault isn't FireFox's, nor Verisign's. > and it wanting to rely on root certs that are no longer used by Verisign. Wrong, on several counts. 1. Verisign's old RSA Security Secure Server authority cert doesn't expire until 2010. Until then, server certs issued by that CA will continue to validate against that root CA cert. 2. ALL certs are verified by following a "chain" (or "path") of CA certs, beginning with the issuer of the server cert, then the issuer of that cert, and so on, until we come to a root CA cert (which is its own issuer). If the chain is incomplete, so that we cannot follow it all the way to the root, then the server cert cannot be verified. Servers that send out incomplete cert chains are violating the standards for SSL 3.0 and/or TLS (SSL 3.1), which require servers to send out their entire cert chains, up to (but not including) the root CA. An SSL server that doesn't send its intermediate CA certs is simply non-conformant and mis-configured. RFC 2246, the standard definition of TLS (SSL 3.1) 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. Yes, there is a standard for certs that allows (but does not require) "relying parties" to go search on the internet for missing intermediate CA certs. But that standard does NOT relieve SSL servers of the obligation to send their entire server cert chains (minus the root CA cert, which is optional). > At least this is what I understand the situation to be from threads at > Mozillazine and dslreports security forum, etc. If this is not the case > please enlighten me. Ah yes, those fonts of indisputable truth. :) The problems need to be fixed where they exist, in the misconfigured servers. Of course, it's easier to complain to mozilla, where in many cases you're more likely to get a reply, but the problem will be fixed when a sysadmin in Winnipeg fixes his server configuration. Maybe you can help him/her hasten that day. /Nelson B (mozilla SSL developer, IETF TLS member, co-author RFC 4492) _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
