Manage Certificate

You can define the CA certificate of your endpoint service using three different ways. If you have the certificate on hand, you can use certificateInline to define it inline. You can also use secretRef or configMapRef fields to read them from a Secret resource or a ConfigMap resource respectively.

Using the certificate data as a inline string

Use spec.tls.certificateInline to define inline certificate string:

apiVersion: dp.wso2.com/v1alpha1
kind: Backend
metadata:
  name: sample-backend
spec:
  protocol: https
  services:
  - host: backend-service
    port: 443
  tls:
    certificateInline: |
        -----BEGIN CERTIFICATE-----
        MIIDQTCCAimgAwIBAgITBmyfz5m/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF
        ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
        b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL
        MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv
        b3QgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJ4gHHKeNXj
        ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM
        9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw
        IFAGbHrQgLKm+a/sRxmPUDgH3KKHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6
        VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJGKLhD+rcdqsq08p8kDi1L
        93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm
        jgSubJrIqg0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
        AYYwHQYDVR0OBBYEFIQYzIU07LwMlJQuCFmcx7IQTgoIMA0GCSqGSIb3DQEBCwUA
        A4IBAQCY8jdaQZChGsV2USggNiMOruYou6r4lK5IpDB/G/wkjUu0yKGX9rbxenDI
        U5PMCCjjmCXPI6T53iHTfIUJrU6adTrCC2qJeHZERxhlbI1Bjjt/msv0tadQ1wUs
        N+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv
        o/ufQJVtMVT8QtPHRh8jrdkPSHCa2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU
        5MsI+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy
        rqXRfboQnoZsG4q5WTP468SQvvG5
        -----END CERTIFICATE-----

Using the certificate data in a Secret

Use spec.tls.secretRef to define certificate data. spec.tls.secretRef.name is the name of the Secret resource and key is the data name which has the certificate data.

apiVersion: dp.wso2.com/v1alpha1
kind: Backend
metadata:
  name: sample-backend
spec:
  protocol: https
  services:
  - host: backend-service
    port: 443
  tls:
    secretRef:
      name: <backend-tls-secret-name>
      key: <backend-tls-secret-data-name>

Using the certificate data in a ConfigMap

Use spec.tls.configMapRef to define certificate data. spec.tls.configMapRef.name is the name of the ConfigMap resource and key is the data name which has the certificate data.

apiVersion: dp.wso2.com/v1alpha1
kind: Backend
metadata:
  name: sample-backend
spec:
  protocol: https
  services:
  - host: backend-service
    port: 443
  tls:
    configMapRef:
      name: <backend-tls-cm-name>
      key: <backend-tls-cm-data-name>

If you have used a combination of above methods for a single Backend, the one with the higherst priority will be picked. The priority order is defined as certificateInline > secretRef > configMapRef, where certificateInline has the highest priority.

Configuring SAN verification of the certificate

SAN verification is enabled by default and it uses the spec.services[*].host as the verifier. If you have a certificate configured in your service that is not same as the above mentioned value, then you can configure it in spec.tls.allowedSANs:

apiVersion: dp.wso2.com/v1alpha1
kind: Backend
metadata:
  name: my-sample-backend
spec:
  protocol: https
  services:
  - host: backend-service
    port: 443
  tls:
    ...
    allowedSANs:
    - "my.site.host.name"