Ansible Role: Keystore Truststore

We are going to look at an Ansible role for generating self-signed certificates and storing them in a PKCS12 keystore and truststore. With these, you can enable SSL/TLS on your services.

Previously we looked at a Couchbase Ansible Role, in this article we will look at another role for enabling https on your services.

I was in need of a simple way to generate a keystore and truststore with self-signed certificates for testing our microservices at work. The goal was that it should be completely automatable and also portable. Ansible was a good tool for the job and I started working on a role that can be used for generating exactly this. The role can be found here: https://galaxy.ansible.com/snieking/keystore_truststore.

ansible-galaxy install snieking.keystore_truststore

Requirements

The role has a few requirements on the host where you will run it.

  • Java installed with JAVA_HOME/bin on the path
  • Pip installed
  • OpenSSL

Example Playbook

- hosts: localhost
  connection: local
  roles:
    - role: snieking.keystore_truststore
      common_name: thecuriousdev.org
      country: SE
      state: Stockholm
      locality: Gröndal
      organization: thecuriousdev
      organizational_unit: blog
      keystore_pass: unsecure
      services:
        - name: thecuriousdev.org
          alt_names: 
            - "DNS.1  = *.thecuriousdev.org"
            - "DNS.2  = localhost"
            - "IP.1   = 127.0.0.1"
        - name: example.com
          alt_names:
            - "DNS.1  = example.com"
            - "DNS.2  = localhost"
            - "IP.1   = 127.0.0.1"

Details

As you can see, you can specify all the subject fields. It is also possible to specify a list of services, which will all get their certificates imported to the keystore. In this list of services, you can specify the subject alternative names that should work. For example, if you have a site running on https://thecuriousdev.org, then you can have the following SAN: *.thecuriousdev.org.

Under the hood, the role with utilizing OpenSSL and Java keytool to generate the certificates and the keystore. The keystore and truststore are in the standard PKCS12 format which means it can be used for applications that are not java services. 

The truststore trusts all the certificates that we have generated, as well as the Baltimore certificate authority. The reason for that is that we needed it to trust Microsoft Azure.

What’s next?

The role is a work in progress and I have a couple of improvements that I would like to do. One thing that I would like to do is to remove the dependency on Java and just rely on OpenSSL. Another thing I would like to do is to make it easy to provide your own certificate authorities that you would like to include in the trusted certificates.

Make sure to check out the GitHub page so that you are up-to-date with how the role works as of when you are reading this.

Updates

Some extra work on the role has been done. We will no longer by default trust the Baltimore certificate authority. Instead, you can now provide a path to a local directory where you store certificates of authorities that you want to trust. The role will then make sure that those are trusted.

trusted_ca_path: /my/trusted/ca-path/

It is also possible to persist your certificate authority throughout more runs now by overriding the flag for clean up. This means that you will keep appending new aliases to your keystore and truststore. If the same alias for a certificate in a keystore is discovered, the role will override that alias and certificate.

clean_up: no

Leave a Reply