The plan for CT was always to be once extended to all certs. And I think this is right. This whole system has suffered from security failures kept under the rug for too long, more transparency is good.

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.

If they are internal hostnames, don't you control both client and server? Why not create a PKI?

In my opinion the only advantage certificates from official CAs bring is that clients you have no control over are not MitMed.

Well yeah, that is a fair point actually. There would be a couple of issues to sort out, but nothing major or anything we couldn't deal with.

Setting up your own CA is rather easy, for internal hostnames I'd definitely not bother with going to an external CA (nor want an external CA to have control over internal certificates).

Having set up and run an internal CA for a > 1000 person org that needed to issue a couple certificates a week, I would refute the "easy" claim.

Still easier than StartSSL's horrible, occasionally unreachable, web interface I'd bet.

I hope you don't often place bets. :P

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.

I've always enforced a strict policy of every certificate request be asked for in person by someone with authority to ask us for one, and then a second person actually issues the certs after an hour, just in case. Nobody likes being responsible for data breaches, and I for one am a sadist and a masochist when it comes to keeping control of my systems.

I think the end-game for CT is that all certificates will have to be submitted to log servers, so this is going to happen anyway.

The current CT draft spec permits the CA to generate a precertificate containing "?.example.com" instead of "secretproject.example.com", for exactly this reason:

https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...

I don't think that was really an option in this case as his CA just went and published the logs without asking the users first?

I'm pretty sure they're not publishing any existing certificates, so that's okay, but they definitely need to treat the fact that they are doing from now on as a "breaking change" and be very clear about it to existing users.

Yeah, I don't know what StartCom is actually doing. All I'm saying is that StartCom has the option of redacting the labels, and as a paying customer, they should be asking StartCom to do so.

RFC6962bis is still a draft and there are no implementations of it yet, so actually they don't have the option to redact labels.

Did all of those internal hostnames need to be accessed over the internet in the first place?

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.

Most of these hostnames are on 10.x IPs, so not internet addressable anyway, but we don't really want to advertise how our internal services are structured.

If they're on private IP addresses, per RFC, they shouldn't be listed in a public DNS zone. If they aren't listed in a public DNS zone, it's not really an issue, is it?

Still a bit of an issue. Primarily the reasoning here is that if you compromise one of our systems, we'd prefer to make it as difficult as possible to traverse across our internal network.

Obviously that is mostly handled by access controls, but every little helps.

Which RFC is that? I've never noticed this restriction in any of the DNS RFCs (and I do DNS for a living ;))

(Honestly curious, not trying to say you're wrong !)

RFC1918.

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.

So it does, I've never noticed this section before:

   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.

I'm not aware of any RFCs on the matter either. Some DNS servers do this to protect against DNS rebinding attacks, though.

Ah, the use of public ca implied a more general use scenario in my head.

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.

Yeah, agreed. We had used it so far simply because it was convenient. I do still think it's important for StartSSL to be very clear about this to their existing customers though - it's a breaking change of sorts.

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 

But if you get a wildcard, it doesn't leak anything about the names or details of your internal servers.

Not really true. Wildcard certs only work for one level of labels. As such, we still have to include quite a large proportion of a set of our internal hostnames in the cert