Labels

Certificate Management 201

How to manage certificates and automate certificate fulfillment with a single platform 

How to install Certificate Inventory & Management

Before digging into this article, I also highly remommend to go through the SN documentation. The doc covers this topic pretty good.


Achieve service operations excellence with ITOM Visibility 


Certificate Inventory and Management is part of ITOM Visibility product line. So, you must have ITOM Visibility installed to install Certificate Inventory and Management module. 

Certificate Management Workspace


The Certificate Management Workspace offers a good overview of the org certificates. You can see and track the unique certificates, certificate expirations, certificates by fingerprint algorithm, etc. 

Certificate Management Dashboard

Alternatively, the certificate management dashboard comes in handy for those who are responsible for managing/renewal of certificates. You get all the necessary info to track the org certificates as effectively as possible.

Open Certificate Taks


As you can see, there’re 31 tasks for renewals for expired certificates; 1 priority task; 36 open renewal tasks and 0 open new request tasks. Below you can see the graph of upcoming expirations (which are broken down by critical and moderate upcoming expirations).

Certificate Inventory 


There are 236 unique certificates; 236 certificates with renewal tracking; 2 certificates with priority 1; 75 certificates discovered (last 30 days). You can also see who the root issuers are.

Certificate Task (Automation Flow)


Here you can see how many automated open requests you have. With automation you should have 0 open requests. Certificates should be automatically processed. 

Setting up certificate discovery and running discoveries

Port-based 

Discovery Port Probes 

The path for setting up the certificate management tool starts with activating a port probe/switch to start discovering your certificates. The method for port-based discovery: 


Table: discovery_port_probe

Once you install the Certificate Management app, you will have the option to activate port probe tls_ssl_certs by selecting active: 


This will enable the system to start discovering TLS/SSL Certificates. 

Here you have the option to select which IP services or ports you want to be discovered:  


The common/standard ones are selected OOTB. You can add more if you want. So, any certificates listed on those ports the discovery scan will pick them up. The IP services/ports need to be triggered to discover TLS/SSL Certs. 

Discovery Schedule 

Next, you need to set up a Discovery Schedule: 


Table: discovery_schedule

Discovery Schedules grouped by Discovery: 


There're many types of discovery schedules - discovery schedules for Certificates, CIs, Cloud Resources, etc. 

For example, the CI discovery schedule scans a subnet or multiple subnets (depending on the IP range) for devices that are in there.

By turning on the port probe (see above) the discovery schedule will look for certificates. So, there're no additional configs needed to discover certificates via a discovery schedule. 

Example of a CI discovery schedule: 


In the log of the discovery status (of the discovery schedule) you can see the results of the captured certificate information: 


So, download the certificate management app in your instance. Turn up the port probe and start discovering certificates inside PROD. You will start to see the value of it.

This is a straightforward example for setting up the port-based discovery. 

CA-based

Discovery CA Credentials 

For CA discovery, you need to create credentials to connect to the CA stores/providers. 

Connections & Credentials > Credentials  


The credentials type should be Certificate Management Credentials

Example of a CA credential: 


Discovery Schedule 

Example of a discovery schedule for CA-based certificates: 


This is a discovery schedule that discovers certificates based on the CA Trust Discovery (Certificate Discovery Type).

Serverless Execution Patterns


SN uses patterns for discovering things in your env. Patterns are instructions to query for additional info to gather the configurations of those devices. So, in this case the DigiCert Pattern is being used to gather info. 

Depending on which serverless execution pattern you need, you can go and import them: 


Within the DigiCert Pattern config you can specify the credentials alias to be used: 


Note:  

The MID Server needs to access the following endpoints depending on your use case: 
  • Entrust: Discover Certificate URL: https://api.entrust.net/enterprise/ 
  • Entrust Download root Certificate URL: https://web.entrust.com/root-certificates - 
  • DigiCert: https://www.digicert.com/services/ 
  • Sectigo: https://cert-manager.com/api/ssl/ 
  • GoDaddy: https://api.godaddy.com/ 
Result of CA discovery: 


CI vs CA discovery 

CI discovery will pull in every certificate that you have on your CI so that you can track live-cycle info. However, CI discovery doesn’t tell us where the certificate is installed. That’s why you want to run Port-based discovery to understand where it’s installed. Because certain certificates are installed across multiple systems. 

URL-based 

Discovery Certificate URLs 

For URL-based discovery we need to create a record in the certificate source URL table: 


Table: sn_disco_certmgmt_cert_url

To create a new certificate URL record you need to put the URL of the website: 


This will enable you to discover the certificate of that website with SN. 

Discovery Schedules 

Next, you need to create a discovery schedule to scan the website: 


Note: this does not require credentials. You can discover any public or internal websites that you want. You do not need credentials for that. 

In the Certificate URL tab, you can add the URLs which you want to include in the scan: 


You can also create multiple discovery schedules to discover different URLs at various times. 

Once the discovery schedule is ready, click on Discovery run to run the scan. 

Result of a URL certificate discovery: 


This means that for every website in the URL tab (see above) you can discover its certificate. 


Example of Netflix certificate in SN: 


You can see everything about the certificate. You have also the option to assign it to someone. Additionally, you have the option to choose the type of renewal task to create (Renewal tracking). 

Bulk Upload Certificates 

SN provides the upload feature to upload your certificates: 

Though it is not real-time data, it is still accurate data that you can track the life cycle of data’s certificates inside SN. This is a way to solve the challenge of non-discoverable certificates.  

Note: download the template file to upload your certificates. You can put up to 5000 records at the time into the spreadsheet.

Requesting and fulfilling certificates with automation 

Like with any request in SN we start in the Service Catalog. 


There are three catalog items: new, renew and revoke. Revoke request is only accessible to those that have a PKI admin role in SN (because not everyone should be able to ask for a certificate revocation). 

Request New Certificate

Backend:


Typically, when you request a certificate, you need a CSR. So, when raising this request, you need to fill in the CSR of the certificate. 

Good practice: set the validity period not higher than 365 days (about 12 months) 


A task is getting created once you submit a request new certificate: 


By clicking on submit the newly request will be processed by Entrust Routing Policy. This is because the data on the form matched the routing policy. Behind this type of request automation is happening. 


Once the task is completed, the certificate records and the chain of certificates are attached to the form. These are also stored in the CMDB. 

As requester, you can download these and then install them on the actual host(s). We do not deploy certificates to the actual host. You must install them manually. 


There is also a change request automatically created and related to the task record to ensure governance. So, now your change management process can take over.

Renew Certificate

Backend:


For renewal, you must choose an existing certificate. 


All the fields are the same as in the request new certificate except the type of task you want to create. This is carried over from the original certificate. 

Once you submit a request renew certificate then it begins to do the process behind the scenes to Entrust. 


Similarly to the request for a new certificate, once the task is completed the certificate records along with the chain of certificates are attached to the form for the request renew certificate. These are also stored in the CMDB.

Revoke Certificate


Here we do not need a CSR nor an approval. We need to select an existing certificate. We also get a prompt that asks if we really want to revoke the certificate. If yes, automation kicks in.


Once the automation runs then the task is completed and the change request is automatically created. 

Configuring certificate lifecycle notifications

Discovery Properties 

You can configure the certificate lifecycle notifications through the discovery properties: 


Note: regarding event management, navigate to flow designer > sublfows (search for subflows contains cert): 


If you deactivate Certificate Event Management, then it will not create alerts. 

Certificate Event Management flow:


Unique Certificate Table 

The unique certificate (cmdb_ci_certificate) table is where the certificates are stored after discovering them. In this table you can see the info about the certificate. There is one record for each unique certificate. One specific certificate might be installed on 5 different systems. However, there is only one record in this table. 

This table tracks the life-cycle state. Grouped by states: 


Remember: everything is driven (like the task creation, life-cycle management, etc.) off the unique certificate table. 

An example of a unique certificate record: 


Note: the first time when you run your certificate discovery the assigned to and change group will be blank. You will have to fill in or assign the certificates to owners and groups. If you do not, then all your renewal tasks will go in one bucket. It is good practice to get to a level of granularity with assignments. 

Further you can see the subject common name; the issuer; the state; the valid from and the valid to. You can also see if a certificate is self-signed or not. 

In the related items, the downstream relationships enable you to see where the certificates are installed. 

You can also see the relationships from a dependency view: 


You see the relationship of the unique certificate to the Linux server. You see the relationship from the Linux server to all its components. You also see the relationship to the HAProxy load balancer to the rest of its components. The certificate goes out to different applications. 

Important: this helps you to understand what is going to be affected when the certificate expires. 

In the related services you can see which services are being impacted when you don’t renew a certificate: 


Remember: on the certificate you can have INCs, certificate tasks, alerts, etc. 

Important: you can prioritize the renewal of certificates based upon what is going to be impacted. 

Installed Certificate Table 

This is where you can see where the certificates are installed. 


For example, nginx.636.com is installed on 10.196.108.57. 

Working through certificate tasks

Example of a certificate task: 



The certificate task looks like a regular task record in SN. This task has an assignment group/assigned to; it has a priority/state. Further you can see that this task - which is a renewal type - was created for a unique certificate. You can also set up approvals for certificate tasks.

The assignment group and assigned to come from the unique certificate record. 

Setting up automated certificate fulfillment 

STEPS 

First, enable this property to set up the default approval group: 


Property: sn_disco_certmgmt.cert_task_default_approval_group 

This property ensures that tasks which are part of the automated process that requires approval will need to be approved by that group. 

Second, you need to create a certificate credential. 

An example of a certificate credential: 


Third, create a CA record. 

An example of a CA record: 


You need a base URL that will process the automated fulfillment request. 

Fourth, set up a routing policy.

Ane example of a routing policy: 


You can have multiple routing policies per certificate authority (CA) depending on the certificate routing policy criteria.

Regarding credential alias, we say that this routing policy needs this credential alias to authenticate to entrust. 

For the certificate authority you need to fill in the entrust CA gateway. This is where it’s going to process that request.

Further, the entrust requires the CA identifier, certificate profile, etc.  

It is important to set the maximum validity period (for PKI standards) not more than a year (365 days). 

Another important thing is to activate the approval so that PKI admins can review requests for new or renewed certificates. For demonstration purposes, this is obviously not important. 

For the rest you need to set up the subject common name details. In other words, what common names will be processed by a certificate routing policy? This is more of a wildcard. You can set up different routing policies for different common names. 

Resources 

Labels:

Comments

Post a Comment

Popular Posts