Back before I found Gandi.net I came across StartSSL (I was looking for basic SSL certifications.) At the time StartSSL's website was horrible, and I mean ugly, it turned me away because it felt so unprofessional. I see now, even with a new flashy website, that they still remain unprofessional (maybe not in their looks, but obviously in their practices.)
It's amazing that their web component is even allowed to dictate what verification addresses are permittable. That should be the concern of a completely separate component of their infrastructure. Says a lot of about their security architecture, I guess.
Why?
Because we had links to a Paypal account set up to take donations. Even though PayPal had its own security, and we were only providing a link to it, that was enough for them to deny us the cert. They refused to understand that WE would be conducting no financial transactions using their service; or that PayPal was a separate entity.
It was maddening, and we ended up abandoning the whole idea of having SSL. Would that LE had existed.
> Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only.
AFAIK simply taking donations counts as "commercial purpose". You are free to dislike their policy though.
This statement strikes me as odd. Email-based validation is the most common validation method used by most CAs for DV certificates. The only exceptions that come to mind are WoSign and Let's Encrypt.
The vulnerability is pretty bad, though. Good catch.
Whenever I've bought a cert for myself I've used the same process. I never thought email verification seemed like a great idea.
Also, did they check properly for TLD and subdomain issues? If I have "me.blogspot.com", can I get a cert for "blogspot.com"? (What's a TLD today? It's complicated. See "https://publicsuffix.org/")
--
[1] Yes, plenty of smart people have been advocating moving away from the current CA system. It's fundamentally broken.
[2] A great talk by moxie, filled with horror examples of CAs. The private key example is at 19:20. https://www.youtube.com/watch?v=Z7Wl2FW2TcA
¹ As long as you're monitoring CT log servers for anything involving domains you own.
Mozilla, Google, Apple and Microsoft should remove this CA ASAP. If it breaks some sites, even better. Maybe it will make some noise and fix all this CA bullshit for good.
[1]: https://security.googleblog.com/2015/10/sustaining-digital-c...
How long has this vulnerability existed? Can we trust any StartSSL certificates? Will they charge for revocation, as they did with Heartbleed?
Then again, I'm not exactly sure how one would go about reporting such a thing. Browser vendors have done most of the blacklisting for cases like this in the past (either by blacklisting individual certificates, or removing the root certificate completely for massive breaches). I guess I'd try my luck on one of their mailing lists or bug trackers.
If you have a regular certificate from StartSSL, there are no security implications for you because of this. (As in: for you specifically. For the CA system as a whole, this is a "Set-Your-Hair-On-Fire-And-Run-Around-Screaming-Loudly"-scenario.)
So, I corrected my WHOIS records... After which they complained that the legal disclaimer posted on the website served from the domain in question was not identical to the registered identity that they had on file for me.
So, I updated that legal disclaimer (since I have root on my own server), and afterward, they STILL refused to validate the domain on grounds that it may only be validated as a business -- a service which they tried to sell me.
15 minutes later, I was up and running with my first Let's Encrypt-issued cert.
Awful customer service at StartSSL.
That's not just an off the cuff insult either - I find very few charitable words to describe a company that charges $25 to rekey a certificate for reasons outside the user's control, i.e. heartbleed.
More to the point, in my arrogant opinion, now that a good, free alternative exists, users in the know should pressure the browser makers to come down a lot harder on companies that let this kind of issue fly. There's no need to work through the CAB bureaucracy when, say, Google and Mozilla are probably a lot more amenable to dealing with bad (be that by ignorance or malice) actors by refusing to recognize their crappily-validated certificates.
Let's Encrypt avoided this by partnering with Akamai. Though StartCom really should have made an exception for Heartbleed.
What makes them greedy? That they are charging for what they do? (Serious question I am curious why you label them "greedy" and further "losers").
They're the CA that wanted to charge $25 to revoke free certificates that were potentially compromised due to Heartbleed. Yes, it wasn't their fault, so they wouldn't be legally responsible for it, but they're acting in bad form by not offering those revocations for free for such a major issue.
> In 9 March, 2016 During my research I was able to replicate the attack and issue valid certificates without verifying the ownership of the website which I will explain later in my post, the vulnerability was reported and fixed within hours.
a CVE
What would be the practical use of issuing a CVE for a vulnerability in custom code in one website? It's not like I'm going to run Nessus to scan my own network for this.It's interesting to me that so many people strongly dislike StartSSL that they won't even use their product for free.
That really goes to show how bad their service is.
I'd lament again how we still need to push DANE, but I was doing that 2 days ago here on HN[0] and I'm tired of it.
Nevermind, maybe the next bug we see will be in one of the other DV methods, like tricking the validator to access a http uri of your choosing rather than '/.well-known/', for instance. Or authoritative DNS poisoning.
Who the heck cares about HTTPS for a fucking blog?