4 ms·

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

by ahmeni 9y 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 9y 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 9y ago
  Seriously. The fancy CA systems are wacky expensive.
  - revelation 9y 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 9y 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 9y 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 9y ago
  Practically the answer is "they pass it around via email"...
- ahmeni 9y 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 9y 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 9y 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 9y 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 9y ago
    [deleted]
geofft 9y 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 9y 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)

by ahmeni 9y ago

revelation 9y 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 9y ago
Seriously. The fancy CA systems are wacky expensive.
- revelation 9y 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 9y 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 9y 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 9y ago
Practically the answer is "they pass it around via email"...
ahmeni 9y 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 9y 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 9y 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 9y 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 9y ago
  [deleted]

geofft 9y 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 9y 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)