Reading Time: 16 minutes

Proactive monitoring for API certificates is a must for every organization. For CloudHub customers, it’s important to consider certificate expiration when using certificates in MuleSoft. Why? Certificate expirations could lead to failing API calls. 

These API calls can be both inbound and outbound to the load balancer, internal system APIs, Process APIs, Experience APIs, and external third-party systems. To remedy this issue, internal expiring certificates need to be reviewed and then updated in the source code before the expiration date. For the external certificates, we need to get the renewed certificate from the third-party responsible and update them accordingly. While there is no MuleSoft out-of-the-box feature that can be used to monitor the certificate expiry, many organizations use proficient services like AWS Certificate Manager (ACM), Azure Key Vault, and open-source tools. Please keep in mind that if you purchase a certificate from a Certification Authority (CA), you will need to renew that yourself.

This article is for MuleSoft customers who have purchased a certificate from a CA and are interested in having the custom capability to alert the certificate expiration date to the responsible team for renewing and managing the certificate accordingly. The outcome of this article will be more helpful for the L2/L3 support and maintenance teams to follow up the certificate renewal with the internal or external teams.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

In a typical organization, a dedicated team owns certificate management, where developers or leads request a new certificate after certain approvals. Then they would request an SSL certificate to CA by sending a Certificate Signing Request (CSR). In return, CA would provide a signed certificate, their root certificate, and a private key. Please note that the certificate comes with validity depending on the request. This certificate will be provided to developers which will be used in an application. Once the certificate expires, they will request a renewal to get the renewed certificate with extended validity, which will be again updated in the application.

With this manual process, the most critical piece is remembering when to renew the certificate. Typically, CA notifies the registered email ID before the expiry, however, if the registered email ID  belongs to an individual who has left the organization or is away, this might present its challenges. A solution would be to create an automated process to keep track of expiration dates. With this proactive monitoring, the DevOps team would easily be able to track and update the certificates in the source code without any downtime. 

How to automate the process of certificate expiry 

There are multiple ways to manage certificate expiry depending on the preferred notification methods. For example, is it just an email that you want to trigger with the list of all the certificates expiring next month? Or do you want to have a UI with a graph or calendar that has all the expiring certificates that can be filtered on the date range?

Image caption: This is a sample Jenkins CI/CD flow to demonstrate how this new stage will help you set up alerts. 

Step 1: Updating the database

When a certificate is added or updated, it is flagged with details such as certificate name, common name, file name, expiry date, application name, organization name, environment name, etc. These details can be stored anywhere; like an Excel sheet on the drive or MySQL DB, DynamoDB, or MuleSoft Object Store. The process of adding certificate details can be automated, semi-automated, or manual depending on the time and effort you would like to spend on this solution. You can start with a manual approach, and then begin to automate the parts where most of the time is spent. Let’s explore these options below:

  • Option 1: For beginners, you can ask your team to update an Excel spreadsheet with all the information by maintaining a master sheet of all the certificates used in MuleSoft applications. There must be a process in place to make sure this information is updated for all the certificates before go-live.
  • Option 2: Expose an API that accepts a JSON with all the details related to the certificate. Consume this endpoint with all the details and store all the information in a database. There must be a process to make sure this information is updated for all the certificates before the go-live.
  • Option 3: Options 1 and 2 above are relatively manual methods, which may be prone to human error. Alternatively, for Option 3, you can automate Option 1 or 2 in your continuous integration and continuous delivery (CI/CD) pipeline by introducing a stage in CI/CD which checks how many certificates are being used in the application. If there are any certificates, fetch all the certificate details using a command-line tool like OpenSSL, and then update these details into the database using an API.
  • Option 4: If you are not comfortable with having this process in your CI/CD in Option 3, you can choose to have a Mule application that goes through all your business groups and environments to download the application zip to extract and fetch all the certificates and application details using a script component in Groovy or Python. Later update these details into the database using an API. Please note that this is the least desirable option because it takes the most time and effort. This is due to the complexity of finding the certificates in the application jar file and then the password to open the certificate to get the required details.

As mentioned earlier, this step can be manual or automated depending on the effort you want to spend on this utility. My suggestion would be to start by finding a suitable database and then expose this database with an API that you can reuse later with Option 3 or Option 4.

Step 2: Trigger the alert 

The next step is to trigger the alert. At this step you can query the available data with an automated scheduled job to find all the certificates, which have expiry in less than 30-45 days and divide them into multiple categories; such as critical (expiry < 7 days), major (7 <expiry < 15 days), minor (15 < expiry < 30 days), and low (30 < expiry < 45 days). Alerts can be triggered using Splunk, MuleSoft CloudHub alerts, Slack, or MS Teams notifications. Splunk comes with a lot of customization with attachments and email formatting, whereas sending emails using an official email ID can be tricky when you have two-factor authentication. I’ve laid out how to create that alert below, along with a few channel options shared under Step 3 depending on your preferred notification methods.

  1. Step 1: Create a Mule application that runs at a particular frequency to query all the certificates that have an expiry date within 30 days from our database.
  2. Step 2: If you are planning to use a MuleSoft custom alert, group the records according to their severity flag depending on the expiry date, and format your email content in the Dataweave. 
  3. Step 3: Send the formatted email content using one of the following options:
    • Option 1: Use a CloudHub connector or platform API to trigger the alert and set up a custom condition-based CloudHub alert on your runtime manager for this particular alert. Please note that email notification sent via the CloudHub alert has a character limit, any content sent above the limit will be truncated. To read more about CloudHub alerts refer to this article about custom application alerts and notifications and understand any limitations.
    • Option 2: If you want to avoid the CloudHub alert due to its limitation, you can always email with or without attachments using the email connector.
    • Option 3: If you are planning to use Splunk for features such as custom dashboard and email alerts, then you will need to send this information to Splunk in a JSON format. An alert can be easily created based on the information sent to Splunk using the search criteria. To read more about Splunk alerts refer to this article about their alerting workflow.
    • Option 4: You can also plan to send alert notifications on Slack using Slack APIs.

Conclusion

It is now proven that we can easily automate the certificate expiry notification after adding a new stage in your CI/CD pipeline. When you put the above steps in action by choosing your current tool and skill set, it will easily be possible to create a custom utility to alert required teams based on expiry dates. The above guide is just an example to accomplish certificate expiry alerts and there are multiple ways to achieve the same result. Please do not deem the above code as production-ready, as it may contain bugs or might have stability issues with your specific use case. Thorough testing is strongly recommended before considering it in production.

You can check out my updated end-to-end working project in the MuleSoft Consulting repo with more information about certificate expiry. Please check the project’s README.md file for more details. There are some changes required on the Groovy script in the Jenkins file (line number 40-50 refer README.md file). Please review and raise a merge request with your changes if you have them. We will review and commit them accordingly.