0

I'm not aware of any frameworks/tools to achieve what we're trying to do, but posting here to hear experts opinions and comments on how this is done at large organizations and recommended automation approaches.

We have automation in place to identify, renew, and track SSL/TLS certificates expirations, but we're unable to see or track all the locations or programs where a certificate is installed unless application team or dev team knows about it.

For example, we create a SSL certificate for foo.internal.net and copy the same file to Apache, Java key store, and many other places. Wondering if there are any products or libraries that can track the deployment of given cert irrespective of the location, program, and OS, with semi or complete automation approach.

I am well aware that we can start a process and keep adding to that CMDB or DB, and keep building forever, to capture all this data.

Are there any approaches that would address some or all of these requirements?

Thanks

Improve this question

1 Answer 1

Reset to default
1

1. You must know where a cert is located because it is related to a private key. A leakage of such cert/key could be a step to attack whole infrastructure, just imagine leakage of a shared cert/key which is used for LDAP and equally for an unimportant HTTPS service. Wildcards certs are bad.

2. Copying that manually is not good solution.

For first issue you must have a management. For the latter you must have an automation which depends on the management.

The management depends on how you want to work. Do you run mostly containers? Is your workload static or dynamic?

The automation depends on a decision if you would implement "push" model, ie. one pushes changes to targets, or a kind of "pull" mode when targets update themselves from a trusted source.

There are products covering all of this. For example HashiCorp Vault is able to generate short-live TLS keys/certs via HTTP API. An update procedure could be initiated from a trusted management node or from the machines using these keys/certs via a scheduled job (cron job in UNIX world). Or you could have consul agent running on all managed nodes which would look for changes in consul's K/D database, and when a value (base64 encoded key/cert) changes, consul agent would react - save update key/cert, restart a TLS service.

Improve this answer
4
  • This is good information. Most of our environment is traditional IIS/.Net, Java/JEE, WebLogic, and WebSphere stack. We're into containers but not many applications are on that platform. We're interested in push model only as we cannot rely on applications/dev teams to pull the data. Heard about HashiCorp products but never used any of that, will these work in static/traditional IIS/Tomcat/WebLogic and other products?
    – cnu
    Commented Mar 10, 2021 at 19:46
  • Check here icicimov.github.io/blog/devops/… Basically, if you would have a process about adding TLS names - git file - you could create a job/action which would ask HashiCorp Vault to generate TLS keys/certs. Then you can either create a schedule job to get key/cert from Vault on each client and reload app, or you could have a central machine regularly updating/getting keys/certs from Vault and uploading them into a consul cluster which agents are on every TLS app, the agent would reload the app with a helper script.
    – Jiri B
    Commented Mar 10, 2021 at 20:00
  • Got it, we have automation in place to identify and renew expired certificates. I will explore Consul and Vault part to see if that's something we can integrate with homegrown PKI solution, to manage the certificates. Need to see management support to install a Consul agent on each and every application host/server.
    – cnu
    Commented Mar 11, 2021 at 3:22
  • Or as I wrote, on every app host/server you could get cert/key via HTTPS from a scheduled job. But the question is authentication vaultproject.io/docs/auth
    – Jiri B
    Commented Mar 11, 2021 at 9:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .