Skip to main content
Version: Develop

TLS/SSL Service Plans

This section describes the usage and configuration of TLS/SSL service plans from the perspective of the Platform Operator. For information from the Application Developer's point of view, please refer to the a9s TLS/SSL Service Plans documentation.

All TLS/SSL service instances use a X.509 certificate in order to encrypt the communication between server and client. These X.509 certificates and their corresponding private keys must be in PKCS#1 format and PEM encoded.

There are three general sources for the certificate of a service instance:

However, to use TLS/SSL service plans the Platform Operator has either to provide a wildcard certificate that is used for all corresponding service instances or a CA that is used to sign a specific certificate that is extra generated for a service instance. Only one of these options can be used at the same time.

Furthermore, please be aware that different services may have special limitations which are described explicitly in the Limitations section.

caution

While the Platform Operator has to decide between a wildcard certificate or a generated certificate, the Application Developer is always able to provide their own certificate for a service instance which always takes precedence over the Platform Operator configured option and cannot be prohibit.

Supported Services​

The following a9s Data Services support TLS/SSL service plans and share a common configuration interface:

Limitations​

Currently, the a9s Data Services do not support service plan upgrades from Non-TLS/SSL to TLS/SSL service plans.

MariaDB Limitations​

MariaDB 10.4 has a pre-defined structure for how it expects the different certificates. While the structure is described in length in the vendors' documentation, for our intents and purposes, this is the most relevant piece of information:

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, you are only able to provide the ca property, which is in turn used to create both the server and client certificates. You learn more about the usage of the ca property in the generated certificates section of our documentation.

caution

Due to this limitation, it is not possible to use a wildcard certificate with the a9s MySQL Data Service, regardless of version. However this is not the case for the a9s MariaDB Data Service, as it uses versions above v10.4.

In consequence, for the a9s MySQL Data Service, the Platform Operator must explicitly provide a CA. For further details, please refer to Generated Certificates documentation.

OpenSearch Limitations​

OpenSearch expects that the certificates' private keys are in the format PKCS#8. This restriction applies when one is using user provided certificates, a wildcard certificate or generated certificates.

You can check the vendor's documentation for more information:

*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by anynines GmbH is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and anynines GmbH.