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:
- A specific user provided certificate
- A generated certificate that is signed by the Certificate Authority (CA) that the Platform Operator configured
- A wildcard certificate that is directly provided by the Platform Operator
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.
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:
- a9s KeyValue
- a9s LogMe2 - See OpenSearch Limitations
- a9s MariaDB
- a9s Messaging
- a9s MongoDB
- a9s MySQL (10.4 only) - See MariaDB Limitations
- a9s PostgreSQL
- a9s Redis (starting from version 6)
- a9s Search - See OpenSearch Limitations
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.
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: