Designing a Public Key Infrastructure (PKI) for RWS GIS with Ansible

Discover how to streamline the creation and management of RWS SSL/TLS certificates and Java KeyStores using Ansible, integrating manual steps seamlessly.

Projects: c2platform/rws/ansible-gis, c2platform.core, c2platform.gis


In line with common practices among Dutch government organizations, the responsibility for SSL/TLS certificate creation is often delegated to a separate unit. The typical procedure involves generating a Certificate Signing Request (CSR), forwarding it to the designated unit via TopDesk, and receiving an official RWS certificate in return via email.

Unfortunately, automation is often hindered in such scenarios due to the absence of APIs. Unlike solutions such as Let's Encrypt  , there is no comparable automation in place.

This section elucidates the Public Key Infrastructure (PKI) design of the RWS GIS Platform. It delineates the creation and management of SSL/TLS certificates and Java KeyStores, with a setup designed to facilitate the creation of a fully functional GIS platform without the need for manual intervention.

While there are some manual steps involved, they are neither essential nor impediments to provisioning a fully automated GIS Platform. These steps can be independently performed to comply with security and compliance standards.

The proposed methodology leverages Ansible’s capabilities, utilizing modules from the community.crypto collection to establish a compact Certificate Authority (CA). Refer to the How to create a small CA — Ansible Documentation  for comprehensive insights and guidance on this process.


Step 1: OwnCA Certificates

The sequence diagram below illustrates the initial fully automated steps in provisioning services, including SSL/TLS certificates and Java KeyStores. The example employs Tomcat for an FME Core server, but the principle/idea is applicable to the provisioning of all services. The Tomcat role utilizes (through include_role) the cacerts2 role of the c2platform.core Ansible collection.This role delegates the creation of SSL/TLS certificates and Java KeyStores to a dedicated CA Server.

Any Linux server can fulfill the role of the CA Server. Linux is the preferred OS for these tasks due to the abundance of Ansible modules for Linux hosts and the complete absence of such modules for MS Windows hosts. It’s important to note that the choice of Linux as the OS for the CA Server is not solely based on its Ansible module support. Instead, it’s part of a strategic approach to centralized certificate management and issuance. As emphasized in the community.crypto.x509_certificate module documentation  , for enhanced security, the ownca provider should be operated on a dedicated CA machine. This is to avoid storing the CA’s private key on the target machine. Once the certificate is signed, it can then be transferred to the intended target machine.

Completing this first step results in a fully operational system without the need for manual interventions.

Within the RWS GIS platform, various actors are involved in certificate management and deployment:

  1. Ansible Automation Platform ( AAP ): AAP handles the deployment and management of servers, such as the FME Core servers. Additionally, it manages the CA Server.
  2. GIS Platform Team: GIS Platform management team.
  3. RWS CSP: RWS Certificate Service Provider (CSP) issues RWS certificates.

For the creation/configuration of a Java KeyStore on the FME Core Server, the following steps are taken:

  1. AAP initiates the deployment of Tomcat via the c2platform.gis.tomcat Ansible role.
  2. The Tomcat role (c2platform.gis.tomcat) performs tasks from the cacerts2 role, which delegates tasks to the CA Server.

On the CA Server, cacerts2 executes the following tasks/steps:

  1. Generation of certificate request.
  2. Generation of the certificate.
  3. Creation and import of certificates into the Java KeyStore.
  4. Import of RWS/OwnCA Root and intermediate certificates into the Java KeyStore.

On the FME Core server, cacerts2 executes the following tasks/steps:

  1. Copying the Java KeyStore from the CA Server to the FME Core server.
  2. The Tomcat role resumes control and configures Tomcat for HTTPS based on the Java KeyStore.
  3. The Tomcat role initiates a restart of the Tomcat Server.

After ensuring the initial functionality with OwnCA certificates, the next crucial step involves the substitution of these temporary certificates with official RWS certificates.

Step 2: RWS Certificates

The sequence diagram illustrates the steps necessary to ensure compliance with the RWS security policy, which mandates the use of a secure protocols like HTTPS with proper RWS certifictes everywhere, regardless of whether communication is internal or external within the GIS platform. Services are required to utilize official RWS certificates, obtainable exclusively through email requests.

  1. GIS Platform Team sends the CSR file generated in step 3 to the RWS CSP.
  2. The RWS CSP generates the certificate and sends it back to the GIS Platform Team team.
  3. GIS Platform Team receives the RWS certificate and replaces the OwnCA certificate on the CA Server with the RWS certificate.

AAP can now install the certificate, repeating steps 1 through 9 with the following differences:

  1. Steps 3 and 4 are skipped.
  2. Steps 5 and 6 result in a new keystore used in steps 7 through 9.

With the RWS certificates in place, the system is now fully compliant and ready for production use. This transition ensures a secure and compliant GIS platform, with the entire process automated through Ansible.