3 ms·

I know that automation is key here and all the benefits that doing thing very often bring BUT in the specific case of certificates issue if you have short lived

I know that automation is key here and all the benefits that doing thing very often bring BUT in the specific case of certificates issue if you have short lived certs now you have to ensure your CA system works perfectly, as its uptime now is the uptime of your whole platform. Yeah you can outsource it to AWS ACM and the like, or use Hashicorp Vault but still, it's something that before the change was totally static and now is an extra moving part. I'm not advocating against it, just exposing the whole story.

ArchOversight 6y ago
With a short expiry, let's say 90 days, you should be renewing 30 days ahead of time, so at the 60 day mark you attempt to renew. This grants you 30 days to fix any problems and get the system back up.
- shuntress 6y ago
  Then you have to automate handling the 60-day renewal failure warnings which adds another moving part.
  - johncolanduoni 6y ago
    If you can’t reliably automate sending an unignorable message to some set of humans when something fails to happen, you’re going to have a tough time keeping anything actively developed online.
NovemberWhiskey 6y ago
It depends on your organization, but in many ways the enterprise PKI CA is one of the easiest services to run at high availability. There are hardly any shared-data dependencies, so it's easy to scale; it's almost completely CPU bound with highly predictable demand, etc. Pretending it's "totally static" is exactly the problem. There are only two kinds of things in the software world - things that can stay the same until your next release, and things that need automation. "Almost completely static" is how your post mortem ends up on the front page of HN. A consideration of the full story also needs to include the risks associated with long-lived certificates. If you lose control of the private key associated with one, what do you do? Are you actually operating a CRL? Are any of your HTTPS clients actually checking the CRL? What would you do if a severe compromise were discovered that affected the signature algorithm you're using?

ArchOversight 6y ago

With a short expiry, let's say 90 days, you should be renewing 30 days ahead of time, so at the 60 day mark you attempt to renew. This grants you 30 days to fix any problems and get the system back up.

shuntress 6y ago
Then you have to automate handling the 60-day renewal failure warnings which adds another moving part.
- johncolanduoni 6y ago
  If you can’t reliably automate sending an unignorable message to some set of humans when something fails to happen, you’re going to have a tough time keeping anything actively developed online.

NovemberWhiskey 6y ago

It depends on your organization, but in many ways the enterprise PKI CA is one of the easiest services to run at high availability. There are hardly any shared-data dependencies, so it's easy to scale; it's almost completely CPU bound with highly predictable demand, etc. Pretending it's "totally static" is exactly the problem. There are only two kinds of things in the software world - things that can stay the same until your next release, and things that need automation. "Almost completely static" is how your post mortem ends up on the front page of HN. A consideration of the full story also needs to include the risks associated with long-lived certificates. If you lose control of the private key associated with one, what do you do? Are you actually operating a CRL? Are any of your HTTPS clients actually checking the CRL? What would you do if a severe compromise were discovered that affected the signature algorithm you're using?