Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE Cloud Application Platform 1.5.2

25 Managing Certificates

This chapter describes the process to deploy SUSE Cloud Application Platform installed with certificates signed by an external Certificate Authority.

25.1 Certificate Characteristics

Ensure the certificates you use have the following characteristics:

  • The certificate is encoded in the PEM format.

  • In order to secure uaa-related traffic, the certificate's Subject Alternative Name (SAN) should include the domains uaa.example.com and *.uaa.example.com, where example.com is replaced with the DOMAIN set in your scf-config-values.yaml.

  • In order to secure scf-related traffic, the certificate's Subject Alternative Name (SAN) should include the domain *.example.com, where example.com is replaced with the DOMAIN in your scf-config-values.yaml.

25.2 Deployment Configuration

Certificates used in SUSE Cloud Application Platform are installed through a configuration file, called scf-config-values.yaml. To specify a certificate, set the value of the certificate and its corresponding private key under the secrets: section.

Note
Note

Note the use of the "|" character which indicates the use of a literal scalar. See the http://yaml.org/spec/1.2/spec.html#id2795688 for more information.

Certificates are installed to the uaa component by setting the values UAA_SERVER_CERT and UAA_SERVER_CERT_KEY. For example:

secrets:
  UAA_SERVER_CERT: |
    -----BEGIN CERTIFICATE-----
    MIIFnzCCA4egAwIBAgICEAMwDQYJKoZIhvcNAQENBQAwXDELMAkGA1UEBhMCQ0Ex
    CzAJBgNVBAgMAkJDMRIwEAYDVQQHDAlWYW5jb3V2ZXIxETAPBgNVBAoMCE15Q2Fw
    T3JnMRkwFwYDVQQDDBBNeUNhcE9yZyBSb290IENBMB4XDTE4MDkxNDIyNDMzNVoX
    ...
    IqhPRKYBFHPw6RxVTjG/ClMsFvOIAO3QsK+MwTRIGVu/MNs0wjMu34B/zApLP+hQ
    3ZxAt/z5Dvdd0y78voCWumXYPfDw9T94B4o58FvzcM0eR3V+nVtahLGD2r+DqJB0
    3xoI
    -----END CERTIFICATE-----

  UAA_SERVER_CERT_KEY: |
    -----BEGIN PRIVATE KEY-----
    MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDhRlcoZAVwUkg0
    sdExkBnPenhLG5FzQM3wm9t4erbSQulKjeFlBa9b0+RH6gbYDHh5+NyiL0L89txO
    JHNRGEmt+4zy+9bY7e2syU18z1orOrgdNq+8QhsSoKHJV2w+0QZkSHTLdWmAetrA
    ...
    ZP5BpgjrT2lGC1ElW/8AFM5TxkkOPMzDCe8HRXPUUw+2YDzyKY1YgkwOMpHlk8Cs
    wPQYJsrcObenRwsGy2+A6NiIg2AVJwHASFG65taoV+1A061P3oPDtyIH/UPhRUoC
    OULPS8fbHefNiSvZTNVKwj8=
    -----END PRIVATE KEY-----

Certificates are installed to the scf component by setting the values ROUTER_SSL_CERT and ROUTER_SSL_CERT_KEY. In addition, set UAA_CA_CERT with the root certificate of the Certificate Authority used to sign your certificate. For example:

secrets:
  ROUTER_SSL_CERT: |
    -----BEGIN CERTIFICATE-----
    MIIEEjCCAfoCCQCWC4NErLzy3jANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJD
    QTETMBEGA1UECAwKU29tZS1TdGF0ZTEOMAwGA1UECgwFTXlPcmcxEjAQBgNVBAMM
    CU15Q0Euc2l0ZTAeFw0xODA5MDYxNzA1MTRaFw0yMDAxMTkxNzA1MTRaMFAxCzAJ
    ...
    xtNNDwl2rnA+U0Q48uZIPSy6UzSmiNaP3PDR+cOak/mV8s1/7oUXM5ivqkz8pEJo
    M3KrIxZ7+MbdTvDOh8lQplvFTeGgjmUDd587Gs4JsormqOsGwKd1BLzQbGELryV9
    1usMOVbUuL8mSKVvgqhbz7vJlW1+zwmrpMV3qgTMoHoJWGx2n5g=
    -----END CERTIFICATE-----

  ROUTER_SSL_CERT_KEY: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIEpAIBAAKCAQEAm4JMchGSqbZuqc4LdryJpX2HnarWPOW0hUkm60DL53f6ehPK
    T5Dtb2s+CoDX9A0iTjGZWRD7WwjpiiuXUcyszm8y9bJjP3sIcTnHWSgL/6Bb3KN5
    G5D8GHz7eMYkZBviFvygCqEs1hmfGCVNtgiTbAwgBTNsrmyx2NygnF5uy4KlkgwI
    ...
    GORpbQKBgQDB1/nLPjKxBqJmZ/JymBl6iBnhIgVkuUMuvmqES2nqqMI+r60EAKpX
    M5CD+pq71TuBtbo9hbjy5Buh0+QSIbJaNIOdJxU7idEf200+4anzdaipyCWXdZU+
    MPdJf40awgSWpGdiSv6hoj0AOm+lf4AsH6yAqw/eIHXNzhWLRvnqgA==
    -----END RSA PRIVATE KEY----

  UAA_CA_CERT: |
    -----BEGIN CERTIFICATE-----
    MIIDaSjCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
    MTQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
    DkITVCBSb290IENBIFg7MB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
    ...
    R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
    NvaEkqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
    NTQVZRzI9neWagqNdwvYkQsEjgfbKbYK7p2MEIAL
    -----END CERTIFICATE-----

25.2.1 Configuring Multiple Certificates

Cloud Application Platform supports configurations that use multiple certificates. To specify multiple certificates with their associated keys, replace the ROUTER_SSL_CERT and ROUTER_SSL_CERT_KEY properties with the ROUTER_TLS_PEM property in your scf-config-values.yaml file.

secrets:
  ROUTER_TLS_PEM: |
    - cert_chain: |
        -----BEGIN CERTIFICATE-----
        MIIEDzCCAfcCCQCWC4NErLzy9DANBgkqhkiG9w0BAQsFADBGMQswCQYDVQQGEwJD
        QTETMBEGA1UECAwKU29tZS1TdGF0ZTEOMAwGA1UECgwFTXlPcmcxEjAQBgNVBAMM
        opR9hW2YNrMYQYfhVu4KTkpXIr4iBrt2L+aq2Rk4NBaprH+0X6CPlYg+3edC7Jc+
	...
        ooXNKOrpbSUncflZYrAfYiBfnZGIC99EaXShRdavStKJukLZqb3iHBZWNLYnugGh
        jyoKpGgceU1lwcUkUeRIOXI8qs6jCqsePM6vak3EO5rSiMpXMvLO8WMaWsXEfcBL
        dglVTMCit9ORAbVZryXk8Xxiham83SjG+fOVO4pd0R8UuCE=
        -----END CERTIFICATE-----
      private_key: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEpAIBAAKCAQEA0HZ/aF64ITOrwtzlRlDkxf0b4V6MFaaTx/9UIQKQZLKT0d7u
        3Rz+egrsZ90Jk683Oz9fUZKtgMXt72CMYUn13TTYwnh5fJrDM1JXx6yHJyiIp0rf
        3G6wh4zzgBosIFiadWPQgL4iAJxmP14KMg4z7tNERu6VXa+0OnYT0DBrf5IJhbn6
	...
        ja0CsQKBgQCNrhKuxLgmQKp409y36Lh4VtIgT400jFOsMWFH1hTtODTgZ/AOnBZd
        bYFffmdjVxBPl4wEdVSXHEBrokIw+Z+ZhI2jf2jJkge9vsSPqX5cTd2X146sMUSy
        o+J1ZbzMp423AvWB7imsPTA+t9vfYPSlf+Is0MhBsnGE7XL4fAcVFQ==
        -----END RSA PRIVATE KEY-----
    - cert_chain: |
        -----BEGIN CERTIFICATE-----
        MIIEPzCCAiegAwIBAgIJAJYLg0SsvPL1MA0GCSqGSIb3DQEBCwUAMEYxCzAJBgNV
        BAYTAkNBMRMwEQYDVQQIDApTb21lLVN0YXRlMQ4wDAYDVQQKDAVNeU9yZzESMBAG
        A1UEAwwJTXlDQS5zaXRlMB4XDTE4MDkxNzE1MjQyMVoXDTIwMDEzMDE1MjQyMVow
	...
        FXrgM9jVBGXeL7T/DNfJp5QfRnrQq1/NFWafjORXEo9EPbAGVbPh8LiaEqwraR/K
        cDuNI7supZ33I82VOrI4+5mSMxj+jzSGd2fRAvWEo8E+MpHSpHJt6trGa5ON57vV
        duCWD+f1swpuuzW+rNinrNZZxUQ77j9Vk4oUeVUfL91ZK4k=
        -----END CERTIFICATE-----
      private_key: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEA5kNN9ZZK/UssdUeYSajG6xFcjyJDhnPvVHYA0VtgVOq8S/rb
        irVvkI1s00rj+WypHqP4+l/0dDHTiclOpUU5c3pn3vbGaaSGyonOyr5Cbx1X+JZ5
        17b+ah+oEnI5pUDn7chGI1rk56UI5oV1Qps0+bYTetEYTE1DVjGOHl5ERMv2QqZM
	...
        rMMhAoGBAMmge/JWThffCaponeakJu63DHKz87e2qxcqu25fbo9il1ZpllOD61Zi
        xd0GATICOuPeOUoVUjSuiMtS7B5zjWnmk5+siGeXF1SNJCZ9spgp9rWA/dXqXJRi
        55w7eGyYZSmOg6I7eWvpYpkRll4iFVApMt6KPM72XlyhQOigbGdJ
        -----END RSA PRIVATE KEY-----

25.3 Deploying SUSE Cloud Application Platform with Certificates

Once the certificate-related values have been set in your scf-config-values.yaml, deploy SUSE Cloud Application Platform.

Note
Note: Embedded uaa in scf

The User Account and Authentication (uaa) Server is included as an optional feature of the scf Helm chart. This simplifies the Cloud Application Platform deployment process as a separate installation and/or upgrade of uaa is no longer a prerequisite to installing and/or upgrading scf.

It is important to note that:

  • This feature should only be used when uaa is not shared with other projects.

  • You cannot migrate from an existing external uaa to an embedded one. In this situation, enabling this feature during an upgrade will result in a single admin account.

To enable this feature, add the following to your scf-config-values.yaml.

enable:
  uaa: true

When deploying and/or upgrading scf, run helm install and/or helm upgrade and note that:

  • Installing and/or upgrading uaa using helm install suse/uaa ... and/or helm upgrade is no longer required.

  • It is no longer necessary to set the UAA_CA_CERT parameter. Previously, this parameter was passed the CA_CERT variable, which was assigned the CA certificate of uaa.

If this is an initial deployment, use helm install to deploy uaa and scf:

  1. Deploy uaa:

    tux > helm install suse/uaa \
    --name susecf-uaa \
    --namespace uaa \
    --values scf-config-values.yaml

    Wait until you have a successful uaa deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace uaa'

    When uaa is successfully deployed, the following is observed:

    • For the secret-generation pod, the STATUS is Completed and the READY column is at 0/1.

    • All other pods have a Running STATUS and a READY value of n/n.

    Press CtrlC to exit the watch command.

  2. Deploy scf:

    Note
    Note: Setting UAA_CA_CERT

    Starting with SUSE Cloud Application Platform 1.5.2, you no longer need to set UAA_CA_CERT when using an external UAA with a certificate signed by a well known Certificate Authority (CA). It is only needed when you use an external UAA with either a certificate generated by the secret-generator or a self-signed certificate.

    If you need to set UAA_CA_CERT:

    1. Obtain your UAA secret and certificate:

      tux > SECRET=$(kubectl get pods --namespace uaa \
      --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
      
      tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
      --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
    2. Then pass --set "secrets.UAA_CA_CERT=${CA_CERT}" as part of your helm command.

    tux > helm install suse/cf \
    --name susecf-scf \
    --namespace scf \
    --values scf-config-values.yaml

    Wait until you have a successful scf deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace scf'

    When scf is successfully deployed, the following is observed:

    • For the secret-generation and post-deployment-setup pods, the STATUS is Completed and the READY column is at 0/1.

    • All other pods have a Running STATUS and a READY value of n/n.

    Press CtrlC to exit the watch command.

If this is an existing deployment, use helm upgrade to apply the changes to uaa and scf:

  1. Upgrade uaa:

    tux > helm upgrade susecf-uaa suse/uaa \
    --values scf-config-values.yaml \
    --version 2.20.3
  2. Wait until you have a successful uaa deployment before going to the next steps, which you can monitor with the watch command:

    tux > watch --color 'kubectl get pods --namespace uaa'
  3. Pass your uaa secret and certificate to scf:

    tux > SECRET=$(kubectl get pods --namespace uaa \
    --output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')
    
    tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
    --output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"
  4. Upgrade scf:

    tux > helm upgrade susecf-scf suse/cf \
    --values scf-config-values.yaml \
    --set "secrets.UAA_CA_CERT=${CA_CERT}" \
    --version 2.20.3
  5. Monitor the deployment progress using the watch command:

    tux > watch --color 'kubectl get pods --namespace scf'

Once all pods are up and running, verify you can successfully set your cluster as the target API endpoint by running the cf api command without using the --skip-ssl-validation option.

tux > cf api https://api.example.com

25.4 Rotating Automatically Generated Secrets

Cloud Application Platform uses a number of automatically generated secrets for use internally. These secrets have a default expiration of 10950 days and are set through the CERT_EXPIRATION property in the env: section of the scf-config-values.yaml file. If rotation of the secrets is required, increment the value of secrets_generation_counter in the kube: section of the scf-config-values.yaml configuration file (for example the example scf-config-values.yaml used in this guide) then run helm upgrade.

This example demonstrates rotating the secrets of the scf deployment.

First, update the scf-config-values.yaml file.

kube:
  # Increment this counter to rotate all generated secrets
  secrets_generation_counter: 2

Next, perform a helm upgrade to apply the change.

tux > SECRET=$(kubectl get pods --namespace uaa \
--output jsonpath='{.items[?(.metadata.name=="uaa-0")].spec.containers[?(.name=="uaa")].env[?(.name=="INTERNAL_CA_CERT")].valueFrom.secretKeyRef.name}')

tux > CA_CERT="$(kubectl get secret $SECRET --namespace uaa \
--output jsonpath="{.data['internal-ca-cert']}" | base64 --decode -)"

tux > helm upgrade susecf-scf suse/cf \
--values scf-config-values.yaml --set "secrets.UAA_CA_CERT=${CA_CERT}" \
--version 2.20.3

25.5 Difference between TRUSTED_CERTS and ROOTFS_TRUSTED_CERTS

The TRUSTED_CERTS parameter contains a list of CA certificates which become available in application instance containers as files in the directory /etc/cf-system-certificates and the general trust store (Only cflinuxfs3). The environment variable CF_SYSTEM_CERT_PATH holds the first path. No difference between applications from buildpacks and from Docker images.

The ROOT_TRUSTED_CERTS parameter contains a list of CA certificates which are available in application instance containers through the general OS trust store. Only applications based on buildpacks (and a rootfs) receive the information.

Summary

  • Both contain additional CA certificates for applications.

  • ROOTFS_TRUSTED_CERTS only applies to applications based on buildpacks and rootfs and are automatically available through the OS trust store.

  • TRUSTED_CERTS applies to all applications, based on both buildpacks and Docker images. Not automatically available. Applications have to use the environment variable CF_SYSTEM_CERT_PATH and add the certificates themselves.

Print this page