261900 - mozilla.org sites have non-standard/invalid server SSL certificates via https

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations, task)

Description

[Stephen Lee]

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.

Comment 1

[Stephen Lee]

Oops - wrong product  :-[

Comment 2

[Wan-Teh Chang]

Another solution is to get bugzilla.mozilla.org its
own SSL server certificate.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 4

[Scott A. Colcord]

Link this to its predecessor.

Comment 5

[Manfred Schubert]

Safari now shows a warning when opening bugzilla.mozilla.org. Maybe that's because of this problem.

Fix this!

Comment 6

[Henrik Gemal]

Attachment: Screenshot of IE error

Comment 7

[Dave Miller [:justdave]]

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

Comment 8

[Dave Miller [:justdave]]

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.

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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?  

Comment 10

[Dave Miller [:justdave]]

(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)

Comment 11

[Jason Pyeron]

we doit for out servers all the time.

in the openssl conf file:

0.commonname
1.commonname
...

Comment 12

[Jason Pyeron]

Attachment: 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

Comment 13

[Dave Miller [:justdave]]

(In reply to comment #12)
> Created an attachment
> openssl config

Oooh, thanks much! :)

Comment 14

[sfmag]

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.

Comment 15

[Ali Ebrahim]

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.

Comment 16

[Ali Ebrahim]

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.

Comment 17

[Daniel Veditz [:dveditz]]

Is this fixed now with the new XRamp certs? (except for the poor Safari people)

Comment 18

[Jason Pyeron]

IE is happy

Comment 19

[Stephen Lee]

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.

Comment 20

[Anne (:annevk)]

If you not know what fixed it can never be FIXED.

Comment 21

[Stephen Lee]

(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?

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 23

[Dave Miller [:justdave]]

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).

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

Bugzilla's cert expires in less than 2 months.  
It is only valid for 60 days from date of issuance.
Why so short? 

Comment 25

[Dave Miller [:justdave]]

(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.

Comment 26

[Stephen Lee]

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?

Comment 27

[Dave Miller [:justdave]]

(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.