[pfg]

It's worth pointing out that StartCom claims the verification email address in the article in question was only accepted because it matched the WHOIS record of said domain[1], which is permitted according to CA/B Baseline Requirements and their CPS. Definitely not a good choice by the researcher either way.

[1]: https://www.startssl.com/NewsDetails?date=20160322

[cypherpunks01]

That is real confusing, wouldn't that imply one party is outright lying?

Blog claims: In the last step of the validation process is where you can modify the email address and replace it with any regular email address

StartSSL claims: The email address used to verify the domain name is listed in the WHOIS records..

[pfg]

It could be that, or the researcher really didn't think to try it with an address that's completely unrelated to the domain.

Personally, I find it hard to believe that an audited CA has a system where the web frontend can make a decision as to what would be an allowed verification email address. I'm leaning towards believing their story, and would assume they have a backend system which is responsible for checking that input (and which happened to be out of sync with the options offered by the frontend). That's a reasonable explanation for the complete lack of validation in their frontend code.

Then again, some CAs have had a terrible track record, so I guess we'll never know for sure now that they fixed the issue (whatever the issue actually was).

[BillinghamJ]

Honestly, while StartSSL's front-end is awful, their practices always seem to far exceed other CAs - especially around verification.

I don't enjoy the website, or the verification procedure, but ultimately I generally trust them pretty highly - they operate in a way which shows me they care about security.

[creshal]

We've been generating certificates in direct violation of their TOS for over six years. Every few years they pretend to find out, we do another blatantly non-compliant verification, fork over 120 dollars, and they let us keep printing certificates.

[debaserab2]

Went through the same headaches for a few years. Their atrociously unfriendly and unintuitive interface finally just pushed me over to using a cheap alternative that is much less painful (RapidSSL in our case).

[creshal]

Until Let's Encrypt came around we've heavily depended on wildcard certificates (several domains with 100+ customer facing subdomains), so any other alternative would have been massively more expensive.

But with LE allowing scripted certificate generation, we're just moving to that instead.

[BillinghamJ]

That's interesting. If you don't mind, what rules are you violating?

[creshal]

You're only ever allowed to use your account with the person you validated with. You cannot share an account, e.g. between employees of the same company; if you want to transfer an account to another person over your vacation, you have to create a new account, re-validate, and recreate all certificates on the new account.

Obviously, we said f*k that and just registered everything on the CEO's name and have him do the phone verification.

[ikeboy]

>the vulnerability was reported and fixed

If this was not really a vuln, then they wouldn't have told the researcher it was fixed.

OTOH maybe it wasn't exploitable because the backend checks it, but they still considered it a vulnerability and fixed the ability to put a bad email in at all.

[pfg]

Sure, it's a vulnerability in the sense that they didn't want to allow WHOIS-based verification from their web frontend (for whatever reason. Maybe it wasn't even a conscious decision and they just forgot to include it during some rewrite.)

It's not a vulnerability in the sense that it's not allowed in their CPS or by CA/B.