Skip to main content
Version: 31.0.0

Common SSL/TLS configuration

Supported Services

The following data services support SSL/TLS plans and share a common configuration interface for x509 certificates:

  • Elasticsearch
  • Harbor
  • MongoDB
  • PostgreSQL
  • RabbitMQ
  • MySQL (10.4 only) - See Restrictions

SSL/TLS Certificates

An x509 certificate for SSL service instances can be deployed in several ways. The following list is specified in order of preference, so that - if specified - a "user provided certificate" will be used before a "configured wildcard certificate". In other words, if a user has specified a certificate for a particular SSL service instance, they have to delete the certificate before another certificate can be deployed to the service instance.

Certificate Usage Order

  1. User provided certificate
  2. Configured wildcard certificate
  3. Generated certificate with a configured intermediate certificate
  4. Self-signed certificate

User Provided Certificates

The user can provide their own certificate as a parameter in the call to cf create-service or cf update-service. See app developer documentation.

Wildcard Certificate

A platform operator can define wildcard certificates in a deployment manifest (e.g. rabbitmq-service.yml). These are used when the user doesn't provide their own certificates (see User Provided Certificates).

...
properties:
...
rabbitmq-spi:
wildcard:
ca: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
key: |
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

NOTE Please note that the supplied key must not be encrypted! If your intermediate CA's key is encryped with a password, please provide the decrypted version of the key. If you supply an encrypted key, you should see an error message similar to this:

$ cf create-service a9s-messaging310 rabbitmq-single-small-ssl rabbitmq1
Creating service instance rabbitmq1 in org test / space test as admin...
Service broker error: Neither PUB key nor PRIV key: nested asn1 error
FAILED

TLS Certificate Creation

A data service can either create self signed certificates or create certificates derived from an intermediate certificate. For the latter the customer has to configure an intermediate certificate with their private key.

...
properties:
...
rabbitmq-spi:
intermediate-ca:
cert: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
key: |
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----

NOTE Please note that the supplied key must not be encrypted! (see above)

Self-signed Certificate

A supported data service instance using an SSL plan will create its own self-signed certificate, if no user leaf certificates or certificate authorities have been supplied.

Restrictions for MySQL 10.4

MySQL 10.4 has a pre-defined structure how it expects the different certificates. This structure is described in the vendors documentation:

These are the most important parts that we want to highlight:

There are three certificates that you need to create in order to secure Galera Cluster: the Certificate Authority (CA) key and cert; the server certificate, to secure mysqld activity and replication traffic; and the client certificate to secure the database client and stunnel for state snapshot transfers.

Due to the nature of our automation, one is only able to provide the intermediate-ca property which is used to create the server and client certificates. How to use the intermediate-ca property is explained here.

Please also ensure that the given intermediate-ca certificate is in the VMs trust store(s). The certificate can be distributed, for example, via the BOSH director.