Closed Bug 449610 Opened 16 years ago Closed 16 years ago

A certificate used by mozilla.org was issued under two "problematic practices"

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: wtc, Assigned: hecker)

References

(
URL
)

Details

The current certificate for https://bugzilla.mozilla.org/
was issued under two of the problematic practices listed in
http://wiki.mozilla.org/CA:Problematic_Practices

1. It is a wildcard certificate.  The CN in the Subject field is
"*.mozilla.org".

2. It is issued directly from a root CA.

I hope we can resolve this conflict.  Perhaps we should
lead by example and get new certificates for the mozilla.org
servers.  Perhaps the description of these problematic
practices in the wiki page should be balanced with the
benefits of these practices.
Not sure which benefits those practices have for the relying parties. Most of them are due to benefit either the CA or the subscriber.

In addition to your suggestion of getting a new certificate may I suggest that Mozilla should get at least a validated certificate (most likely if the intention is to continue using a wild card cert AND refrain from being one issued by an issuer of the "Problematic Practices").
Assignee: hecker → server-ops
Component: CA Certificates → Server Operations
QA Contact: ca-certificates → mrz
What exactly are you proposing Mozilla do? It doesn't make sense practically or fiscally to buy separate SSL certificates for each subdomain, especially when the number of subdomains is in the hundreds.

Just as a little background, for the last year or so, Mozilla has used GeoTrust as its CA for SSL certificates, which is actually owned by VeriSign but signs its certificates using the Equifax name that it aquired several years ago. Mozilla used to use X-Ramp as its CA, but it was bought out by SecureTrust, which was then bought out by Trustwave, and they apparently stopped answering Mozilla's requests for SSL certificates, so a new provider was found.

http://www.geotrust.com/products/ssl_certificates/wildcards.asp has some information about the two wildcard SSL certificate "products" that GeoTrust offers, and I'm not sure what the difference between the two is.

Also, if Mozilla were to buy new wildcard SSL certificates from a different CA to deal with this "direct from the root" problem, that would basically mean that Mozilla would have to throw away the current wildcard SSL certificates it has that were not cheap to purchase in the first place. That definitely seems impractical.

As a side note, why isn't bug 159483 fixed yet? That bug just makes Mozilla look less secure than IE when it comes to handling wildcard SSL certificates, imho.
OS: Windows XP → All
Hardware: PC → All
So the Problematic Practices thing seems to imply that a wildcard EV cert would be fine (It complains about wildcard DV certs).  Funny thing is, I'm pretty sure the EV spec expressly forbids wildcard certs.  I know, we looked into it about when FF3 came out and people wanted us to be an example case. :)
Reed:

It would be fine to just update the wiki page
http://wiki.mozilla.org/CA:Problematic_Practices
with a more balanced description of wildcard DV
SSL certificates.  (The first paragraph of your
comment 2 explains why wildcard certificates
simplify server administration.)  I just wanted
to point out the contradiction between documentation
and practice.
Looks like MoFo wrote that documentation originally with Nelson working on it, too. I'll leave it up to Hecker/Nelson/other people dealing with SSL policy to update it. Unless there's something Mozilla itself needs to do, this is WONTFIX, as we won't be getting separate SSL certificates for each subdomain we have.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
Reed, this bug was originally filed against CA Certificates, which is the 
right place for bugs about policy and related statements.  It was an 
attempt to show that the current statements seem at odds with common 
practice.  

So, why don't you reopen this bug and move it back to where it was originally filed?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: server-ops → hecker
Status: REOPENED → NEW
Component: Server Operations → CA Certificates
QA Contact: mrz → ca-certificates
(In reply to comment #3)
> So the Problematic Practices thing seems to imply that a wildcard EV cert would
> be fine (It complains about wildcard DV certs).  Funny thing is, I'm pretty
> sure the EV spec expressly forbids wildcard certs.  I know, we looked into it
> about when FF3 came out and people wanted us to be an example case. :)
> 

That's correct. EV forbids wild cards (but not multiple validated domain names in the SAN extension). Due to the added risk for wild card certificates we decided that DV isn't enough for this type of certificates and because of that added it to the "Problematic Practices" after a thorough discussion at dev.tech.crypto. I suggest that MoFo gets a VALIDATED wild card certificate from now on, preferable one that isn't issued directly from the CA root.

(In reply to comment #4)
> Reed:
> 
> It would be fine to just update the wiki page
> http://wiki.mozilla.org/CA:Problematic_Practices
> with a more balanced description of wildcard DV
> SSL certificates.  (The first paragraph of your
> comment 2 explains why wildcard certificates
> simplify server administration.)  I just wanted
> to point out the contradiction between documentation
> and practice.
> 

WT, the problematic practices concerning wild cards is not because they are wild card certificates, but because they are only domain validated. Nobody is against wild cards - they are widely used and valuable, it's the validation which is the problem here. I'm more than glad to comment with more details at dev.tech.crypto if you want.

(In reply to comment #7)
> I suggest that MoFo gets a VALIDATED wild card certificate
> from now on, preferable one that isn't issued directly from the CA root.

Could you please explain what you mean by "a validated wild card certificate"? You mention certificates that aren't directly issued from the root, but what else besides that?

Sure! The identity of the subscriber SHOULD be validated for wild card certificates, in this case the organization called "Mozilla Foundation". Wild card certificates SHOULD NOT be domain validated only.
(In reply to comment #10)
> Sure! The identity of the subscriber SHOULD be validated for wild card
> certificates, in this case the organization called "Mozilla Foundation". Wild
> card certificates SHOULD NOT be domain validated only.

But if EV wildcard SSL certificates are not permitted per the EV spec (from what I understand), what other type of SSL certificate is there that would allow us to have a wildcard SSL certificate that meets your requirements? I see there's something called OV SSL certificates (mentioned on http://www.networksolutions.com/SSL-certificates/guide/SSL-Security.jsp), but I've never heard of OV before reading that page. There doesn't seem to be very much documentation in general about the finite differences between OV/DV/EV SSL certificates from what I've seen.
Yes, there are at many CAs with clearly defined different types of certificates. They might be:

1.) Domain validated only (DV)
2.) Identity and/or organization validated (IV/OV)
3.) Extended Validated (EV)

EV doesn't allow wild cards in order to have absolute control over the issued domain names, including their sub domains. This is the extreme in that respect (also requires to buy more certificates by the subscriber ;-) )

Our point at dev.tech.crypto is, that the CA should have some control over the issued (sub)domain (some CAs in fact do have software checking for certain patterns) and in case is doesn't (as with a wild card), the subscriber should be validated. This follows the same principals as with code signing certificates. For example the Mozilla CA policy REQUIRES code signing certificates to be issued only to validated identities (See http://www.mozilla.org/projects/security/certs/policy/ and also http://www.mozilla.org/projects/security/certs/pending/ which shows the various validations a CA performs). 

Apparently the certificate which was issued to *.mozilla.org was domain validated only. This can be easily corrected with a certificate from a different provider.
Eddy,

Your comment 12 should be added to the Problematic Practices
wiki page.  Like Reed, I thought that DV and EV are the only
kinds of certificates, and since EV disallows wildcard certificates,
I mistakenly concluded that the Problematic Practices wiki page
is against all wildcard certificates.
I understand. But doesn't the wiki page already say that: 

"Concerns have been expressed that wildcard SSL certificates should not be issued except to subscribers whose actual identity has been validated."?

My intention is to promote the code siging requirement (e.g. validated identity) also for wild card server certificates as part of the Mozilla CA Policy.
(In reply to comment #12)
> Apparently the certificate which was issued to *.mozilla.org was domain
> validated only. This can be easily corrected with a certificate from a
> different provider.

What other provider(s) would you recommend to Mozilla that would be able to provide such a certificate?

I suggest that Frank Hecker makes the recommendations, because I must disqualify myself from doing that...
(In reply to comment #15)
> (In reply to comment #12)
> > Apparently the certificate which was issued to *.mozilla.org was domain
> > validated only. This can be easily corrected with a certificate from a
> > different provider.
> 
> What other provider(s) would you recommend to Mozilla that would be able to
> provide such a certificate?

I'm a little confused here. If you got a so-called TrueBusinessID Wildcard SSL cert from GeoTrust, then GeoTrust should have validated the organizational identity of the Mozilla Foundation or Corporation as part of the application process; at least that's what is implied by

http://www.geotrust.com/buy/certificate_compare.asp

Am I missing something?

As for other providers, based on cursory inspection I think the following CA/product combinations would fulfill the criteria to have wildcard capabilities combined with validation of Mozilla's organizational identity (these are in no particular order):

Go Daddy Deluxe SSL with unlimited subdomains:
https://www.godaddy.com/gdshop/ssl/ssl.asp?ci=9173

Comodo PlatinumSSL Wildcard:
http://www.enterprisessl.com/ssl-certificate-products/addsupport/wildcard-ssl-platinumssl_wildcard.html

Thawte Wildcard Certificates:
https://www.thawte.com/ssl-digital-certificates/wildcardssl/index.html

GlobalSign OrganizationalSSL certificate with Wildcard Option:
http://www.globalsign.com/ssl/ssl-certificates/organization-ssl/index.htm
http://www.globalsign.com/ssl/ssl-certificates/ssl-options/wildcard-ssl.htm

The above are among the top CAs by market share; of the other CAs with leading market share, I can't tell if VeriSign offers wildcard certs or not (note that GeoTrust and Thawte are also owned by VeriSign) and I can't tell if Network Solutions offers a wildcard cert for which organizational identity is validated.

I should also mention (because Eddy's not going to, due to the inherent conflict of interest) that StartCom also offers wildcard SSL certs with validation of organizational identity. If/when the StartCom root ever gets included in Windows/IE that might be a possible option as well.

Finally, I think it might make sense for us to consider EV certs for selected SSL-enabled public Mozilla sites that are primarily used by end users (as opposed to developers), though I don't have any firm recommendations for this right now. However I will note that for any of these that are mozilla.org sites (as opposed to mozilla.com or mozillamessaging.com) then I think it would appropriate for the Mozilla Foundation to pay any extra fees required for EV certs.




It's a pity that no further details are included in the certificate issued by GeoTrust, but if it's what you say it is, it appears to be a validated certificate. I suspect that since WT misunderstood parts of the "Problematic Practices" he thought that the certificate in question isn't OV validated. That leaves the "root issuing" as the only conflict for now.
(In reply to comment #17)
> I'm a little confused here. If you got a so-called TrueBusinessID Wildcard SSL
> cert from GeoTrust, then GeoTrust should have validated the organizational
> identity of the Mozilla Foundation or Corporation as part of the application
> process; at least that's what is implied by
> 
> http://www.geotrust.com/buy/certificate_compare.asp
> 
> Am I missing something?

Not sure. We definitely use GeoTrust's "True BusinessID® Wildcard" product for the *.mozilla.org and *.mozilla.com SSL certificates, and the certificates you see used for www.mozilla.org and www.mozilla.com are what we were given.
Eddy, Frank,

How about if we change "Wildcard DV SSL certificates"
to "Wildcard non-OV SSL certificates"?

Alternatively, we can change the last sentence of that
section to:

  Concerns have been expressed that wildcard
  SSL certificates should not be issued except
  to subscribers whose actual identity has been
  validated with organizational validation (OV).
  (There are no EV wildcard certificates.)

I have a dissenting opinion about whether Wildcard certs are any less 
problematic for OV than for DV.  

This bug provides lots of evidence that proves my main point: it is not 
possible to tell DV certs and OV certs apart.  Even the participants in 
this bug could not tell, by direct inspection, that Mozilla's wildcard 
cert was OV and not DV.  Mozilla's operations staff (who are the 
subscribers) knew that it was OV because of their memories of the process 
they followed to get it, but the cert itself bears no evidence of same. 

I can and will (and have) written a lot more about this subject that I 
will put into the newsgroup, rather than this bug, because I think the 
discussion belongs in the newsgroup.  Here I will just summarize:

I think it is pointless to try to declare that DV certs are more 
"problematic" than OV certs as long as our browsers and our experts 
cannot tell them apart.  
(In reply to comment #21)
> I have a dissenting opinion about whether Wildcard certs are any less 
> problematic for OV than for DV.  
> 

Pardon me? https://paypal.domain.com/ is problematic if the identity is unknown. It's not an issue (and even legitimate as we've discussed it previously) if the identity of the subscriber is known.


> This bug provides lots of evidence that proves my main point: it is not 
> possible to tell DV certs and OV certs apart.  Even the participants in 
> this bug could not tell, by direct inspection, that Mozilla's wildcard 
> cert was OV and not DV.

It's not an RP issue but a policy issue!!! The same way the Mozilla CA Policy requires validations for code signing certificates, the same way wild cards should be treated policy-wise!

> I think it is pointless to try to declare that DV certs are more 
> "problematic" than OV certs as long as our browsers and our experts 
> cannot tell them apart.  

Than please adjust the requirements for code signing certificates because you can't tell them apart either (as an RP).

Feel free to start a new thread at m.d.t.c.

(In reply to comment #20)
>   Concerns have been expressed that wildcard
>   SSL certificates should not be issued except
>   to subscribers whose actual identity has been
>   validated with organizational validation (OV).
>   (There are no EV wildcard certificates.)
> 

Sounds good to me...

(In reply to comment #21)
> This bug provides lots of evidence that proves my main point: it is not 
> possible to tell DV certs and OV certs apart.  Even the participants in 
> this bug could not tell, by direct inspection, that Mozilla's wildcard 
> cert was OV and not DV.

I'm sympathetic to your position (I've argued in the past that the CA market should logically split into DV and EV offerings, with nothing in between), but I should note that looking into the actual cert for, e.g., https://bugzilla.mozilla.org/ reveals an O=Mozilla Corporation that presumably wouldn't be there if this were a true DV cert.

Part of the confusion is that the Firefox UI treats it like a DV cert, unless you actually look at the cert contents. In particular, the "Larry" popup says "You are connected to mozilla.org, which is run by (unknown)", and going to the "More information..." dialog says for "owner" that "This web site does not supply identity information".

(In reply to comment #20)
> Alternatively, we can change the last sentence of that
> section to:
> 
>   Concerns have been expressed that wildcard
>   SSL certificates should not be issued except
>   to subscribers whose actual identity has been
>   validated with organizational validation (OV).
>   (There are no EV wildcard certificates.)

Done.


Frank, 

I can show you DV certs (and email certs) that have O= in them.
And you may recall that the CABForum members reported that the O= field 
contents are NOT vetted.  So, IMO, the O= field cannot be used as a 
reliable indication of OV (sadly).

FF doesn't visually distinguish OV certs from DV because there is no 
reliable indicator of OV.  IMO, it is right of FF3 to continue to not 
give prominence to O= information while it remains unknown whether that 
information was vetted.
OK, since this bug is assigned to me, I'm going to state my opinions on what
(if anything) we should do about it.

At least the following issues have been raised in this bug, with my take on each one:

1. The wildcard certs for Mozilla sites are wildcard DV certs, a practice viewed as problematic, and we should consider getting new certs. As noted above (e.g., in comment #19), the GeoTrust-issued wildcard certs for Mozilla sites are in fact not DV certs. I therefore consider this issue closed.

2. The wildcard certs for Mozilla sites are issued directly from the root, a practice viewed as problematic, and we should consider getting new certs. This is still the case, however IMO I don't see this issue as warranting an immediate replacement of the certs.

The *.mozilla.org cert doesn't expire until December 2009. I would prefer to revisit the cert question sometime nearer that time, and look at some alternative providers as noted in my comment #17, as well as at the possibility of getting EV certs for selected mozilla.org sites. Since we do have a CA policy, and our use of a particular CA for our own sites can be viewed as a sort of endorsement of that CA, it would be good to select a CA that not only offers good value to us but also operates in a manner fully in the spirit of our policy.

3. The text on the "potentially problematic practices" page should be changed to clarify its meaning. I've just done that.

4. There's no real distinction between DV and OV certs. I'm sympathetic to that argument, but that's a discussion for m.d.t.crypto IMO.

Given the above, I'm minded to resolve this bug as WONTFIX; we can open a new bug later for doing a general cert refresh for mozilla.org sites.
Status: NEW → ASSIGNED
(In reply to comment #26)
> I can show you DV certs (and email certs) that have O= in them.

Point taken.

> And you may recall that the CABForum members reported that the O= field 
> contents are NOT vetted.

Are you talking about the EV case? IIRC it was OU information that is not normally vetted by CAs, even when subscriber identity is otherwise verified.
(In reply to comment #27)
> The *.mozilla.org cert doesn't expire until December 2009. I would prefer to
> revisit the cert question sometime nearer that time, and look at some
> alternative providers as noted in my comment #17, as well as at the possibility
> of getting EV certs for selected mozilla.org sites.

As a side note, we're currently pursuing moving www.mozilla.org/mozilla.org to a CDN, in which case, we'll be buying a separate SSL certificate so as not having to share the wildcard SSL certificate with an outside party. If you think www.mozilla.org/mozilla.org should have an EV SSL certificate, this might be a good time to talk about that. However, please read the discussion in bug 418038, as that request has already been proposed and successively WONTFIX'd.
(In reply to comment #26)
> I can show you DV certs (and email certs) that have O= in them.

I'd like to see them, actually. Does the CP/CPS under which they have been issued really state that the organizationName RDN is not vetted?

> And you may recall that the CABForum members reported that the O= field 
> contents are NOT vetted.

Were they talking of organizationName (O, 2.5.4.10) or organizationalUnitName (OU, 2.5.4.11)?
(In reply to comment #28)

> > And you may recall that the CABForum members reported that the O= field 
> > contents are NOT vetted.
> 
> Are you talking about the EV case? IIRC it was OU information that is not
> normally vetted by CAs, even when subscriber identity is otherwise verified.

You recall correctly - O fields are absolutely, and rigorously, verified in EV.  OU fields have some "best efforts" language around them, but unlike organization name, for which there are corporate registries, government records, etc., this is a mostly internal identifier (e.g. department name).

(In reply to comment #29)
> As a side note, we're currently pursuing moving www.mozilla.org/mozilla.org to
> a CDN, in which case, we'll be buying a separate SSL certificate so as not
> having to share the wildcard SSL certificate with an outside party. If you
> think www.mozilla.org/mozilla.org should have an EV SSL certificate, this might
> be a good time to talk about that. However, please read the discussion in bug
> 418038, as that request has already been proposed and successively WONTFIX'd.

I was a part of that WONTFIX'ng, because that bug was making the argument that this was a good thing to have basically as a technology demo - a "would be nice".  That's a different conversation from, say, "AMO should have an EV certificate, and here's why" which I think is more to Frank's point.


(In reply to comment #31)
> I was a part of that WONTFIX'ng, because that bug was making the argument that
> this was a good thing to have basically as a technology demo - a "would be
> nice".  That's a different conversation from, say, "AMO should have an EV
> certificate, and here's why" which I think is more to Frank's point.

Correct. For example, with AMO the majority of users are typical end users, and because of the nature of the site they have a strong interest in knowing that it's indeed an official Mozilla site. Thus I think an EV cert makes sense for AMO. However with bugzilla.m.o the user population is more technically savvy and I don't think needs as much the extra assurance EV provides. But in any case I agree that a) this is a separate discussion/bug, and b) we should treat each site on a case-by-case basis as to whether it needs EV or not (hence this would really be multiple bugs IMO).


OK, as I mentioned above I'm going to WONTFIX this. There are no issues outstanding that can't be better dealt with in other bugs or in m.d.t.crypto.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
In answer to questions in above comments:
- I had misremembered what the CABForum members had said they were not 
  always vetting.  It was OU, not O.

- I know that I've seen DV certs with Organization fields, but at the 
moment, I don't recall where.  When I see them again, I'll try to remember
to make a note here.
(In reply to comment #34)
> - I know that I've seen DV certs with Organization fields, but at the 
> moment, I don't recall where.  When I see them again, I'll try to remember
> to make a note here.

In the meantime, I found two CAs which populate the organizationName even for DV certs:

a) Starfield Technologies (aka Go Daddy) - cf.
https://certs.godaddy.com/repository/StarfieldCP-CPS.pdf, p.41: for "Medium Assurance Certificates", it uses the following attributes:

> CN = domain name of Subscriber’s web site (may be fully qualified or wildcard)
> OU = “Domain Control Verified” or similar text indicating the assurance level
> of the certificate.
> O = domain name of Subscriber’s web site (may be fully qualified or wildcard)

Example URL: https://secure.dshield.org/trendgraph.png


b) RapidSSL (aka Geotrust/Verisign) - cf. http://www.rapidssl.com/resources/pdfs/RapidSSL_CPS_v1.0_6-27-05_FINAL.pdf, p. 10:

> 1. Organizational Name
> GeoTrust will insert the domain name in the Organization field for all
> RapidSSL Certificates.
> 2. Organizational Unit Name
> GeoTrust will insert "Domain Control Validated" or similar language into one
> of the Organizational Unit name fields in all Certificates. If available,
> GeoTrust will insert a Business Registration Number in one of the
> Organizational Unit name fields of the Certificate.

Example URL: https://www.mcad.edu/skins/default/images-template/main-title.gif


Bottom line: while it's true that the presence/absence of an O attribute by itself can't be used to tell DV and OV certs apart, there's still a mechanism to determine if a particular cert is OV: if it includes an O attribute *and* that O attribute differs from the CN attribute, then it's OV.
That's a heuristic that works for two DV CAs out of hundreds(?).
Also StartCom adds the base domain name to the organization fields, e.g. the value that was validated. The OU field states "StartCom Free Certificate Member", indicating the internal status of Class 1 (which is DV).
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.