How to Become a Metadata Ninja in the Keyfactor Platform

I am often asked what is the right amount and type of certificate metadata. The answer is of course different for every company, and I have seen anything from 5 to 50 metadata items for companies.  However, there is some commonality to that data that can be easily explained.

Just to make sure we are all on the same page, let’s review what certificate metadata is and how it’s used within the Keyfactor platform.

Put simply, metadata is a powerful feature with Keyfactor that allows you to tag certificates with unique attributes, above and beyond the standard data available in X.509 format. Metadata fields can include any number of important details, things like certificate owner, business unit, and billing or contact information. These attributes are used to create collections, which help you define and manage groups of certificates at scale very effectively.

When asked about metadata, there are three key areas that I generally point out that every company should consider:

• Things that are important for the PKI team to know about a certificate
• Things that are important operationally to know about a certificate
• Things that are important for the business to know about a certificate

While often there is overlap in these three areas, having clearly defined scopes will help to make sure that the right items are captured every time.

Let’s look at each more closely.

PKI admins typically have the heaviest burden to manage certificates across an enterprise environment. The biggest challenge is tracking who owns what certificate (ownership), which application it’s being used for (location/usage), and when it expires (validity). 

Of course, tracking when certificates expire is an important first step, but it won’t help you to take action when it comes time for renewal. Using metadata ties the certificate to an application owner and location, which makes it much simpler to track down servers, DNS names, and contact details for every certificate issued.

Knowing who owns the application on a server is one thing, but it’s equally important to capture operational details. Some examples here include which servers the certificate protects, the OS being used, or what the various DNS or SANs are for the certificate. In some cases, I have seen this go as far as to capture which server rack, virtual host, or Kubernetes cluster a particular certificate is used for.

Last, but not least, is capturing information that is important to the business. These often include data that is specific to how the business operates. These could include information such as billing codes or departments, which are used for accounting purposes. It could also include associated risk profiles or compliance categories for auditors. This category in particular is very specific to each customer.

All in all, metadata is a very powerful feature in the Keyfactor platform and one that is universally used by all our customers. However, with the flexibility of metadata, each organization can decide what data is best captured for them. When combined with the power of certificate collections, metadata can give a unique perspective and view into the use of certificates in an organization and level up abilities for admins to become certificate lifecycle management ninjas.

Here are a few of the most common metadata fields I see:

• Certificate Owner’s Email
• Certificate Owner’s Team Distribution Email
• Production (T/F)
• Application Name
• Ticket Number/Reference ID

Head to the Keyfactor Demo Center right now to see how you can leverage certificate discovery, metadata, and automation to effectively manage certificates at scale and eliminate downtime caused by unexpected outages.

Watch it now →