Creating an Inventory
Establish a comprehensive inventory of all keys and certificates, including their common names, expiration dates, location(s), owner(s), metadata (key length, CA, keystore type, etc.), and other information.
What is this?
An inventory is a repository of information about keys and certificates that are in use across an enterprise. It may include copies of the keys and certificates or just data about them—sometimes holding a copy of a key in a central inventory can increase the risk of compromise. A good inventory includes but is not limited to the following information:
- Name of the Key and/or Certificate
- Locations
- Key Length
- Algorithm
- Creation Date
- Validity Period or Expiration Date
- Issuing CA (for certificates)
- Owners/Contacts/Custodians
- Business Need (what is the business driver for using the key/certificate)
- Applicable Policies or Regulations
- Processes Used to Manage
Why should I care?
Encryption keys and certificates are used to secure critical data and systems, and therefore must be properly managed. If you do not have a list of keys and certificates that are deployed in your environment, it is difficult to ensure they are being managed in compliance with policies, regulations, and/or best practices. A critical starting point in any certificate and private key management strategy is to create a comprehensive inventory of all certificates and their locations. If you do not, you are risking a security breach or system outage.
Developing an inventory is not a trivial matter. In most organizations, certificates have been deployed over a period of years by a variety of different administrators in all sorts of locations. Often, the individuals who deployed the keys and certificates have been reassigned or have left the organization. Requesting a list from your certificate authority may be a good starting point to develop an inventory, but it is not a reliable method for identifying all keys and certificates and their locations.
What should I do?
Take a multi-pronged approach to ensure that no certificates are missed. The diagram below summarizes the recommended approach:

- Import from Certificate Authorities: The first step is to import certificates from all known CAs. There are two primary reasons for this:
- It can typically be done quickly and
- It helps in building a list of contacts (see Managing Contacts/Ownership).
It is very dangerous to assume that an import from your known CAs will provide an accurate inventory of all certificates. Invariably, organizations find additional certificates during discovery (the next two steps) that were not accounted for by the CA. These certificates are typically certificates from other CAs that are not approved by your organization or self-signed certificates generated by the applications where they are deployed. These culprits can cause some of the most serious downtime.
- Network Discovery: The next step is to perform a network discovery to discover any server-side certificates—certificates that are present on a listening port. For this step, it is important to coordinate with your network team, intrusion detection group, and any other groups that might be impacted. The network team can typically help in providing IP addresses that should be scanned. However, if you already have a solution in place to regularly scan IP addresses and ports (e.g. for vulnerability scanning), this solution may be able to provide certificates to import into the certificate inventory database. Alternatively, it can provide a list of known IP addresses and ports which can be scanned by your network discovery solution. Firewalls invariably play into any network discovery strategy. In some cases, you can have the necessary ports opened up in all firewalls for a central discovery system to perform operations. Alternatively, you may need to deploy discovery engines on the other side of firewalls in each network zone and configure each discovery engine to pass the discovery results into the central certificate inventory database.
- Agent-based Discovery: Many certificates are not discoverable via network ports, such as client-side certificates used for mutual authentication on SSL. In-service expirations of these types of certificates can be as damaging as server-side certificates so it is important to include them in your inventory. Unless you can confidently count on administrators to tell you about all of these certificates, finding these certificates typically involves performing file system scans on server and client systems with an agent.
- Individual Import by Admins: Network and agent-based discovery can take time and it may not be possible to perform discovery in all corporate locations. That makes it critical to educate administrators and make sure they are proactively reporting any certificates they are aware of and adding them to the inventory. (See Defining Roles and Responsibilities for more on this.)
In performing the above steps, it is important to have a system that can correlate the results of each inventory method so you do not end up with duplicate entries. Also, performing an inventory is not a one-time event. You have to regularly repeat the steps above to update the inventory. Here again, it helps to have a system that helps you correlate the results of, for example, newly discovered certificates and only show you new certificates and not every certificate that was discovered during a run.






