Implementing PKI for RWS GIS with Ansible

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.

This section outlines the PKI architecture for the RWS GIS Platform, emphasizing the streamlined generation and management of SSL/TLS certificates and Java KeyStores. The process is designed for full automation, minimizing manual interventions.

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 approach employs Ansible’s community.crypto collection to set up a simple Certificate Authority (CA). This CA server is straightforward, with minimal requirements, and is driven entirely by Ansible without any running processes.

For detailed guidance, see the How to create a small CA — Ansible Documentation  . The c2platform.core.cacerts2 role leverages the community.crypto collection to implement the CA.

For hands-on exploration, refer to:

• Tomcat SSL/TLS and Java Keystore and TrustStore Configuration for Linux and Windows Hosts
• Create a Simple CA Server using Ansible

Step 1: GIS CA Certificates

Below is a sequence diagram showing the automated provisioning of SSL/TLS certificates and Java KeyStores for services like Tomcat on an FME Core server. The process is generalizable to any service provisioning. The Tomcat role uses the c2platform.core.cacerts2 role from the c2platform.core collection to delegate certificate and Java KeyStore creation to a CA Server.

Any Linux server can serve as the CA Server, with Linux preferred for its comprehensive Ansible module support. This strategic choice centralizes certificate management and issuance, enhancing security by isolating the CA’s private key from target machines.

The outcome is a system ready for operation with no manual steps required.

Step 2: RWS Certificates

This sequence outlines the process of replacing temporary certificates with official RWS certificates, complying with RWS security policies that require HTTPS and RWS certificates for all communications.

With the integration of RWS certificates, the platform achieves full compliance and is ready for secure production deployment, facilitated entirely through Ansible automation.