6 ms·

As a Class 4 StartCom subscriber, this is quite irritating. We use StartCom to issue a lot of certificates for sensitive internal hostnames. While we don't rel

As a Class 4 StartCom subscriber, this is quite irritating. 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.

DoubleMalt 11y ago
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.
- BillinghamJ 11y ago
  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.
  - creshal 11y ago
    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).
    - ryan-c 11y ago
      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.
      - creshal 11y ago
        Still easier than StartSSL's horrible, occasionally unreachable, web interface I'd bet.
        TheSwordsman 11y ago
        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.
        davenull 11y ago
        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.
pfg 11y ago
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.
hannob 11y ago
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.
Namidairo 11y ago
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.
- BillinghamJ 11y ago
  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.
  - Namidairo 11y ago
    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.
    - BillinghamJ 11y ago
      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.
  - jlgaddis 11y ago
    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?
    - kiallmacinnes 11y ago
      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 !)
deleted 11y ago
[deleted]
geofft 11y ago
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#section-4 https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...
- Namidairo 11y ago
  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?
  - BillinghamJ 11y ago
    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.
  - geofft 11y ago
    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.
    - agwa 11y ago
      RFC6962bis is still a draft and there are no implementations of it yet, so actually they don't have the option to redact labels.
technion 11y ago
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.
- BillinghamJ 11y ago
  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

DoubleMalt 11y ago

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.

BillinghamJ 11y ago
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.
- creshal 11y ago
  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).
  - ryan-c 11y ago
    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.
    - creshal 11y ago
      Still easier than StartSSL's horrible, occasionally unreachable, web interface I'd bet.
      - TheSwordsman 11y ago
        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.
        davenull 11y ago
        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.

pfg 11y ago

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.

hannob 11y ago

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.

Namidairo 11y ago

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.

BillinghamJ 11y ago
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.
- Namidairo 11y ago
  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.
  - BillinghamJ 11y ago
    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.
- jlgaddis 11y ago
  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?
  - kiallmacinnes 11y ago
    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 !)

deleted 11y ago

[deleted]

geofft 11y ago

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#section-4 https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-13#...

Namidairo 11y ago
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?
- BillinghamJ 11y ago
  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.
- geofft 11y ago
  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.
  - agwa 11y ago
    RFC6962bis is still a draft and there are no implementations of it yet, so actually they don't have the option to redact labels.

technion 11y ago

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.

BillinghamJ 11y ago
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