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

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

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

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.

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.

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

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.

How do you plan to get around LE's 5 subdomains per 7 day period limit? You can only get about 60 subdomains in theory, and that only if you stagger the registrations out carefully over three months and never make any mistakes.

If appropriate for your use case, you can get your domain added to the public suffix list [1]. Then the restrictions no longer apply.

This has side-effects with browsers and cookies so you wouldn't want to do it on a domain without understanding the impact.

[1]: https://github.com/publicsuffix/list/blob/master/public_suff...

P.S. In the unlikely event that someone involved is reading this, PLEASE make this a DNS attribute that is set on the top-level domain instead, in a TXT record perhaps. It's silly that we have to have a globally coordinated and distributed list for this data.

> P.S. In the unlikely event that someone involved is reading this, PLEASE make this a DNS attribute that is set on the top-level domain instead, in a TXT record perhaps. It's silly that we have to have a globally coordinated and distributed list for this data.

The Dbound WG[1] was working on this, but sadly didn't seem to get anywhere.

[1]: https://tools.ietf.org/wg/dbound/

You can get up to 100 SANs on one certificate, which will only increase your rate limit counter by one.

Works nicely if you have a (mostly) fixed list of subdomains, but becomes hard or impossible to manage if subdomains are dynamic.

You can get 100 subdomains per certificate, you're only limited to 5 certificates per domain per week.

That's largely sufficient for our use case, but we're still staggering renewal for certificates on our main domains. So far it's no problem because renewal is fully automated and we're leaving buffers.

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

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.

Oh right, yeah. I'm pretty sure every company violates that particular rule :P

Every company that does this loses all their auditing capabilities on the systems that use these accounts. Not good.

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

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.

Reminds me of Symantec's "we really like CT too, and have spontaneously decided to use it for all our certs" after Google ripped them a new one and demanded they do it: https://security.googleblog.com/2015/10/sustaining-digital-c...