Rotating Certificates

Page last updated:

This topic describes how to check the expiration date of and rotate certificate authorities (CAs) and leaf certificates in Ops Manager.

This includes the Ops Manager root CA, BOSH NATS CA, BOSH DNS CA, the Diego root CA, and other CAs and leaf certificates stored in Ops Manager and CredHub that are visible to the Ops Manager API.

Warning: The rotation procedures described in this topic do not work if the certificates have already expired. If the certificates have expired, contact Support for guidance.

For information about rotating IPsec certificates, see Rotating IPsec Certificates.

For information about using trusted third-party certificates for both apps hosted on Ops Manager and internal Ops Manager components, see Setting Trusted Certificates.

For information about how to rotate certificates managed by CredHub, including the Services TLS CA (/services/tls_ca), see Advanced Certificate Rotation with CredHub Maestro.

Overview

The Ops Manager API manages and lists internal CAs and leaf certificates that enable Ops Manager components to communicate with each other securely using TLS. It can also list certificates used externally, such as SAML certificates that authenticate to an external identity provider (IDP).

For more information about the CAs and leaf certificates visible to the Ops Manager API, see Certificate Types.

Rotate CAs and leaf certificates before they expire to avoid downtime for your foundation. To rotate certificates in Ops Manager, first check the expiration dates of all certificates. Then, based on the types of certificates that expire soon, follow a certificate rotation procedure to replace expiring certificates and deploy BOSH to apply changes.

Prerequisites

Before you rotate certificates in Ops Manager v2.9:

  • You must reset any certificates that were manually set in CredHub on Ops Manager v2.6 and earlier to prevent them from being rotated with other certificates generated by CredHub. To find and reset any manually set certificates in CredHub, see Reviewing Manually Set Certificates in CredHub.

  • You must have both Ops Manager v2.9 and VMware Tanzu Application Service for VMs (TAS for VMs) v2.9 or later to rotate CredHub-managed certificates with this procedure. If you have a version of TAS for VMs earlier than v2.9, you can follow this procedure to rotate certificates managed by Ops Manager. Then, to rotate certificates managed in CredHub, see Advanced Certificate Rotation with CredHub Maestro.

  • You cannot have VMware Enterprise PKS (PKS) installed to rotate CredHub-managed certificates with this procedure. If you have PKS, you can follow this procedure to rotate certificates managed by Ops Manager. Then, to rotate certificates managed in CredHub, see Advanced Certificate Rotation with CredHub Maestro.

Check Expiration Dates and Certificate Types

This section describes how to manually check the expiration dates of the CAs and leaf certificates that the Ops Manager API lists and manages. It also explains how to identify the types of certificates that require manual rotation.

To configure Concourse to automatically monitor expiring certificates, you can use Platform Automation. For more information, see expiring-certificates in the Platform Automation documentation.

After identifying the types of certificates that expire soon, you can determine which certificate rotation procedure to follow.

To check certificate expiration dates and types:

  1. Follow the procedure in Using Ops Manager API to target and authenticate with the Ops Manager User Account and Authentication (UAA) server. Record your Ops Manager access token, and use it for UAA-ACCESS-TOKEN in the steps below.

    Note: When you record your Ops Manager access token, remove any newline characters such as \n.

  2. To retrieve the certificates, use curl to call the /deployed/certificates endpoint of the Ops Manager API. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/deployed/certificates" \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN"
    

    Where:

    • OPS-MANAGER-FQDN is the fully-qualified domain name (FQDN) of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is the access_token value you recorded in the previous step.

      More options:
      • To limit command output to certificates that expire within a given time interval, append ?expires_within=TIME to the endpoint, replacing TIME with an integer-letter code.
        • Valid letter codes are d for days, w for weeks, m for months, and y for years. For example, querying to https://OPS-MANAGER-FQDN/api/v0/deployed/certificates?expires_within=6m searches for certificates expiring within six months.
      • To make the JSON output more readable, you can pipe your curl command to jq or another text editor with JSON formatting.
  3. The deployed/certificates output lists all CAs and leaf certificates visible to the Ops Manager API, whether they are stored in Ops Manager directly or stored in CredHub. To determine the expiration date and type for each certificate listed:

    1. Determine the expiration date from the valid_until value. For example, the root CA listed below expires on August 12, 2020:
      {
      "configurable": true,
      "is_ca": true,
      "property_reference": ".properties.root_ca.fb10484dd5541a273c9d",
      "property_type": "rsa_cert_credentials",
      "product_guid": "ops_manager",
      "location": "ops_manager",
      "variable_path": null,
      "issuer": "/CN=ToolsmithsCA",
      "valid_from": "2019-08-13T15:30:22Z",
      "valid_until": "2020-08-12T15:30:22Z"
      },
      
    2. For any certificates expiring soon, use the following rules to identify their types:
      • Non-rotatable certificates: Non-rotatable certificates have the following property value:
        • variable_path matches /p-bosh/service-instance_*/pxc_*, /p-bosh/service-instance_*/tls_certificate, or /p-bosh/service-instance_*/redis_certificate
      • Non-configurable certificates: Non-configurable leaf certificates have the following property values:
        • configurable is false.
        • location is either ops_manager or credhub.
        • is_ca is false.
      • Configurable certificates: Configurable leaf certificates have the following property values:
        • configurable is true.
        • is_ca is false.
      • CAs: CAs have the following property values:
        • is_ca is true.
        • location is ops_manager or credhub.
  4. After you identify the list of certificates that expire soon, complete the Rotate Certificates procedure below.

Rotate Certificates

This section explains how to rotate certificates in Ops Manager, including the Ops Manager root CA, BOSH NATS CA, CAs stored in CredHub, and leaf certificates. There are different rotation procedures for each type of certificate that requires rotation.

You can determine which rotation procedure to follow based on the types of certificates in your foundation that must be rotated.

To rotate certificates, follow one of these procedures:

Rotate CAs and Leaf Certificates

Warning: The Services CA, /services/tls_ca, cannot be rotated using this procedure. For Services CA rotation instructions, see Managing Certificates (pre-Maestro) in the VMware Tanzu GemFire documentation.

This procedure uses the Ops Manager API to rotate the Ops Manager root CA and non-configurable leaf certificates. When you rotate the Ops Manager root CA, the Ops Manager API automatically rotates the BOSH NATS CA.

If you used the Generate RSA Certificate feature to rotate the configurable certificates, this procedure instructs you to rotate the configurable leaf certificates by regenerating them.

To prevent system downtime, this procedure includes two BOSH deploys. The first BOSH deploy applies new certificates to Ops Manager components. The second BOSH deploy deletes the old certificates.

Note: The names of the Recreate all service instances and the Upgrade all service instances errands may be slightly different between services.

Warning: You must complete these steps in the exact order specified. Otherwise, you may damage your deployment.

To rotate CAs, configurable leaf certificates and non-configurable leaf certificates:

  1. Add a new Ops Manager root CA. This step also automatically adds new CAs for all CAs visible to the Ops Manager API. For more information, see Step 1: Add New CAs.

  2. Activate the Ops Manager root CA. This step also automatically activates any other new CAs added in the previous step. For more information, see Step 2: Activate the CAs.

  3. Rotate configurable leaf certificates. For more information, see Step 3: Rotate Configurable Leaf Certificates.

  4. Rotate non-configurable leaf certificates. For more information, see Step 4: Rotate Non-Configurable Leaf Certificates from the New CAs.

  5. Delete the old root CA and mark the old CAs in CredHub as inactive. For more information, see Step 5: Delete the Old Root CA and Mark Old CAs in CredHub as Inactive.

Step 1: Add New CAs

This section describes how to add a new root CA for Ops Manager. The new root CA can be an Ops Manager-generated CA or your own custom CA.

This procedure also automatically regenerates the BOSH NATS CA as well as CAs stored in CredHub, such as the BOSH DNS CA and the Diego root CA.

Warning:The CAs for certain versions of the MySQL, Redis, RabbitMQ, and VMware Tanzu GemFire tiles are also excluded from rotation. See the tile-specific documentation for information about rotating these CAs.

To add new CAs:

  1. If you have not already done so, follow the procedure in Using Ops Manager API to target and authenticate with the Ops Manager UAA server. Record your Ops Manager access token, and use it for UAA-ACCESS-TOKEN in the following steps.

    Note: When you record your Ops Manager access token, remove any newline characters such as \n.

  2. Use Ops Manager to generate a new CA, or add your own custom CA:

    Note: Elliptic Curve Digital Signature Algorithm (ECDSA) certificates are not supported in Ops Manager.

    • To use your own custom CA: Call the Ops Manager API certificate_authorities endpoint. Run:

      curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities" \
          -X POST \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN" \
          -H "Content-Type: application/json" \
          -d '{"cert_pem": "-----BEGIN CERTIFICATE-----\CUSTOM-CERTIFICATE", "private_key_pem": "-----BEGIN RSA PRIVATE KEY-----\RSA-KEY"}'
      

      Where:

      • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
      • CUSTOM-CERTIFICATE is your custom CA.
      • RSA-KEY is your RSA key.
      • UAA-ACCESS-TOKEN is your UAA access token.

        If the command succeeds, the API returns a response that includes the new CA certificate. For example:
        HTTP/1.1 200 OK
        {
        "certificate_authorities": [
          {
            "guid": "f7bc18f34f2a7a9403c3",
            "issuer": "YOUR-CA",
            "created_on": "2017-01-09",
            "expires_on": "2021-01-09",
            "active": true,
            "cert_pem": "-----BEGIN CERTIFICATE-----\nMIIC+zCCAeOgAwIBAgI....etc"
          }
        ]
        }
        
    • To use an Ops Manager-generated CA: Call the Ops Manager API generate endpoint. Run:

      curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities/generate" \
            -X POST \
            -H "Authorization: Bearer UAA-ACCESS-TOKEN" \
            -H "Content-Type: application/json" \
            -d '{}'
      

      Where:

      • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
      • UAA-ACCESS-TOKEN is your UAA access token.

        If the command succeeds, the API returns a response that includes the new CA certificate. For example:
        HTTP/1.1 200 OK
        {
        "guid": "f7bc18f34f2a7a9403c3",
        "issuer": "VMware",
        "created_on": "2017-01-19",
        "expires_on": "2021-01-19",
        "active": false,
        "cert_pem": "-----BEGIN EXAMPLE CERTIFICATE-----
        MIIC+zCCAeOgAwIBAgIBADANBgkqhkiG9w0BAQsFADAfMQswCQYDVQQGEwJVUzEQ
        EXAMPLEoCgwHUGl2b3RhbDAeFw0xNDarthgyMTQyMjVaFw0yMTAxMTkyMTQyMjVa
        EXAMPLEoBgNVBAYTAlVTMRAwDgYDVVaderdQaXZvdGFsMIIBIjANBgkqhkiG9w0B
        EXAMPLEoAQ8AMIIBCgKCAQEAyV4OhPIIZTEym9OcdcNVip9Ev0ijPPLo9WPLUMzT
        EXAMPLEo/TgD+DP09mwVXfqwBlJmoj9DqRED1x/6bc0Ki/BAFo/P4MmOKm3QnDCt
        EXAMPLEooqgA++2HYrNTKWJ5fsXmERs8lK9AXXT7RKXhktyWWU3oNGf7zo0e3YKp
        EXAMPLEoh1NwIbNcGT1AurIDsxyOZy1HVzBLTisMyDogJmSCLsOw3qUDQjatjXKw
        EXAMPLEojG3nv2hvD4/aTOiHuKM3+AGbnaS2MdIOvFOh/7Y79tUp89csK0gs6uOd
        EXAMPLEohe4DcKw5CzUTfHKNXgHyeoVOBPcVQTp4lJp1iQIDAQABo0IwQDAdBgNV
        EXAMPLEoyH4y7VEuImLStXM0CKR8uVqxX/gwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
        EXAMPLEoBAMCAQYwDQYJKoZIhvcNAQELBQADggEBALmHOPxdyBGnuR0HgR9V4TwJ
        EXAMPLEoGLKVT7am5z6G2Oq5cwACFHWAFfrPG4W9Jm577QtewiY/Rad/PbkY0YSY
        EXAMPLEokrfNjxjxI0H2sr7qLBFjJ0wBZHhVmDsO6A9PkfAPu4eJvqRMuL/xGmSQ
        EXAMPLEoCynMNz7FgHyFbd9D9X5YW8fWGSeVBPPikcONdRvjw9aEeAtbGEh8eZCP
        EXAMPLEob33RuR+CTNqThXY9k8d7/7ba4KVdd4gP8ynFgwvnDQOjcJZ6Go5QY5HA
        EXAMPLEoPFW8pAYcvWrXKR0rE8fL5o9qgTyjmO+5yyyvWIYrKPqqIUIvMCdNr84=
          -----END EXAMPLE CERTIFICATE-----
          "
        
  3. Confirm that the new CA is added by listing all the root CAs for Ops Manager by running:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities" \
          -X GET \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN"
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is your UAA access token.

      The API call returns the GUID of the newly added CA. For example:
      HTTP/1.1 200 OK
      {
      "certificate_authorities": [
        {
          "guid": "f7bc18f34f2a7a9403c3",
          "issuer": "VMware",
          "created_on": "2017-01-09",
          "expires_on": "2021-01-09",
          "active": true,
          "cert_pem": "-----BEGIN CERTIFICATE-----\nMIIC+zCCAeOgAwIBAgI....etc"
        }
        {
          "guid": "a8ee01e33e3e3e3303e3",
          "issuer": "VMware",
          "created_on": "2017-04-09",
          "expires_on": "2021-04-09",
          "active": false,
          "cert_pem": "-----BEGIN CERTIFICATE-----\nzBBBC+eAAAe1gAwAAAeZ....etc"
        }
      ]
      }
      
  4. Identify the newly added CA, which has active set to false. Record its GUID.

  5. Navigate to https://OPS-MANAGER-FQDN in a browser, where OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.

  6. Log in to Ops Manager.

  7. Click the BOSH Director tile.

  8. Select Director Config.

  9. Enable the Recreate VMs deployed by the BOSH Director checkbox. This propagates the new CA to all VMs deployed by the BOSH Director to prevent downtime.

  10. Return to the Ops Manager Installation Dashboard.

  11. If you have service tiles installed, for each service tile:

    1. Click the tile.
    2. Click the Errands tab.
    3. Enable the Upgrade all service instances errand. Running this errand is necessary to push CredHub certificate updates to each service instance.
    4. If the service tile has the Recreate all service instances errand:
      1. Enable the Recreate all service instances errand. Running this errand pushes BOSH agent certificate updates to service instances.
      2. Click Review Pending Changes.
      3. Click Apply Changes.
    5. If the service tile does not have the Recreate all service instances errand:

      1. Click Review Pending Changes.
      2. Click Apply Changes.
      3. When the deploy finishes, manually push BOSH agent certificate updates to each service instance. For each service instance, run:

        bosh -d SERVICE-INSTANCE-DEPLOYMENT recreate
        

        Where SERVICE-INSTANCE-DEPLOYMENT is the BOSH deployment name for the service instance.

  12. If you do not have any service tiles installed:

    1. Click Review Pending Changes.
    2. Click Apply Changes.
  13. When the deploy finishes and you have completed all necessary tasks to update service instances, continue to the next section, Step 2: Activate the CAs.

Step 2: Activate the CAs

To activate the CAs that you added in Step 1: Add New CAs:

  1. Make an Ops Manager API call that activates the new CAs. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities/CERTIFICATE-GUID/activate" \
      -X POST \
      -H "Authorization: Bearer UAA-ACCESS-TOKEN" \
      -H "Content-Type: application/json" \
      -d '{}'
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • CERTIFICATE-GUID is the GUID of your CA that you retrieved in the previous section.
    • UAA-ACCESS-TOKEN is your UAA access token.

      The API returns a successful response:
      HTTP/1.1 200 OK
  2. List your CAs to confirm that the new Ops Manager root CA is active. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities" \
          -X GET \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN"
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is your UAA access token.
  3. Examine the response to ensure that your new CA has the active property set to true.

Step 3: Rotate Configurable Leaf Certificates

Any configurable certificates generated from the Ops Manager root CA must be rotated. These are the certificates that you generated using Generate RSA Certificate in the Ops Manager UI. For example, see Providing a Certificate for Your TLS Termination Point.

To regenerate and rotate configurable leaf certificates, do the following for each configurable certificate that expires soon:

  1. Find the text field where the certificate is configured within the Ops Manager interface. You might need to look through multiple configuration panes to identify the location of the certificate configuration text field. Use the following fields to identify the location of the certificate configuration text field:

    • The product_guid field in the Ops Manager API output can help identify in which tile the certificate is configured. For example, the prefix p-bosh- refers to the BOSH Director tile, and the prefix cf- refers to the VMware Tanzu Application Service for VMs (TAS for VMs) tile.
    • The property_reference field in the API output can help identify in which Settings pane the certificate is configured. For example, the uaa.service_provider_key_credentials property is configured in the UAA pane of the TAS for VMs tile.
  2. Copy a new value for the certificate into the text field or generate a new certificate using the Generate RSA Certificate button.

  3. Click Save at the bottom of each pane in which you added new certificates.

Step 4: Rotate Non-Configurable Leaf Certificates from the New CAs

After activating the new Ops Manager root CA and other CAs, you must rotate non-configurable leaf certificates from the new CAs.

Warning:The CAs for certain versions of the MySQL, Redis, RabbitMQ, and VMware Tanzu GemFire tiles are also excluded from rotation. See the tile-specific documentation for information about rotating these CAs.

To rotate non-configurable leaf certificates:

  1. Make a call to the Ops Manager API to regenerate all non-configurable certificates and apply the new root CA to your existing BOSH Director. Run:

      curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities/active/regenerate" \
            -X POST \
            -H "Authorization: Bearer UAA-ACCESS-TOKEN" \
            -H "Content-Type: application/json" \
            -d '{}'
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is your UAA access token.

      The API returns a successful response:
      HTTP/1.1 200 OK
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click the BOSH Director tile.

  4. Select Director Config.

  5. Enable the Recreate VMs deployed by the BOSH Director checkbox. This propagates the new CAs to all VMs deployed by the BOSH Director to prevent downtime.

  6. Return to the Ops Manager Installation Dashboard.

  7. If you have service tiles installed, for each service tile:

    1. Click the tile.
    2. Click the Errands tab.
    3. Enable the Upgrade all service instances errand. Running this errand is necessary to push CredHub certificate updates to each service instance.
    4. If the service tile has the Recreate all service instances errand:
      1. Enable the Recreate all service instances errand. Running this errand pushes BOSH agent certificate updates to service instances.
      2. Click Review Pending Changes.
      3. Click Apply Changes to perform a second deploy.
    5. If the service tile does not have the Recreate all service instances errand:

      1. Click Review Pending Changes.
      2. Click Apply Changes to perform a second deploy.
      3. When the deploy finishes, manually push BOSH agent certificate updates to each service instance. For each service instance, run:

        bosh -d SERVICE-INSTANCE-DEPLOYMENT recreate
        

        Where SERVICE-INSTANCE-DEPLOYMENT is the BOSH deployment name for the service instance.

  8. If you do not have any service tiles installed:

    1. Click Review Pending Changes.
    2. Click Apply Changes to perform a second deploy.
  9. When the deploy finishes and you have completed all necessary tasks to update service instances, continue to the next section, Step 5: Delete the Old Root CA and Mark Old CAs in CredHub as Inactive.

Step 5: Delete the Old Root CA and Mark Old CAs in CredHub as Inactive

After activating new CAs and rotating leaf certificates from the new CAs, you must:

  • Delete the old Ops Manager root CA from your foundation.
  • Mark the old CAs stored in CredHub as inactive.

Within CredHub, the leaf certificates that are generated when you rotate your foundation’s root CA are associated with both the new and old versions of the root CA. Deleting the old root CA ensures that these leaf certificates are only associated with the new root CA.

The Ops Manager API call you use to delete your foundation’s old root CA also marks the old versions of all CAs stored in CredHub as inactive, including those not generated by the old root CA.

Note: This procedure does not delete leaf certificates stored in CredHub. It marks CredHub leaf certificates as transitional, which indicates that the leaf certificate is inactive. To delete CredHub leaf certificates, use the CredHub Maestro garbage collection feature. For information about CredHub Maestro certificate garbage collection, see Delete Inactive Certificate Versions in Advanced Certificate Rotation with CredHub Maestro.

Warning: Before you delete the old CA, ensure that you reviewed the Review Pending Changes page and clicked Apply Changes as part of Step 4: Rotate Non-Configurable Leaf Certificates from the New CAs.

To delete the old Ops Manager root CA and mark the old CredHub CAs as inactive:

  1. List your root CAs to retrieve the GUID of the old, inactive Ops Manager root CA. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities" \
          -X GET \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN"
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is your UAA access token.
  2. Use curl to make an API call to delete the old Ops Manager root CA. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities/OLD-CERTIFICATE-GUID" \
          -X DELETE \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN"
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • OLD-CERTIFICATE-GUID is the GUID of the old Ops Manager root CA.
    • UAA-ACCESS-TOKEN is your UAA access token.

      The API returns a successful response:
      HTTP/1.1 200 OK
  3. Navigate to the Ops Manager Installation Dashboard.

  4. Click the BOSH Director tile.

  5. Select Director Config.

  6. Enable the Recreate VMs deployed by the BOSH Director checkbox.

  7. Navigate to the Ops Manager Installation Dashboard.

  8. If you have service tiles installed, for each service tile:

    1. Click the tile.
    2. Click the Errands tab.
    3. Enable the Upgrade all service instances errand. Running this errand is necessary to push CredHub certificate updates to each service instance.
    4. If the service tile has the Recreate all service instances errand:
      1. Enable the Recreate all service instances errand. Running this errand pushes BOSH agent certificate updates to service instances.
      2. Click Review Pending Changes.
      3. Click Apply Changes.
    5. If the service tile does not have the Recreate all service instances errand:

      1. Click Review Pending Changes.
      2. Click Apply Changes.
      3. When the deploy finishes, manually push BOSH agent certificate updates to each service instance. For each service instance, run:

        bosh -d SERVICE-INSTANCE-DEPLOYMENT recreate
        

        Where SERVICE-INSTANCE-DEPLOYMENT is the BOSH deployment name for the service instance.

  9. If you do not have any service tiles installed:

    1. Click Review Pending Changes.
    2. Click Apply Changes.

Rotate Non-Configurable Leaf Certificates

This procedure rotates non-configurable leaf certificates visible to the Ops Manager API, whether they are managed and stored by Ops Manager directly, or by CredHub at Ops Manager request.

Warning: This procedure does not rotate the Ops Manager root CA or other CAs managed by Ops Manager or CredHub. To rotate both the root CA and non-configurable leaf certificates, see Rotate CAs and Leaf Certificates.

To rotate non-configurable leaf certificates:

  1. Use curl to make an API call to regenerate all non-configurable certificates and apply the new CA to your existing BOSH Director. Run:

    curl "https://OPS-MANAGER-FQDN/api/v0/certificate_authorities/active/regenerate" \
          -X POST \
          -H "Authorization: Bearer UAA-ACCESS-TOKEN" \
          -H "Content-Type: application/json" \
          -d '{}'
    

    Where:

    • OPS-MANAGER-FQDN is the FQDN of your Ops Manager deployment.
    • UAA-ACCESS-TOKEN is your UAA access token.

      The API returns a successful response:
      HTTP/1.1 200 OK
  2. Navigate to the Ops Manager Installation Dashboard.

  3. Click Review Pending Changes.

  4. Click Apply Changes to perform a second deploy.

Rotate Configurable Leaf Certificates

Configurable certificates are generated by the user and pasted into Ops Manager configuration panes where needed. Examples include certificates that terminate SSL traffic into TAS for VMs, or authenticate a Single Sign-On for VMware Tanzu service plan to an external SAML server.

For instructions on how to rotate SAML certificates for both TAS for VMs and the Single Sign-On for VMware Tanzu service, see Rotate Identity Provider SAML Certificates.

Warning: This procedure does not rotate the Ops Manager root CA. To rotate both the root CA and non-configurable leaf certificates, see Rotate CAs and Leaf Certificates.

To rotate configurable leaf certificates:

  1. If you have not already done so, use the Ops Manager API deployed/certificates endpoint to retrieve information about your expiring configurable certificates, as described in the procedures in Check Expiration Dates and Certificate Types. The information for each configurable certificate looks like the following example:

    {
      "configurable": true,
      "property_reference": ".properties.networking_poe_ssl_certs[0].certificate",
      "property_type": "rsa_cert_credentials",
      "product_guid": "cf-36066831c119c39736d3",
      ...
      "valid_until": "2019-01-25T22:07:58Z"
    },
    

  2. For each configurable certificate that expires soon:

    1. Find the text field the certificate is configured within the Ops Manager interface.
      • The product_guid field in the API output can help identify which tile the certificate is configured in. For example, the prefix p-bosh- refers to the BOSH Director tile, and the prefix cf- refers to the TAS for VMs tile.
      • The property_reference field in the API output can often help identify which Settings pane the certificate is configured in. For example, the uaa.service_provider_key_credentials property is configured in the UAA pane of the TAS for VMs tile.
      • You might need to look through multiple configuration panes to identify where a certificate is configured.
    2. Paste a new value for the certificate into the field.
    3. Click Save at the bottom of each pane in which you have provided new certificates.
  3. If you are rotating configurable certificates within the Rotate CAs and Leaf Certificates procedure, continue to the next step. Otherwise, if you are rotating configurable leaf certificates only:

    1. Return to the Ops Manager Installation Dashboard.
    2. Click Review Pending Changes.
    3. Click Apply Changes.

Rotate Identity Provider SAML Certificates

SAML service provider (SP) credentials are one example of configurable certificates in TAS for VMs. When TAS for VMs is configured to use SAML as an IDP, it uses a configurable CA certificate to authenticate to an external SAML server, by generating ephemeral certificates that TAS for VMs includes in its outbound request message headers. This CA has a two-year expiration period.

In addition, the Single Sign-On for VMware Tanzu service shares the use of TAS for VMs SAML certificates for every SAML external IDP integration, such as trust, partnership, or federation. You must rotate these in lockstep with TAS for VMs. For more information about Single Sign-On for VMware Tanzu, see the Single Sign-On for VMware Tanzu documentation.

The following procedure provides an example of how to rotate certificates for each IDP, including temporarily disabling certificate validation on the IDP side during the rotation.

For more information about rotating SAML certificates, see PCF Advisory - SAML Service Provider Credential Certificates Expire after 2 Years in the VMware Tanzu Knowledge Base.

SAML SP credentials are only required for your TAS for VMs deployment if all of these conditions are met:

  • You are using Single Sign-On for VMware Tanzu in production for login to TAS for VMs or using the Single Sign-On for VMware Tanzu service for login to apps.

  • You are using SAML IDPs for TAS for VMs or Single Sign-On for VMware Tanzu service plans.

  • You had Ops Manager generate a certificate for you by clicking the Generate RSA Certificate button.

  • You are validating the signature of SAML authentication request with your IDP.

To regenerate and rotate SAML SP certificates without disrupting TAS for VMs or your apps using the Single Sign-On for VMware Tanzu service:

  1. Disable certificate validation in your IDP.

  2. For TAS for VMs, follow the procedure in the table below that corresponds to your use case. This includes downloading and importing a new certificate and updated SAML metadata in your IDP.

    Solution Name Procedure
    CA Single Sign-On aka CA SiteMinder Configuring CA as an Identity Provider
    PingFederate Configuring PingFederate as an Identity Provider
    Active Directory Federation Services (AD FS) Configuring AD FS as an Identity Provider

  3. For the Single Sign-On for VMware Tanzu service, follow the procedure in the table below that corresponds to your use case. This includes downloading the SAML SP metadata for each SAML IDP integration, such as trust, partnership, or federation, and importing the updated SAML SP metadata in your IDP.

    Solution Name Procedure
    AD FS Configuring a Single Sign-On for VMware Tanzu Service Provider
    CA Single Sign-On for VMware Tanzu Configuring a Single Sign-On for VMware Tanzu Service Provider
    Okta Configure Okta as an Identity Provider
    PingFederate Configure PingFederate as an Identity Provider
    Additional Documentation Integration Guides

  4. Re-enable certificate validation in your IDP.