7 ms·

I love how none of the example "dependencies" they give should be using public CA in the first place.

ahmeni 10y ago
Given some of the internal CA systems I've dealt within the past, I'd almost prefer a public CA in some cases. Sometimes your internal CA is just the group with manual access to the certificate provisioning and signing systems with either no API or some awful re-implemented API.
- revelation 10y ago
  What API do you need? The signing system should be airgapped or you end up with the same shit that is the public CA system such as roots sitting on public FTP servers. It's a bunch of command line scripts because if you are using it any different way you are probably doing it wrong.
  - Spooky23 10y ago
    Seriously. The fancy CA systems are wacky expensive.
    - revelation 10y ago
      I'm sure people make plenty of money wrapping OpenSSL in ever more elaborate Enterprise schemes. But if the net effect is that one bug in a frontend can cause the server to tell the cert server to tell the secure enclave to tell the wire mesh protected crypto coprocessor to sign a bogus certificate then what are we really doing here.
      - Spooky23 10y ago
        They sure do! We have an offline root on an HSM for various reasons. We looked at various systems to manage intermediate ca issuance and reminders for renewal and the cost was incredible... most were >$200k! Using scripts to automatically generate certificates and using the ugly but effective Windows CA web interface for "vanity" stuff does 90% of what those solutions do. I think we had an intern write a monitoring plugin to open tickets for soon to expire certificates and a few other things that covered the remaining 10%.
    - tyingq 10y ago
      I know several companies are using Amazon's ACM and public domains that resolve to internal ip addresses. It's not 100% automated, as it requires a validation email, but better than most homegrown stuff.
  - hiddencost 10y ago
    Practically the answer is "they pass it around via email"...
  - ahmeni 10y ago
    There's a massive logical leap between having an API and having certificates on public FTP servers. An API is required for you to have proper infrastructure as code and leaving any bit to human input other than another validation step in the automated process is waiting for errors to happen (invalid or incorrectly spelled cert info, missing cert chains, wrong cert chains, etc.). Symantec even calls out how much work these companies will have to do because so few of them have a proper certificate management system in place that's come back to bite them.
  - viraptor 10y ago
    There's more to it than you've seen so far. Think about environments with hosts starting on demand. You need to encrypt data in flight -> how do you automatically assign a new certificate to an instance on startup? You can't do it with an airgapped system.
    - revelation 10y ago
      If you're going to automatically create certificates you are shifting the entire authentication burden to that automated system. This is the exact issue with the public CA system, their automated processes have been found lacking and now what they certify can not be trusted.
      - viraptor 10y ago
        The topic was internal CAs. Those have completely different requirements and possibilities than public ones. The authentication will look completely different as well. You just can't compare those issues. And you're missing the point I raised as well - if you have hosts coming up automatically, you either need automatic certificates, or shared keys. As long as you rely on SSL, there's no other way to go. (For example of authentication: public CA verifies your domain, internal CA can ask the hypervisor to verify a token on your instance - not remotely in the same class)
    - deleted 10y ago
      [deleted]
- geofft 10y ago
  I'm curious if people other than LE have tried deploying Boulder in production, now that it exists. It seems like probably close to what a public CA wants. Ideally you'd have some way of tying it into some internal authorization database instead of relying on HTTP challenges, but HTTP challenges would work too. https://github.com/letsencrypt/boulder https://github.com/letsencrypt/boulder
- viraptor 10y ago
  The are some very-not-enterprisey internal solutions. For example there's Anchor from the OpenStack project with a minimalistic approach (as long as you're cool with the idea of rotating certs daily)
justinjlynn 10y ago
They know exactly what they've done.
will_hughes 10y ago
I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. (e: Also, don't forget the tons of 'smart' phones out there running ancient versions of whatever) If you're someone who supports applications that run on those, then your choices for what CAs you offer on your API/Media/etc endpoints is extremely limited. Some of these decisions were made more than a decade ago, and migrating off those is going to take another decade (i.e as old hardware dies).
- Pyxl101 10y ago
  > There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signed by the Symantec CA. Everything's hunky-dory. What's the problem?
  - will_hughes 10y ago
    Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am" So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.
    - Pyxl101 10y ago
      That certificate can be signed by whatever CAs you wish to use, including Symantec and others.
  - peeters 10y ago

Given some of the internal CA systems I've dealt within the past, I'd almost prefer a public CA in some cases. Sometimes your internal CA is just the group with manual access to the certificate provisioning and signing systems with either no API or some awful re-implemented API.

revelation 10y ago
What API do you need? The signing system should be airgapped or you end up with the same shit that is the public CA system such as roots sitting on public FTP servers. It's a bunch of command line scripts because if you are using it any different way you are probably doing it wrong.
- Spooky23 10y ago
  Seriously. The fancy CA systems are wacky expensive.
  - revelation 10y ago
    I'm sure people make plenty of money wrapping OpenSSL in ever more elaborate Enterprise schemes. But if the net effect is that one bug in a frontend can cause the server to tell the cert server to tell the secure enclave to tell the wire mesh protected crypto coprocessor to sign a bogus certificate then what are we really doing here.
    - Spooky23 10y ago
      They sure do! We have an offline root on an HSM for various reasons. We looked at various systems to manage intermediate ca issuance and reminders for renewal and the cost was incredible... most were >$200k! Using scripts to automatically generate certificates and using the ugly but effective Windows CA web interface for "vanity" stuff does 90% of what those solutions do. I think we had an intern write a monitoring plugin to open tickets for soon to expire certificates and a few other things that covered the remaining 10%.
  - tyingq 10y ago
    I know several companies are using Amazon's ACM and public domains that resolve to internal ip addresses. It's not 100% automated, as it requires a validation email, but better than most homegrown stuff.
- hiddencost 10y ago
  Practically the answer is "they pass it around via email"...
- ahmeni 10y ago
  There's a massive logical leap between having an API and having certificates on public FTP servers. An API is required for you to have proper infrastructure as code and leaving any bit to human input other than another validation step in the automated process is waiting for errors to happen (invalid or incorrectly spelled cert info, missing cert chains, wrong cert chains, etc.). Symantec even calls out how much work these companies will have to do because so few of them have a proper certificate management system in place that's come back to bite them.
- viraptor 10y ago
  There's more to it than you've seen so far. Think about environments with hosts starting on demand. You need to encrypt data in flight -> how do you automatically assign a new certificate to an instance on startup? You can't do it with an airgapped system.
  - revelation 10y ago
    If you're going to automatically create certificates you are shifting the entire authentication burden to that automated system. This is the exact issue with the public CA system, their automated processes have been found lacking and now what they certify can not be trusted.
    - viraptor 10y ago
      The topic was internal CAs. Those have completely different requirements and possibilities than public ones. The authentication will look completely different as well. You just can't compare those issues. And you're missing the point I raised as well - if you have hosts coming up automatically, you either need automatic certificates, or shared keys. As long as you rely on SSL, there's no other way to go. (For example of authentication: public CA verifies your domain, internal CA can ask the hypervisor to verify a token on your instance - not remotely in the same class)
  - deleted 10y ago
    [deleted]
geofft 10y ago
I'm curious if people other than LE have tried deploying Boulder in production, now that it exists. It seems like probably close to what a public CA wants. Ideally you'd have some way of tying it into some internal authorization database instead of relying on HTTP challenges, but HTTP challenges would work too. https://github.com/letsencrypt/boulder https://github.com/letsencrypt/boulder
viraptor 10y ago
The are some very-not-enterprisey internal solutions. For example there's Anchor from the OpenStack project with a minimalistic approach (as long as you're cool with the idea of rotating certs daily)

justinjlynn 10y ago

They know exactly what they've done.

will_hughes 10y ago

I find it hard to believe you can't imagine any valid scenario where at least one of those scenarios shouldn't be using pubic CAs. I've got personal experience with the first two (embedded devices and mobile apps) having pinned certificates (or limited sets of supported CAs) There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. (e: Also, don't forget the tons of 'smart' phones out there running ancient versions of whatever) If you're someone who supports applications that run on those, then your choices for what CAs you offer on your API/Media/etc endpoints is extremely limited. Some of these decisions were made more than a decade ago, and migrating off those is going to take another decade (i.e as old hardware dies).

Pyxl101 10y ago
> There's millions of internet-connected set top boxes, tvs, and dvd/bluray players deployed around the world that run with a limited set of supported CAs. What exactly is the issue? If an embedded device trusts Symantec CA, then connections from the device to its central servers will continue working without interruption. In this example, the device trusts the Symantec CA, and the server presents a certificate signed by the Symantec CA. Everything's hunky-dory. What's the problem?
- will_hughes 10y ago
  Clients have no way to indicate what CAs they trust, so my infrastructure has to just present a certificate and say "Here I am" So now if Google go ahead and distrust Symantec CAs, I need to duplicate that infrstructure (or at least the configuration at load balancers, etc) - this leads to all sorts of complexity.
  - Pyxl101 10y ago
    That certificate can be signed by whatever CAs you wish to use, including Symantec and others.
- peeters 10y ago