Learn how to Automate Integration of Applications with SSL/TLS Certificates from Microsoft PKI
Automatically creating and renewing X.509 certificates on Linux, Mac, and Windows from Microsoft ADCS PKI is simple and quick when using CertAccord© Enterprise. You can take that a step further and automatically integrate certificates with the applications that use them using Certificate Appliers™. This ability allows you to scale your certificate management system by removing manual processes resulting in faster deployments, fewer errors, and a much improved security posture.
Certificate Appliers are executable programs that are usually Bash/shell, cmd, or PowerShell scripts. Each Certificate Applier is usually written to integrate with a specific application such as Apache HTTPD, Apache Tomcat, JBoss, VPN clients, and 802.1x network authorization clients. While you could write a Certificate Applier that supports multiple applications in a single executable, we recommend you keep each applier small and focused on a single application.
Files and Directories
Certificate Appliers should be placed in certappliers directory on the end-point that has the CertAccord Enterprise Agent installed. The directory paths are:
- Unix (Linux, MacOS): /etc/cmb/certappliers
- Windows: C:\ProgramData\Revocent\CertAccordAgent\certappliers
Each certificate applier file should be named using a unique name and the appropriate suffix:
yourname.suffix
The yourname can be any alpha-numeric value you want. The suffix must be one of the supported formats below. All other files in the certappliers directory are ignored.
The file name suffix of each applier determines if it is run or not. The list below indicates the suffix names and how they are used. The suffixes are case-sensitive.
- yourname.yourpurpose.purpose – Run whenever certificate is created/renewed which has purpose yourpurpose
- yourname.all – Run for all certificate create/renew operations
Certificate Applier Execution Process
Certificate Appliers are executed using this process:
- Certificate is created/renewed
- Agent exports the certificate into file(s) based on the settings at the Agent level, product level (CertAccord Management Console), and command-line options.
- If the certificate has a Certificate Purpose then the certapplier directory is searched for all executable files named purposeName.purpose e.g. “AcmeApp.purpose”
- The certappliers directory is searched for all executable files ending with “.all”
- All the found appliers are executed in the sequential order they were discovered in.
The output from each applier is logged in the Agent logs. If a certificate is created on the command line and the “–verbose” option is given then the output is also displayed to the terminal.
Certificate Applier Execution Details
Certificate Appliers must have execute permission. On Linux/Mac this means mode 755 (rwxr-xr-x) or similar.
Certificate Appliers are executed with the same permissions as the Agent is running. On Linux/Mac this is typically user “root”.
Executable Certificate Appliers are run with the following command line arguments:
--certinfo file
The file argument is the path to a CertInfo file which contains details about the certificate. See the Administration Guide for details on the format of this file. The CertInfo file is created by the Agent and will be deleted by the Agent. Certificate Appliers should never delete the CertInfo file.
It is the responsibility of the applier to determine if the certificate presented is relevant or not. Make sure your applier detects if the certinfo it is given is relevant to the purpose of the applier. Your applier may be executed for certificates that are not what your applier is intended to handle.
Example Certificate Applier for Apache HTTPD
In this example we provide a Certificate Applier which integrates an X.509 certificate created through CertAccord Enterprise from a Microsoft Certificate Authority (or other supported CA) on a Red Hat Enterprise Linux end-point.
Required CertAccord Server Setup
On the CertAccord Management Console you need to configure the following settings:
Certificate Purpose
- Name: ApacheHttpServer (name does not matter)
- Usages: ServerAuthentication
Certificate Policy Bindings
- Type: Purpose
- Purpose: ApacheHttpServer
- Certificate Policy: YourPolicy (define in Microsoft ADCS to have Extended Usages of ServerAuthentication)
Certificate Subject Bindings
- Purpose: ApacheHttpServer
- Subject Template: CN=${hostNameFromConnect}
- SAN Templates: Dns:${hostNameFromConnect}
Required EndPoint Setup
The script is written to assume Red Hat Enterprise Linux 7-8. It can easily be adapted to other Linux distributions.
Required Packages:
- httpd
- mod_ssl
Certificate Applier Script for Apache HTTPD
The example certificate applier for apache HTTPD can be downloaded from:
myapplier.ApacheHttpServer.zip
The script should be extracted from the zip file and saved to
/etc/cmb/certappliers/myapplier.ApacheHttpServer.purpose
on the end-point. You can change myapplier to be whatever you like.
Make sure the script is executable:
chmod 755 /etc/cmb/certappliers/myapplier.ApacheHttpServer.purpose
Creating Certificate
Next we create a certificate with a purpose of ApacheHttpServer which will trigger the certificate applier we just created. We will use the “–verbose” option to have the applier discovery and execution output reported on the command line.
saturn$ cmb --verbose cert create purpose=ApacheHttpServer Authenticate using CertAccord/Active Directory Username: smith Password: Created certificate ID: 904526 SUBJECT: "saturn.contoso.com" ... Private key ID: 617cc [RSA 2048] Apply certificate 904526 [SUBJECT: "saturn.contoso.com" ...] Exported NAME: Certificate 904526 as PEM RESULT: CHANGED FILE: /var/cmb/cert/saturn.contoso.com-apachehttpserver.crt Exported NAME: Private Key RESULT: CHANGED FILE: /var/cmb/cert/saturn.contoso.com-apachehttpserver.key Apply Certificate 904526 [SUBJECT: "saturn.contoso.com" ...] Apply certificate using external executable appliers: 904526 [SUBJECT: "saturn.contoso.com" ...] Checking for certificate appliers with suffix ".ApacheHttpServer.purpose" in /etc/cmb/certappliers Found 1 certificate appliers Run [Cert Applier "myapplier.ApacheHttpServer.purpose"] for "904526 [SUBJECT: "saturn.contoso.com" ...] [Cert Applier "myapplier.ApacheHttpServer.purpose"] EXIT: 0 ELAPSED: 9.811 seconds [Cert Applier "myapplier.ApacheHttpServer.purpose"] standard output: Enabling apache access to /var/cmb/ca/ca-trust.crt Updating /etc/httpd/conf.d/ssl.conf Testing the new apache config Restarting apache Certificate successfully applied ERROR [Cert Applier "myapplier.ApacheHttpServer.purpose"] error output: Syntax OK
The output highlighted in orange is the standard output from the applier. The output in red is the standard error output.
To verify that the CertAccord certificates are configured you can run:
saturn$ grep /var/cmb /etc/httpd/conf.d/ssl.conf SSLCertificateFile /var/cmb/cert/saturn.contoso.com-apachehttpserver.crt SSLCertificateKeyFile /var/cmb/cert/saturn.contoso.com-apachehttpserver.key SSLCACertificateFile /var/cmb/ca/ca-trust.crt
Further Details
CertAccord does not itself distribute the contents of the /etc/cmb/certappliers directory. It’s recommended the customer deploy certappliers to this directory using an appropriate automation system such as Ansible, Chef, or Puppet.
More Certificate Applier Examples
How To Automate the Creation of 802.1X wpa_supplicant.conf on Linux With Microsoft PKI
Summary
We have demonstrated how to automatically create an X.509 certificate on a Red Hat Enterprise Linux system from a Microsoft PKI Certificate Authority. Not only did we automate the creation but we automatically integrated the certificate with Apache HTTPD without any manual process.
Customers can create their own Certificate Appliers or work with Revocent’s Professional Services team to create the application integration solutions required for their enterprise environments.
What to learn more and get a demo?
References
CertAccord Enterprise Administrator Guide