I've recently taken responsibility for managing our organization's SSL/TLS certificates. We have applications that send expiration notifications, but those alerts are only useful when the listed contacts and system owners are accurate. To improve that, I started sending a quarterly review to certificate owners asking them to confirm the details or report changes.
At the moment, the process is completely manual. I maintain a spreadsheet, filter it for each person, and email the relevant owners—currently using BCC—so they can confirm the certificate information, update the owner, or note any changes. Someone pointed out that distributing a spreadsheet containing all certificate details may expose information to people who do not need to see it. That seems fair, but I'm not sure how to send each person only the records they are responsible for without creating every message by hand.
How do you keep certificate ownership and contact information accurate? Our existing certificate tools do not have a built-in workflow for periodically confirming ownership. We are also aware that public certificate lifetimes will continue getting shorter, eventually reaching 47 days, with much shorter domain-control validation windows, so we are beginning to consider how to automate renewals and ownership checks. Currently, certificates are provisioned manually by another team.
3 Answers
First separate public certificates from certificates issued by an internal CA. The upcoming public-certificate lifetime reductions are a major reason to prioritize automation, but they do not necessarily apply to internally issued certificates.
You may also want to evaluate a certificate lifecycle management product, especially if the inventory is large or spread across many teams. Make sure the process is based on service or team mailboxes rather than individual employees wherever possible. Individual contacts leave you vulnerable to missed notifications when someone changes roles, leaves the company, or is listed on a certificate that has already been replaced.
It is also worth correlating certificates with active deployments. Expiration alerts for certificates that were retired months ago create noise and make people less likely to trust the notifications.
The long-term answer is to automate certificate issuance and renewal wherever possible, usually with ACMEv2, while adding monitoring that alerts you when automation fails or a certificate is unexpectedly close to expiration. For externally issued certificates, shorter lifetimes will make a spreadsheet-based process increasingly difficult to maintain.
A practical interim step would be to generate owner-specific reports automatically from the certificate inventory. Each owner should receive only the certificates and fields they need to verify, while the complete inventory stays restricted to the administrators. You can usually do this with a scheduled script, mail-merge workflow, or an IT service-management system.
Many organizations place TLS termination at a load balancer, gateway, or service mesh and make that platform team responsible for certificate issuance and rotation. Application owners then only need to confirm who owns the service and where the certificate should be used, rather than handling X.509 details themselves.
For the current process, avoid sending the entire spreadsheet. Keep a central source of truth with restricted access, then send each owner a filtered task containing only their certificate records. Require them to confirm ownership, service name, renewal method, and current contact information, and record a date for the last review.
That’s the direction I’d like to take, but we’re not close to it yet. Certificates are still provisioned manually by a central team, so I’m looking for a safer and more manageable process in the meantime.