User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; T312461; Q312461) Build Identifier: The server certificate that is presented by the machine known as bugzilla.mozilla.org when accessing via https says that it is issued to (bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org This is not the same as the name of the site, except by using a non-standard Netscape extension that is not understood by other browsers (including MSIE, the most widely deployed browser in the market). This non-standard certificate causes security warnings when using a standard web browser, which may contribute to an unwanted effect of training users to accept such security warnings as "Normal". Reproducible: Always Steps to Reproduce: 1. Load a web browser that does not support non-standard netscape extensions 2. Navigate to http://bugzilla.mozilla.org Actual Results: I am presented with a security warning dialog stating that "The name on the security certificate is invalid or does not match the name of the site" Expected Results: EITHER: a) I am given the bugzilla index page over http (rather than https) OR b) I am redirected to a https page that does not give a security warning. According to bug 58300 comment #35 From Wan-Teh Chang, there is a standard method to create a certificate for multiple DNS names by using a subjectAltName extension, but according to that comment, it would block out Netscape 4.x and Mozilla earlier than 1.2. Unknown what version of MSIE or other browsers would support this standard method. Most other websites that I have encountered follow the original model of a dedicated IP address for each SSL-enabled DNS name.
Oops - wrong product :-[
Assignee: justdave → myk
Component: bugzilla.org → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: mattyt-bugzilla → justdave
Version: 2.17.6 → other
Another solution is to get bugzilla.mozilla.org its own SSL server certificate.
I wouldn't call Netscape's regular expression syntax a "non-standard extension". Remember that SSL and https were invented at Netscape. That syntax predates the creation of the current standards. It works with X.509 version 1 and version 2 certificates, as well as with the current standard (version 3). Netscape chose to use the "Common Name" attribute in the cert's subjectName field for the server's hostname(s), and defined the regular expression syntax (which includes wildcards) so that one cert could serve multiple hosts. The standards bodies chose to adopt different standards, after Netscape's scheme was in place for some time. The standards (RFC 3280 and its predecessor, RFC 2459, and other related RFCs) do NOT use the SubjectName's CommonName attribute AT ALL, much less with a regular expression syntax. The current standards work only with X.509 v3 certificates, because they require the use of certificate extensions, which did not exist in prior versions. RFC 3280 defines a "subject Alternative Name" extension for certificates. That extension may contain one or more dnsNames and/or IP Addresses. ALL the host names for which a cert is to be used should be specified as dnsNames in that extension. RFC 2818 (which is NOT a standard, but is often treated as one) says If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. One implication of that first paragraph is that, when sujectAltName is used, it must contain ALL the relevant host names, NOT all but one. That is, a proper cert does not list one hostname in the subjectName's CommonName and all the other names as "alt names", but rather, ALL the names are listed in the AltName extension. Putting all-but-one name into the SujectAltName extension is the single most common mistake made when using that extension. RFC 2818 codifies the wildcard syntax that began with Netscape, and allows the use of wildcards in the AltNames, which are not allowed by RFC 3280. Browsers were slow to implement the recognition of host names and IP addresses in SubjectAltNames, after the RFCs emerged that defined them. So, old browsers tend to only recognize the subjectName's CommonName attribute. A cert that strictly follows RFC 3280, listing hostnames (without wildcards) only in the subjectAltName (and not in the subjectName CommonName) will not be recognized by the older browsers. So, my advice is to 1) list all these host names as dnsNames in the subjectAltName extension: bugzilla.mozilla.org bonsai.mozilla.org tinderbox.mozilla.org despot.mozilla.org mecha.mozilla.org, and 2) In the cert's subjectName CommonName attribute, put EITHER a) the existing regular expression: (bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org or b) one of those hostnames, e.g. bugzilla.mozilla.org or c) a wildcard syntax (if you can get a CA to issue that), e.g. *.mozilla.org According to reports I've read, IE supports wildcards but not regular expressions, and treats the subjectName's CommonName as if it was just another one of the SubjectAltName's dnsNames.
Link this to its predecessor.
Depends on: 58300
Safari now shows a warning when opening bugzilla.mozilla.org. Maybe that's because of this problem. Fix this!
*** Bug 273927 has been marked as a duplicate of this bug. ***
No longer blocks: 265357
Summary: bugzilla.mozilla.org has non-standard/invalid server SSL certificate via https → mozilla.org sites have non-standard/invalid server SSL certificate via https
Component: Bugzilla: Other b.m.o Issues → Server Operations
OS: Windows 2000 → All
Hardware: PC → All
Summary: mozilla.org sites have non-standard/invalid server SSL certificate via https → mozilla.org sites have non-standard/invalid server SSL certificates via https
OK, got a couple questions for the luminaries on this bug. :) 1) What browsers are known to support pure wildcard certificates? (such as "*.mozilla.org" for the subject) 2) How does one go about generating a CSR for a certificate that contains the individual subjectAltName entries? All of the configuration stuff I can find for OpenSSL doesn't seem to support it, so I'm assuming there must be extra configuration to add to openssl.cnf to make it support creating one.
Um, given tht mozilla has its own crypto tools that are quite capable of generating a CSR with alt name extensions, why do you want to use the competitor's tools?
(In reply to comment #9) > Um, given tht mozilla has its own crypto tools that are quite capable of > generating a CSR with alt name extensions, why do you want to use the > competitor's tools? Well, first off, I had no clue that Mozilla has such tools, and openssl comes preinstalled on almost every OS these days, so it was at my fingertips. Maybe someone needs to advertise a little better. ;) Where do I find them and how do I use them? (and I'd still like to know how to do it with openssl if someone knows)
we doit for out servers all the time. in the openssl conf file: 0.commonname 1.commonname ...
Created attachment 168971 [details] openssl config install ca cert from http://ca.pdinc.us browse to http://mail.pdinc.us http://mail.pyerotechnics.com ie 6 happy mozilla happy: Mozilla 1.6 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
(In reply to comment #12) > Created an attachment > openssl config Oooh, thanks much! :)
This is also an issue on update-beta.mozilla.org I noticed this because today I got an extension update request from u-b.m.o despite the fact that I've never downloaded anything from there that I'm aware of. This probably is a DNS issue on top of the certificates issue. This happens plainly in FF 1.0, it brings up the certificate name mismatch warning box.
The update-beta issue is a non-issue because it's a beta site, and doesn't need to have a valid SSL cert (though it is secure nonetheless). Furthermore, at this time update and update-beta are running the same code, rendering this point doubly moot.
Having re-read your comment, I'd also add that it's a transitory issue, because it should not be pointing to update-beta. It's a bug in the update code that needs to be fixed. I don't think anything needs to be done here.
Is this fixed now with the new XRamp certs? (except for the poor Safari people)
IE is happy
VRFY comment 18... Are all other browsers happy too? It seems plausible that there may be some browser which does not understand any form of wildcard. Marking FIXED as my observation is that the problem I reported has been fixed, but feel free to reopen if there are compatibility problems with other browsers.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
If you not know what fixed it can never be FIXED.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #20) > If you not know what fixed it can never be FIXED. I do know what fixed it - Per comment 17 and comment 18 and checking the certificate from the icon on the status bar, there is a new SSL cert for *.mozilla.org which works in IE (and probably all browsers). Is there a reason this should not be marked FIXED?
This is the first wildcard cert issued by a real CA that I have ever seen. Congratulations to whoever got it. I'd say this bug is fixed.
The new cert has not yet been deployed to all of our SSL sites, only Bugzilla and Despot have it so far. The rest are due to get it within the next week (there's a hardware move involved as well).
Bugzilla's cert expires in less than 2 months. It is only valid for 60 days from date of issuance. Why so short?
(In reply to comment #24) > Bugzilla's cert expires in less than 2 months. > It is only valid for 60 days from date of issuance. > Why so short? Because there's a whole bunch of people with root access to that box, and we're trying to limit access to the real (3 year) certificate. It'll be hopefully moving to a more secure box by the time that cert expires.
We now appear to have a cert which both IE and Firefox are happy with, and with an expiry time in 2008. This is fixed, isn't it?
(In reply to comment #26) > We now appear to have a cert which both IE and Firefox are happy with, and with > an expiry time in 2008. > > This is fixed, isn't it? Yes.
Status: REOPENED → RESOLVED
Last Resolved: 14 years ago → 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.