Introduction

With the increasing use of https and transport layer security, over time more private keys and certificates have to be managed. While some applications and technologies can use PEM-formatted keys and certificates directly, Java applications typically require certificates and private keys stored in a keystore or truststore.

Depending on the used technology the effort to provide private keys and certificates to an application can be quite challenging. For this reason, we decided to add a function for managing key and trust stores to ConfigSeeder and thus do some work automatically.

Hypothetical scenario

Imagine the following scenario (in our experience, certificates are organized similarly in many companies):

• There is a root certificate with tree intermediate certificates.
• All application certificates for the production environment are signed by the prod applications intermediate certificate.
• All application certificates for the test environments are signed by the test applications intermediate certificate.
• All infrastructure service certificates (like the web proxy) are signed by the infrastructure intermediate certificate.

Consequences

• Every application which provides https (or tls) services requires its own private key and certificate.
• Any application that consumes an https (or tls) service requires the root and application intermediate certificate to verify the certificate returned by the service.
• Every application which uses the web proxy requires the root and infrastructure certificate to be able to verify the certificate returned by the proxy.

If you are using java, you will likely need to provide the private key and accompanying certificate in the form of a key store. In this case, you must also provide the necessary certificate chains in the form of trust stores.

Application A

If application A accesses application B it requires:

• A key store containing its own private key and certificate
• A trust store containing the root certificate and intermediate certificate for applications (Reason: Validate certificate of application B).

Application B

If application B accesses application a as well as the proxy it requires:

• A key store containing its own private key and certificate
• A trust store containing the root certificate and intermediate certificate for applications (Reason: Validate the certificate of application A).
• A trust store containing the root certificate and intermediate certificate for infrastructure services (Reason: Validate the certificate of the web proxy).

Consequences and Challenges

There will be more than one trust store around containing exactly the same certificates (In real life multiple applications will access other applications and multiple applications will access the web proxy or other infrastructure).

Imagine an intermediate certificate with an ending lifetime: Are you sure you know exactly in which trust store the certificate is used? ConfigSeeder stores the certificate in one location. Depending on your use case, a renewed intermediate certificate is updated once and will be distributed on access or even automatically.

If trust stores are created manually: How do you know which certificates are contained in a trust store? If the trust store is used in a production environment you probably don’t even have access to it. With ConfigSeeder you can specify exactly which certificates are selected when creating a trust store.

Capabilities of ConfigSeeder

ConfigSeeder can take over the following kind of work:

• Store private keys and certificates
• Create PKCS12 or JKS formatted key and trust stores
• Manage stores on a file system (requires OS Connector)
• Manage stores as Kubernetes Secrets (requires Kubernetes Connector)
• Optionally send notification emails if the lifetime of a certificate is nearing its end.

Be aware that ConfigSeeder just stores certificates. ConfigSeeder doesn’t currently implement PKI functionality and we also haven’t planned this for the future.

Manage Keystores and Truststores

Depending on the target runtime environment an assembly of type File: Keystore or Secret: Keystore is required for every key or trust store you like to manage.

A newly created Assembly of type key store doesn’t contain any configuration values for storing private keys or certificates. You have to decide which data should be contained in the key store and add the corresponding attributes.

Key stores

A key store contains a private key and its accompanying certificate. Usually, only one application uses this data. Therefore ConfigSeeder stores the private key and certificate directly in the assembly. Of course, you can use all activated filters to select the required private key and certificate for different scenarios. The following screenshot shows how you can define different data for the environments TEST and PROD.

In the same way, it is possible to select data depending on a version, date and/or a context. You can store one or multiple private key / certificate pairs. By clicking on the preview button, you can see how the data will look like. The following example shows a key store with a complete certificate chain.

Trust stores

A trust store contains one or more certificates (certificate chain), but no private keys. As shown in the hypothetical scenario, multiple applications typically use the same certificates. Therefore, and unlike the key store shown earlier, an Assembly that describes a trust store doesn’t contain the certificates themselves, but rather certificates that are contained in a referenced configuration group.

The Assembly itself only contains a reference to one or multiple configuration groups which stores the certificates. Optionally you can define an additional regex to define exactly which certificates should be imported into the trust store.

The referenced configuration groups contain the certificates. This could look like shown in the following screenshot.

This example defines the root certificate which is valid for all environments and the application intermediate certificate which is different for TEST and PROD. If you create the trust store for TEST or PROD ConfigSeeder ensures that the created trust store contains the right certificates.

Runtime Environments

File systems (Linux / Windows)

Managing key and trust stores on a file system is done with Assemblies of type File: Keystore and requires the OS Connector.

If installed on a virtual machine you can control when the OS Connector retrieves the newest key and trust store from ConfigSeeder. One possibility would be to update the stores on deploy time, another before every restart of the application.

If you use the OS Connector as a Kubernetes init container, you can also provide a key or trust store to some workload running in Kubernetes. Every time the application starts, the os connector retrieves the newest key and trust stores from ConfigSeeder.

Kubernetes Secrets

Managing key and trust stores as Kubernetes Secrets is done with Assemblies of type Secret: Keystore and requires the Kubernetes Connector.

You can update the Secrets holding a key or trust store periodically (run the Kubernetes Connector as a Cron Job) or at a specific event like the deployment of an application or the restart of an application. Please see our blog article for more details.

The following example shows how a Secret which contains a key store created by ConfigSeeder looks like:

kind: Secret
apiVersion: v1
metadata:
  annotations:
    configseeder.com/dataHash: 299614750f422d19a3370bca179de36b6e0f358a2f8d985eed751d76470de43d
    configseeder.com/managed: "true"
    configseeder.com/module: SMM_KEYSTORE
  name: my-keystore
  namespace: my-application
data:
  keystore: MIIN9wIBAzCCDbAGCSqGSIb3DQEHAaCC...
type: Opaque

You can of course inject key and trust stores contained in Kubernetes Secrets into Deployments and use them like any other key or trust store from your application.

Conclusion

Our feature to create key and trust stores directly out of ConfigSeeder doesn’t solve all problems around certificates. In particular, we haven’t implemented any PKI functionality.

ConfigSeeders Keystore functionality might be the right solution for you if

• you are looking for a way to get a better overview of how your certificates are used
• you need a way to create key and trust stores out of existing certificates
• distribute these key and trust stores to the target runtime environment

Outlook

Although the functionality for managing key and trust stores is already very powerful, we are considering to support Kuernetes Secrets of type TLS.

• Manage Kubernetes Secrets of type TLS