Platform Operator Provided Certificates
The TLS/SSL service plans have either a wildcard certificate that is used for all corresponding service instances or a certificate authority that is used to sign a specific certificate that is extra generated for a service instance. These are provided by the Platform Operator and only one of these options can be used at the same time.
Rotation
This section describes how to rotate server/leaf certificates for any of the a9s Data Services' TLS/SSL service plans. The server/leaf certificates are either automatically or manually rotated.
Please be aware that rotating a server/leaf certificate doesn't require you to re-bind your applications, as the CA certificate remains the same, so the existing bindings remain valid.
As an Application Developer you are not able to rotate:
- The CA of the generated certificates that are provided by the Platform Operator; you can however rotate the generated certificates themselves
- The wildcard certificate provided by the Platform Operator, nor its CA
If you require such rotations, please contact your Platform Operator.
Automatic Certificate Rotation
This is the default rotation for the a9s Data Services' service instances. It takes place when a service instance update is triggered within 30 days of a certificate's expiration date. Our automation detects this upcoming expiration and seamlessly rotates the server/leaf certificate.
cf update-service <service_instance_name> -c '{"<custom_parameter>": <value>}'
Manual Certificate Rotation
There may be situations where you need to rotate a server/leaf certificate, regardless of the remaining "valid time".
For this kind of situation the a9s Data Services provide a custom parameter: force_certificate_rotation, which can be
used as follows:
cf update-service <service_instance_name> -c '{"force_certificate_rotation": true}'
When an update is triggered with the force_certificate_rotation parameter set to true the server/leaf certificate
will be rotated, but the CA certificate will be left intact.