StartCom will log all issued SSL certificates to public CT log servers
startssl.com
startssl.com
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..
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).
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.
But with LE allowing scripted certificate generation, we're just moving to that instead.
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.
The Dbound WG[1] was working on this, but sadly didn't seem to get anywhere.
Works nicely if you have a (mostly) fixed list of subdomains, but becomes hard or impossible to manage if subdomains are dynamic.
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.
Obviously, we said f*k that and just registered everything on the CEO's name and have him do the phone verification.
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.
It's not a vulnerability in the sense that it's not allowed in their CPS or by CA/B.
We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rely on security by obscurity, we'd really prefer it if our internal hostnames weren't published all over the internet... :\
Given Lets Encrypt does this too, I'm not sure what other options we have with regards to certificates without paying on a per-certificate basis. :( I like StartCom's model of only paying for verifications (i.e. the only thing which really directly costs money).
We definitely want our EV certs going to CT logs, but not any of our wildcard or Class 2/3 certificates.
If you don't want transparency of your certificates don't participate in the public CA system. You still have the option of using wildcards for internal names.
In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.
Honestly, it's not that easy. The StartSSL process is much, much, much easier.
There are a myriad of problems you need to solve when running an internal CA for your organization. Who has access to generate new certs? Is it automated, and what security controls are around that system? What audits are there around certs being cut? Who can revoke certificates? Then you get down to the details of CRL/OSCP...
While running your own PKI is great and definitely recommended, it's much easier to say "just set up PKI" than to actually do it and maintain it.
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...
I don't envy you though, that's quite a few subdomains you have there. Although I think that quite a few/almost all of those would have been found anyway if someone were to throw their dictionary at it.
Obviously that is mostly handled by access controls, but every little helps.
(Honestly curious, not trying to say you're wrong !)
If memory serves, it does say "should not" and not "MUST NOT" (cf. RFC2119). Thus, it's not technically a "violation" to do so but it certainly goes against the recommendations, IMO.
I also "do DNS for a living" (and have been for ~20 years) but I'm sure there's still things that I don't know. This is one of those often overlooked things simply because it isn't that common and one doesn't often see any major issues because of it.
Indirect references to such addresses should be contained within the
enterprise. Prominent examples of such references are DNS Resource
Records and other information referring to internal private
addresses. In particular, Internet service providers should take
measures to prevent such leakage.As someone else mentioned, creating a PKI is probably the way to go at this point.
And I suppose double check that none of them are binding interfaces they're not supposed to, if any of those have interfaces with public IPs.
And they are definitely not, but thanks. :) They're in an AWS VPC which is only internet addressable via explicitly defined servers. The default is to not provide a public IP.
not any of our wildcard
Perhaps all CAs for should be married to internet-facing domains with an encrypted, authoritative, non-repudiable cert discovery protocol... perhaps something like DNSSEC+DANE or something else.
Likely the only way to fix the situation is make some nonrepudiable proof-of-domain-ownership mandatory before any CA can issue any cert... although that doesn't solve the other issue of clients figuring out which certs to trust, although there have been some web-of-trust efforts to improve it (un-authoritatively).