Closed Bug 556468 Opened 14 years ago Closed 13 years ago

Investigate incident with RapidSSL that issued SSL certificate for portugalmail.pt

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: reed, Assigned: kathleen.a.wilson)

References

(
URL
)

Details

[Filed as a result of thread started by Kurt Seifried on mozilla.dev.tech.crypto]

--------------------------------------------------------------------------------

Kurt Seifried here:

So I picked a webmail provider at random (sorry portugalmail.pt!) and  
filled in the account form, taking ssladministrator as the email name.  
Using this I was then able to buy a secure web certificate for  
portugalmail.pt since the verification process is so weak. Here are  
the five emails I received from RapidSSL, the only things I have  
removed is my phone number and the last four digits of the credit  
card, as you can see the process isn't that hard.

With respect to Firefox: what does it take, evidence wise to prove a  
CA is doing a bad job? Is this enough or do you need more (like does  
this have to happen 10 times or more?)?

--------------------------------------------------------------------------------

Entire thread can be read at http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/ab1c21635e07d818.
For the record there isn't much of anything to investigate. RapidSSL will verify domain ownership through a list of addresses that most people aren't aware of so if you can read email (by creating account, sniffing, etc.) you can trivially buy a certificate. All the details are available in the article: http://www.linux-magazine.com/Issues/2010/114/BREACH-OF-TRUST
Blocks: 477783
Also see bug 477783.
Is this another 1st of April joke?

It must be noted that I've warned and requested to limit the acceptable email addresses during the inclusion request of GeoTrust SHA256 root in bug 409236. Verisign committed to remove some of the email address during the discussion and Kathleen confirmed this action item in comment 16 of bug 409236. Verisign requested an extension to this change which had to be performed within the February/March 2010 timeframe.
No, this is not a joke.
It is about how we all need to be
> a little more informed about how the CA business works technically before commenting on it.
> -- Gervase Markham [:gerv] 2009-02-11 06:38:03 PST
Yes, this sort of thing (not commenting on the specific incident) is definitely a significant issue. We don't think it's a joke. 

I've been pushing in CABForum to get a standardized (and small) list of email addresses agreed as best practice for this purpose. I can't offhand remember what stage that proposal has reached, but I will look into it and get back to you.

Gerv
Exactly the section dealing with this issue was removed from the proposed draft. At this stage the proposed guidelines are stuck to all of my knowledge.
Kathleen - can we get our GeoTrust contacts to comment here and explain the issue? It's April - the shortened list Verisign agreed to should be in place now.
I want to confirm we did remove the ssladministrator email from our list of generic options for RapidSSL and all GeoTrust products. That went live on March 6th (along with the other options we stated we would eliminate). This cert was ordered 2 weeks prior to that change on February 18th.
I want to confirm we did remove the ssladministrator email from our list of generic options for RapidSSL and all GeoTrust products. That went live on March 6th (along with the other options we stated we would eliminate). This cert was ordered 2 weeks prior to that change on February 18th.
Excellent - it this issue probably confirms that this was a good thing to do. I highly recommend to improve it even a bit further and opt for:

   POSTMASTER     SMTP               [RFC821], [RFC822]
   HOSTMASTER     DNS                [RFC1033-RFC1035]
   WEBMASTER      HTTP               [RFC 2068]
Ok I just (10 seconds ago) went to RapidSSL and enrolled for a certificate, got to the email approval address page and got this (we can go with WHOIS, or the list of "special" addresses still):

==================
RapidSSL Enrollment
 
  
Approval of Your Certificate Request
The RapidSSL.com RapidSSL® service relies upon the Subscriber or the Subscriber's authorized administrator to approve all certificate requests for all hosts in the domain. It is important that you select the correct authorized administrator below. By selecting an authorized administrator, you warrant that the individual is authorized to approve the request. Your request for a RapidSSL® server certificate will not be processed beyond this point if you select an incorrect email address.
Registered Domain Contacts
We have successfully obtained domain contacts for this domain from the domain registrar.
dnsadmin@seifried.org 	Registered Domain Admin contact
dnsadmin@seifried.org 	Registered Domain Tech contact
Alternate Approval Email Addresses
The following approval email addresses can be used. You must make sure that the email account has been set up and is available before you submit this order, or the approval email will not be delivered.
  
Level 2 Domain Addresses
administrator@seifried.org
admin@seifried.org
info@seifried.org
hostmaster@seifried.org
root@seifried.org
ssladmin@seifried.org
sysadmin@seifried.org
webmaster@seifried.org
info@seifried.org
postmaster@seifried.org
	
  
Level 3 Domain Addresses
administrator@www.seifried.org
admin@www.seifried.org
info@www.seifried.org
hostmaster@www.seifried.org
root@www.seifried.org
ssladmin@www.seifried.org
sysadmin@www.seifried.org
webmaster@www.seifried.org
info@www.seifried.org
postmaster@www.seifried.org
The action was as follows.

ACTION: GeoTrust will remove the following email addresses from their list of
options for domain validated certs: is, it, mis, ssladministrator,
sslwebmaster. 

It looks like those did get removed, according to the list above.

Then there's the follow on action which is dependent on the CA/B Forum providing the guidelines...

ACTION: GeoTrust will update their list to meet the CAB/Forum guidelines of
acceptable email addresses for domain validated certs, when the CAB/Forum
guidelines are provided.
The guidelines are stuck and IMO unlikely to become a reality anytime soon. It should be noted that it's nevertheless in the interest of the CAs that their domain control validation system is not going to be abused.
I'd like to know who here can officially speak for Firefox, I need to ideally get a response/quote on this for a follow up article and I'd like to get a response from Firefox (which as a group have been incredibly non-responsive with respect to this issue). I'm assuming at this point this bug will quietly be ignored just like bug 477783.
(In reply to comment #14)
> I'd like to know who here can officially speak for Firefox, I need to ideally
> get a response/quote on this for a follow up article and I'd like to get a
> response from Firefox (which as a group have been incredibly non-responsive
> with respect to this issue).

I recommend you contact press@mozilla.com, and they can put you in touch with somebody.
Jonathan and Kathleen are responsible.
Kurt, I'm trying to understand your comments as being motivated by a desire to help, but they keep coming off as more combative than I think someone trying to help would be. I honestly and earnestly appreciate people who try to help keep our root healthy, though, so I'm going to hope that I'm interpreting your intentions correctly here, that you really do want to make things better.

(In reply to comment #14)
> I'd like to know who here can officially speak for Firefox, I need to ideally
> get a response/quote on this for a follow up article and I'd like to get a
> response from Firefox (which as a group have been incredibly non-responsive
> with respect to this issue). I'm assuming at this point this bug will quietly
> be ignored just like bug 477783.

Can you help me understand why you think bug 477783 was ignored? Are you focusing on the bug's activity state (UNCONFIRMED) over the numerous comments from active community members and employees of Mozilla organizations? We should probably go through and update that bug to reflect the information that Kathleen notes here in comment 12, but your remarks dismissing all of that come after her comment, so I'm wondering where the disconnect is, there?

Certainly we want to ensure that CAs are taking appropriate steps to validate identity, and I think that's your key focus here, too. One thing we could do is just pull a root every time we see smoke, but I don't think that's what you're arguing for, is it? I know you know how profoundly disruptive that would be, and while it's a tool we have at our disposal for cases where a CA is wantonly misbehaving it seems, as Kathleen mentions above, by far the more sensible route to use our relationships with CAs to move them towards practices we consider more secure. 

If we didn't see responses from a CA, of course we'd have to move to more disruptive approaches, but in this case Jay has said that, in fact, they have accommodated precisely the changes we suggested after bug 477783. Do you think there was a better choice we could have made there that would adequately balance the health of our root program and the quality of our user experience? Security is certainly paramount, but flipping trust bits on and off at every accusation feels like it would show users so many intermittent certificate warnings that their attention to (and hence the efficacy of) those warnings would be diminished, not enhanced, doesn't it?

Jay needs to explain the email you got in comment 11, which lists addresses we understood them to have removed from the permitted list, but I'm able to imagine scenarios where updates to their issuing criteria didn't make it into their canned emails as quickly as one might hope. If new certs can't actually *be* obtained in the manner you did in comment 0, that's more important to me than what their emails *claim*, the latter being more of an embarrassment to RapidSSL than a security issue.

Finally, I'm sorry to hear that you've found the Mozilla community unresponsive on the issue. If you don't think it's impertinent of me to ask, where did you look for responses? Your dev crypto thread has several replies, as does this bug. To the best of my knowledge, you haven't contacted press@mozilla before today, certainly not for the article you mention in comment 1. You ask for someone "official" and I guess that's me and Kathleen as much as anyone, but as a writer for a Linux publication, I also know that you're well aware of the community-driven aspect of software like this, so I know I don't have to explain the fact that the answers and discussion you have gotten from the community are as essential to the process as any decree that I might make unilaterally. Frank Hecker is the module owner for the CA Certificates module, so you could ask him for his opinion as well, unless you've already done so for your article? I suspect his reactions will largely mirror my own.

I appreciate you fighting to make sure that CAs do their jobs. I think you'll agree that, at the end of the day, we need to see overhauls in certificate issuance in general. We started that work as members of the CABForum by setting a high standard for identity validation with EV certs - validation that went well beyond domain ownership - but that's not it. I think you'll agree that not every website NEEDS a high-cost, high-validation certificate, and that a place does exist for more basic-- but still reliable!-- validation. I appreciate your help in trying to narrow down the realm of mechanisms that should be considered acceptable there. What other steps do you think we should take on this issue?
A large part of it is frustration. I have reached out via mailing lists, I have posted evidence and all I got from Mozilla was... nothing. Someone else filed the bug and... nothing. Previous issues like this have been reported and ... nothing... has happened. 

You and Kathleen aren't listed anywhere in big letters as being the go to people on this issue, I never received emails saying "hi I'm the mozilla security guy/gal, can we talk about this?". I also noticed previous bugs (477783) being ignored and to be honest kind of lost hope (and decided to just take it out in public so at least there's a record of it). 

>Can you help me understand why you think bug 477783 was ignored?

Second last entry:

Gervase Markham [:gerv]      2009-04-07 04:26:20 PDT
Give me a couple of weeks to get consensus on a list :-)

And then silence. That was a year ago. Hence me thinking not much has been done. I used this exact problem (ssladministrator@) in late Feb 2010 (the 18th if memory serves) to get a certificate for a domain I do not own through RapidSSL. RapidSSL obviously hasn't addressed this issue, and Firefox still has the root certificate in there, hence the thought it's being ignored. I sent the emails to the list:

http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/ab1c21635e07d818/f567a1baee97476b?lnk=gst&q=portugalmail.pt#f567a1baee97476b

What really frustrates me is this was brought up back in 2000, I even wrote articles about it back in the day, and here we are ten years later, arguably much worse off.

-Kurt
Oh and as far as what CA's could do: for cheap SSL certificates (not EV/etc.) to establish ownership of a domain currently takes a single email address (ssladmin@, etc.) which is incredibly weak, if you can setup an email, or sniff traffic, intercept MX traffic to a secondary, manipulate DNS, etc. you can easily subvert this). What I would like to see is at least the level say Google uses for some services added to this:

1) verification of a WHOIS listed email@the domain (not email@somewhere else) or a well known address like comment 10 (POSTMASTER/HOSTMASTER/WEBMASTER). Not it@, is@, ssladmin@, etc.
2) verification of DNS control, generate say a random MD5 hash, have the person add it as an A name record pointing to 10.0.0.0 or something else harmless
3) verification of web control by adding a file to the webroot of the web server such as 9839hfwbqef2.html or whatever

At least with these three you know that either a) the person is the legit domain owner or b) the attacker controls enough infrastructure of the domain that any technical checks will be passed, so there's not much you can do beyond this.

The last two strategies were used by Google for things far less important than SSL certificates. 

But this will never happen since it would slow down ordering a certificate significantly and people would jump to a competitor that only requires the email confirmation.

I'd also like to see CA's make it easy to report suspicious/compromised certificates, I searched the RapidSSL site with no luck, finally tried the live chat, got bounced, was told to email order processing with the number. The funny thing is you as a domain owner technically have no rights to talk to a CA and report an improperly issued certificate apparently (Eddy Nigg mentioned adding it to the requirements, which I hope happens). 

These would be the top two items, but there are many more problems (as you probably know).
(In reply to comment #18)
> >Can you help me understand why you think bug 477783 was ignored?
> 
> Second last entry:
> 
> Gervase Markham [:gerv]      2009-04-07 04:26:20 PDT
> Give me a couple of weeks to get consensus on a list :-)
> 
> And then silence. That was a year ago. Hence me thinking not much has been
> done. 

My apologies for not being more communicative. I made a proposal to the CABForum, and got rough consensus. But then the list got worked into a larger best practices document, which (I believe) is currently stalled. And, TBH, because the bug wasn't assigned to me and because I have about a zillion job responsibilities I lost track of the issue. Mea culpa.

But I might politely ask in return: what did you do during that year to remind me that it didn't seem like I was making any progress?

Gerv
I apologize if this frustrates/annoys/angers you but look at it from the user perspective, we have at least one well known CA in the Mozilla root store that behaves _very_ badly, this has been known for quite some time, a solution was proposed (and apparently ignored by the CA) and nothing has been done about it. 

I don't want to get into a flame war or a **** match, as that serves absolutely no purpose. What I want is (ideally) for the CAs to behave properly (i.e. actually verify domain ownership/control), and for that to happen I strongly suspect Mozilla might have to give them a nudge (more likely you'll need to take a cattle prod to them). Yeah it sucks for you guys (this shouldn't be your job, you should be able to spend your time making Mozilla software better, not policing CAs) but I don't see any options really if Mozilla actually wants to ensure it's users are protected.

I have posted evidence (emails from ssladministrator@portugalmail.pt) showing RapidSSL issuing me a certificate improperly, you have the order number and domain name, dates and so on. You can easily ask RapidSSL what their excuse for this is/how they plan to fix it. As an end user there's basically nothing I can do (to put it bluntly, why would RapidSSL listen to me?). 

What more do I need to do?
Hey Kurt,

Thanks for the replies - it does indeed sound like you're looking to improve the situation, which is great. Thanks for that, too.

(In reply to comment #21)
> I have posted evidence (emails from ssladministrator@portugalmail.pt) showing
> RapidSSL issuing me a certificate improperly, you have the order number and
> domain name, dates and so on. You can easily ask RapidSSL what their excuse for
> this is/how they plan to fix it. As an end user there's basically nothing I can
> do (to put it bluntly, why would RapidSSL listen to me?). 

Jay, from Verisign, responded saying that the cert in question was issued before the changes we requested came into effect. Do you dispute his statement there, (beyond, as I mentioned in comment 17, the question of the canned email message listing more domains than Jay claims they now accept) or did you just miss it/not realize that it was from someone in a position to respond on RapidSSL's behalf?

Are there more questions you would like to ask Jay? He'll listen to you here. (He's a nice guy with a great accent, I'd like to believe he'd listen to you regardless, but certainly he's been responsive here in the past).
I didn't realize that Verisign was speaking for RapidSSL (does Verisign own RapidSSL?). And yes I do dispute it, see Comment 11, a few days ago their website still listed the "naughty" addresses as being acceptable. I don't want to shell out yet another $79 to test it (but will if I have to). 

Also my questions for Jay are: 

1) What list of email addresses exactly is Verisign/RapidSSL/? accepting (WHOIS listed ones, WHOIS isted ones @the same domain, hostmaster@ the domain, etc.)?

2) What does Verisign/RapidSSL plan to do to improve domain control/verification in the future (i.e. require a DNS record to be created, a file in the web site, etc.)? Or will it be business as usual (just an email check). 

3) Does verisign/RapidSSL have any plans to make it easier to report suspicious certificates/etc.? I had to jump through a number of hoops just to find out how to report the issue, it wasn't listed on the website at rapidssl.com anywhere I (or Google) could find. 

4) In order for domains to protect themselves from improperly issued certificates is there any way I can query Verisign/RapidSSL to see if a certificate has been issued for my domain(s)? We have proof that  people can improperly buy certificates for domains without alerting the real domain owner. How can domains make sure this hasn't happened to them and that an attacker isn't out there with a certificate?
(In reply to comment #23)
> I didn't realize that Verisign was speaking for RapidSSL (does Verisign own
> RapidSSL?).

Indeed, VeriSign acquired the RapidSSL product line as part of its acquisition of GeoTrust in September of 2006.

http://news.netcraft.com/archives/2006/05/17/verisign_to_buy_geotrust_combining_top_ssl_providers.html
Hi Kurt,

Yes, VeriSign acquired GeoTrust and the RapidSSL product line back in 2006. We have been following this thread and I did want to supply responses to your questions below. As to your dispute that we have not made changes to our processes, we did indeed remove the options requested of us from Firefox on March 6th (this was the planned release we had from last fall when the request was made to us). Mozilla requested we remove the following generic options: is, it, mis, ssladministrator, and sslwebmaster. If there are others you feel we should remove, we are open to hear your recommendations and can investigate the option of removing those. 

1) What list of email addresses exactly is Verisign/RapidSSL/? accepting (WHOIS
listed ones, WHOIS isted ones @the same domain, hostmaster@ the domain, etc.)?

VeriSign: Today we allow the admin and technical emails listed on the whois registration and the following generic options @domain.com to do the approval: admin, administrator, hostmaster, root, ssladmin, sysadmin, webmaster, info, postmaster


2) What does Verisign/RapidSSL plan to do to improve domain
control/verification in the future (i.e. require a DNS record to be created, a
file in the web site, etc.)? Or will it be business as usual (just an email
check). 

VeriSign: we are working on some plans for improving this process both internally and with the CA/Browser Forum. I think you made some good suggestions that are worth us investigating in terms of effectiveness and feasability of implementing. 

3) Does verisign/RapidSSL have any plans to make it easier to report suspicious
certificates/etc.? I had to jump through a number of hoops just to find out how
to report the issue, it wasn't listed on the website at rapidssl.com anywhere I
(or Google) could find. 

VeriSign: That is a good point. We are working through a website re-design and we will provide that feedback to our web team. 

4) In order for domains to protect themselves from improperly issued
certificates is there any way I can query Verisign/RapidSSL to see if a
certificate has been issued for my domain(s)? We have proof that  people can
improperly buy certificates for domains without alerting the real domain owner.
How can domains make sure this hasn't happened to them and that an attacker
isn't out there with a certificate?

VeriSign: If you want to supply me with a list of the domains you own offline, we can query our system to see if any certs have been improperly issued. You can reach me at jschiavo@verisign.com.
1) I would also ask that you remove ssladmin@ since it isn't a "well known" email address (most webmail providers have not locked it down, at least I haven't found one yet that disallowed it). Sent you an email from one.

2) Don't thank me, if memory serves it was Google that started doing that for Google analytics.

3) Please make at least a single page with a clear title like "report a lost, stolen or improperly issued certificate" so Google can easily find it. If Google can't find it, then people can't find it.

4) this is all well and good for  me but what about the banks/webmail providers/etc. of the world? I know automating this would be a pain/open to abuse (WHOIS domain contact scrapping for "ssl expiry notices bills" and whatnot but it worries me that with several dozen CA's globally no-one can be sure someone doesn't have certificates for their domain). 

My other thought moving forwards would be a notification email to WHOIS contacts/well known emails like root@ or administrator@ (which is usually redirected to an admin) along the lines of "billing name (using blah@yourdomain.com) has purchased an SSL certificate for yourdomain.com on somedate/time, if you have concerns about this please contact them or see our website for details".
The WHOIS-listed administrative contact should be the ONLY contact who can purchase a security cert. This should be an audit point for approving a root CA. That contact should be considered responsible for relaying the emails to anyone they want to delegate certificate authority to.

Furthermore, CAs need to send 'reminder' emails to the WHOIS listed administrative contact at yearly intervals, because it's possible to buy a domain that has been legitimately owned by someone else and then lapsed. This also needs to be an audit point.

Requiring administrators of domains to know to lock down 'special' email addresses is unnecessary overhead, and just plain NOT GOING TO WORK because how are they supposed to know when first configuring the site that they need to look up some special list held by blah.com or blah.org or superemailsnifferadminY@blah.net? There is no technical hurdle that an admin is going to encounter, and probably they don't set up certs at the start, so by allowing other email addresses, you create a lurking monster that arrives when least expected: "Oh no, when I started my website up last year I didn't lock down this list of magic email addresses, so goodbye security??? WTF!"

Security certs from any registrar who has been shown to contravene these simple, logical and easy-to-deduce security fundamentals (what did you guys THINK the WHOIS administrative contact was published in DNS for?) should be rejected AT LEAST for issuing dates up until the time that they finally do satisfy the auditing requirements, which must include this one. Sorry, but if you make security your business, that's the best treatment you can expect for failure. For the customers who have bought bad certs, very sad, hopefully you can get a refund, but no way can those certs be accepted now.
(In reply to comment #27)
> The WHOIS-listed administrative contact should be the ONLY contact who can
> purchase a security cert. This should be an audit point for approving a root
> CA. That contact should be considered responsible for relaying the emails to
> anyone they want to delegate certificate authority to.
> 
> Furthermore, CAs need to send 'reminder' emails ...

Nope! I'm not saying I disagree with your points here, but we've left the rails of the specific issue here, which means this belongs in newsgroups, not this bug. Jay is accommodating and patient, but the general changes you're proposing here are not Verisign-specific, so they should be discussed on their merits in a broader forum.
I never recieved an answer here or via email as to whether or not Verisign would remove ssladmin@ from the list. Will this be done? http://news.slashdot.org/story/10/04/18/1218212/Become-an-SSLAdmin-In-a-Few-Easy-Steps
(In reply to comment #28)
> Jay is accommodating and patient, but the general changes you're proposing
> here are not Verisign-specific, so they should be discussed on their merits in
> a broader forum.

Jonath, see comment 13

Lets take it a step further. It's the CAs absolute requirement to make sure that their domain control validation procedures live up to the Mozilla CA policy. I don't understand why we have to beg for the removal of every generic email address CAs use and kneel thankfully in appreciation for every little improvement.
Hi, I did want to provide an update from our side and say that VeriSign will be removing the following generic approver email options for GeoTrust and RapidSSL as of tonight or tomorrow night:

- ssladmin, sysadmin, and info

We did have these planned for removal in our upcoming release, but have acceralated that to tonight or tomorrow night. We will post an update once these are removed. 

Our hope is that Mozilla will work with the other CAs who use these options for domain validated certs to have them remove these asap as well.
(In reply to comment #31)
> Our hope is that Mozilla will work with the other CAs who use these options for
> domain validated certs to have them remove these asap as well.

Yes, I propose to take this to the policy news group and a list should be compiled about what other CAs have to offer in this respect, then address accordingly.
It's such an ease. RFC 2142 clearly defines in Point 3, 4 and 5 general addresses, finally point 5 defines so called administrative addresses dedicated to services (which are secured by SSL) so finally all CAs should commit to this general addresses and also no unobservant webmail provider then can run into the "surprise", that any addresses provided to the public are recognized by others as general administrative.

In addition the CAB forum should think about the best idea of customers recognition of validity level of certs by using traffic light colors of red for not validated, yellow for low validation (DV) and green for high validation (EV), finally OV should merge to EV. That would help everyone!
(In reply to comment #33)
> It's such an ease. RFC 2142 clearly defines in Point 3, 4 and 5 general
> addresses

#3 and #4 are lesser known, I suggest to refrain from those.

> In addition the CAB forum should think about the best idea of customers
> recognition of validity level of certs by using traffic light colors

The CAB Forum doesn't define UI, the browser vendors do that. And each does something else.

> not validated, yellow for low validation (DV) and green for high validation
> (EV), finally OV should merge to EV. That would help everyone!

Unfortunately EV doesn't allow for wild cards and in some jurisdictions not every legal business form is eligible for EV, specially self proprietor in Germany and the UK. But we should move this discussion to the news groups, not in this bug.
(In reply to comment #34)
> (In reply to comment #33)
> > It's such an ease. RFC 2142 clearly defines in Point 3, 4 and 5 general
> > addresses
> 
> #3 and #4 are lesser known, I suggest to refrain from those.

as mentioned, focus whould be #5, although we already also had #4 long time before, for sure it comes with roles like being member of RIPE etc. and also have #3 as they are also most usual. However #5 should/can be the focus.

> > In addition the CAB forum should think about the best idea of customers
> > recognition of validity level of certs by using traffic light colors
> 
> The CAB Forum doesn't define UI, the browser vendors do that. And each does
> something else.

The B of the CAB are the browser vendors, so they should be also interested in showing validation quality of secure sites, as security is always also a focus of browsers. Currently one big OS company shows TV ads also demonstrating the difference of spoofed sites in 8 seconds... Also this bug is here posted at a browsers vendor site, so I believe, they can/should be aware of and go one direction together, which finally is the goal of the CAB Forum => CAs and browser vendors go one direction together for better security...

> > not validated, yellow for low validation (DV) and green for high validation
> > (EV), finally OV should merge to EV. That would help everyone!
> 
> Unfortunately EV doesn't allow for wild cards and in some jurisdictions not
> every legal business form is eligible for EV, specially self proprietor in
> Germany and the UK. But we should move this discussion to the news groups, not
> in this bug.

Then wildcard issue should be reviewed, but Multidomain/SAN can help, German self proprietor already have a solution now, otherwise then also should be reviewed, e.g. then allow as "public register" also the DUNS register, D&B registrations are free and available worldwide, just take some while...

However for sure, this bug is not the right place for such discussions.
We wanted to provide an update to confirm as of last night we have removed support for ssladmin, sysadmin, and info as generic domain approver options allowed with the GeoTrust and RapidSSL domain validated certificates.

Jay
I believe this particular issue has been resolved.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → NSS
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.