PingOne Advanced Identity Cloud

Manage SSL certificates using the API

For background on self-managed SSL certificates, learn more in Self-managed SSL certificates.

Certificate API endpoints

To use the certificate API, learn more in the following Advanced Identity Cloud API endpoints:

Authenticate to certificate API endpoints

To authenticate to certificate API endpoints, use an access token created with one of the following scopes:

Scope Description

fr:idc:certificate:*

Full access to certificate API endpoints. Use this scope to create, activate, deactivate, or delete certificates.

fr:idc:certificate:read

Read-only access to certificate API endpoints. Use this scope if you only need to List certificates.

Prerequisites

You need the openssl and jq command-line tools to run some of the commands. You can find installation instructions for your particular package manager in https://command-not-found.com/openssl and https://command-not-found.com/jq.

Create a certificate using a tenant-generated private key

You can create certificates using a private key the tenant generates for you and which is retained in the tenant. The benefit of this approach is there is no risk of accidentally leaking your private key as it never leaves the tenant. However, with this approach, you can only install a signed certificate on the same tenant from which you requested the CSR.

Step 1: Create a CSR using the certificate API

In this step, you create a certificate signing request (CSR). You’ll need this in the next step to create a self-signed certificate or to send to your preferred SSL certificate provider to create a CA-signed certificate.

  1. Create a JSON payload of CSR information:

    1. Adapt the following example configuration to suit your company:

      {
        "commonName": "www.pingidentity.com", (1)
        "organization": "Ping Identity Corporation",  (1)
        "organizationalUnit": "IT", (1)
        "country": "US", (1)
        "streetAddress": "1001 17th Street", (1)
        "city": "Denver", (1)
        "postalCode": "80202", (1)
        "email": "example.user@pingidentity.com", (1)
        "businessCategory": "Private Organization", (2)
        "serialNumber": "3463471", (2)
        "jurisdictionCountry": "US", (2)
        "jurisdictionLocality": "Wilmington", (2)
        "jurisdictionState": "Delaware", (2)
        "subjectAlternativeNames": ["support.pingidentity.com", "labs.pingidentity.com"] (3)
      }
      1 Configures the standard CSR fields. All standard fields are included for demonstration, but this is not strictly necessary. Consult your SSL certificate provider’s documentation for the minimum required fields. Remove any fields that are not used rather than include them with an empty value.
      2 (Optional) Configures the EV CSR fields. All EV fields are included for demonstration, but only businessCategory, serialNumber, and jurisdictionCountryName are required.
      3 (Optional) Configures the subject alternative names (SANs). SANs are domains the certificate will secure in addition to the commonName. Wildcards values in SAN domains are not permitted.
    2. Save your adapted configuration in a local file called csr-payload.json.

  2. In the tenant environment where you intend to install the certificate:

    1. Get an access token created with the fr:idc:certificate:* scope.

    2. Create a CSR using the /environment/csrs endpoint:

      $ curl \
      --request POST 'https://<tenant-env-fqdn>/environment/csrs' \ (1)
      --header 'Authorization: Bearer <access-token>' \ (2)
      --header 'Content-Type: application/json' \
      --data "$(< csr-payload.json)" \ (3)
      > tee csr-result.json (4)
      1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
      2 Replace <access-token> with the access token.
      3 The request body is populated with the output of csr-payload.json.
      4 The response is stored in a local file called csr-result.json.
      Show response
      {
        "algorithm": "SHA256-RSA",
        "createdDate": "2024-04-24T17:11:42Z",
        "id": "4f1caf97-bd2f-4d30-8e68-682fa10d27ff", (1)
        "request": "-----BEGIN CERTIFICATE REQUEST-----\nMIIDTTCCAjUCAQAwgbcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQHEwZEZW52ZXIxGTAX\nBgNVB ... MUREqk/\ndSPgWeMMVFQwlmljkE+cvGl9L3f7aPgXtR6nxPS/oTSl\n-----END CERTIFICATE REQUEST-----\n",
        "subject": "CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,STREET=1001 17th Street,L=Denver,C=US",
        "subjectAlternativeNames": [
          "support.pingidentity.com",
          "labs.pingidentity.com"
        ]
      }
      1 The CSR ID is represented by the id key. You need this ID in a later step to update the CSR with the signed certificate. In this example, the CSR ID is 4f1caf97-bd2f-4d30-8e68-682fa10d27ff.
    3. Extract the CSR from the request key of the JSON object in csr-result.json:

      $ jq -r .request csr-result.json > csr.pem
    4. Review the contents of the CSR in csr.pem:

Step 2: Generate a signed certificate and create a certificate chain

In this step, you create a CA-signed or self-signed certificate, then create a PEM-formatted certificate chain.

  1. Create a certificate from the CSR in one of these ways:

    • CA-signed certificate:
      Supply the CSR to your preferred SSL certificate provider so they can generate a CA-signed certificate. Your SSL certificate provider should provide you with a signed certificate and a CA certificate. They may also provide intermediary certificates.

    • Self-signed certificate:
      Use OpenSSL to create a custom CA certificate and a self-signed certificate.

  2. Combine your signed certificate and CA certificate into a certificate chain and save it in the local file chain.pem. If you used an SSL certificate provider, add any intermediary certificates into chain.pem too, inserted between your signed certificate and the CA certificate:

    $ cat cert.pem [inter.cert.pem ...] ca.cert.pem > chain.pem

    The following is an example of what the certificate chain might look like:

    -----BEGIN CERTIFICATE-----
    content of your signed certificate
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    content of an optional intermediate CA certificate
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    content of a CA certificate
    -----END CERTIFICATE-----

Step 3: Install the certificate

In this step, you install the certificate in the tenant environment where you created the CSR request.

  1. Create a JSON payload of certificate information:

    1. Add the certificate chain to a JSON object:

      $ jq -Rs '{certificate: .}' ./chain.pem > payload.json

      Summary of command:

      • Creates a JSON object using the jq command. Learn more in Prerequisites.

      • Adds a certificate key to the JSON object set with the contents of chain.pem as a single line.

      • Saves the JSON object in a local file called payload.json.

    2. The contents of payload.json should look something like this:

      {
        "certificate": "-----BEGIN CERTIFICATE-----\ncontent of your signed certificate\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\ncontent of an optional intermediate CA certificate\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\ncontent of your CA certificate\n-----END CERTIFICATE-----\n"
      }
  2. In the tenant environment where you created the CSR request in step 1.2 and intend to install the certificate:

    1. Get an access token created with the fr:idc:certificate:* scope.

    2. Upload the certificate using the /environment/csrs endpoint:

      $ curl \
      --request PATCH 'https://<tenant-env-fqdn>/environment/csrs/<csr-id>' \(1) (2)
      --header 'Authorization: Bearer <access-token>' \(3)
      --header 'Content-Type: application/json' \
      --data "$(< payload.json)" (4)
      1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
      2 Replace <csr-id> with the CSR ID you noted in step 1, 2b.
      3 Replace <access-token> with the access token.
      4 The request body is populated with the output of payload.json.
      Show response
      {
          "algorithm": "SHA256-RSA",
          "certificateID": "ccrt-d7bad9b1-65fa-48ce-b56a-bd320a75d477", (1)
          "createdDate": "2024-05-03T12:49:29Z",
          "id": "11c5419e-c5de-466d-a7e7-d65afbde1217",
          "request": "-----BEGIN CERTIFICATE REQUEST-----\nMIIDozCCAosCAQAwgbcxCzAJBgNVBAYTAlVTMQ8wDQYDVQQHEwZEZW52ZXIxGTAX\nBgNVB ... ABMyK1\nDVSVbrcuZMoxcnzZNynjGLe58iFS+ko=\n-----END CERTIFICATE REQUEST-----\n",
          "subject": "CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,STREET=1001 17th Street,L=Denver,C=US",
          "subjectAlternativeNames": [
              "support.pingidentity.com",
              "labs.pingidentity.com"
          ]
      }
      1 The certificate ID is represented by the certificateID key. You need this ID to activate, deactivate, or delete the certificate. In this example, the certificate ID is ccrt-d7bad9b1-65fa-48ce-b56a-bd320a75d477.
    3. Get the certificate information using the /environment/certificates endpoint:

      $ curl \
      --request GET 'https://<tenant-env-fqdn>/environment/certificates/<certificate-id>' \(1) (2)
      --header 'Authorization: Bearer <access-token>' \(3)
      --header 'Content-Type: application/json'
      1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
      2 Replace <certificate-id> with the certificate ID you noted in the previous step.
      3 Replace <access-token> with the access token.
      Show response
      {
          "active": false, (1)
          "expireTime": "2024-06-02T12:58:01Z",
          "id": "ccrt-d7bad9b1-65fa-48ce-b56a-bd320a75d477", (2)
          "issuer": "CN=Self-signing CA",
          "live": false,  (3)
          "subject": "CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,STREET=1001 17th Street,L=Denver,C=US,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
          "subjectAlternativeNames": [
              "support.pingidentity.com",
              "labs.pingidentity.com"
          ],
          "validFromTime": "2024-05-03T12:58:01Z"
      }
      1 The active key is set to false which indicates that the certificate is not active. This is the default value for a new certificate.
      2 The certificate ID is represented by the id key. This is the same ID as in the certificateID key in the CSR response from the previous step.
      3 The live key returns the value false, which indicates the certificate is not installed in the environment’s load balancer. In the next step, you will set the active key to true. This triggers an asynchronous process that installs the certificate in the environment’s load balancer. When the asynchronous process is complete, the live key returns the value true.
    4. Activate the certificate to install it in the environment’s load balancer.

Create a certificate using a locally generated private key

You can create certificates using a private key you generate locally and retain access to. The benefit of this approach is once you have signed the certificate, you can install it with the private key on as many tenants as you need. However, to use this approach, you must have robust security practices when handling the private key.

Step 1: Create a CSR using the command line

In this step, you create a certificate signing request (CSR). You’ll need this in the next step to create a self-signed certificate or to send to your preferred SSL certificate provider to create a CA-signed certificate.

  1. Create an OpenSSL CSR configuration file:

    1. Adapt the following example configuration to suit your company:

      [ req ] (1)
      prompt             = no (2)
      distinguished_name = req_distinguished_name
      req_extensions     = req_ext (5)
      
      [ req_distinguished_name ]
      
      # Standard CSR fields (3)
      commonName             = www.pingidentity.com
      organizationName       = Ping Identity Corporation
      organizationalUnitName = IT
      countryName            = US
      streetAddress          = 1001 17th Street
      localityName           = Denver
      stateOrProvinceName    = Colorado
      postalCode             = 80202
      emailAddress           = example.user@pingidentity.com
      
      # EV CSR fields (4)
      businessCategory                = Private Organization
      serialNumber                    = 3463471
      jurisdictionCountryName         = US
      jurisdictionLocalityName        = Wilmington
      jurisdictionStateOrProvinceName = Delaware
      
      [ req_ext ]  (5)
      subjectAltName = @alt_names
      
      [alt_names]  (5)
      DNS.1 = support.pingidentity.com
      DNS.2 = labs.pingidentity.com
      1 Configures the openssl req command.
      2 Configures the openssl req command to use the CSR values supplied in this configuration file instead of prompting for them.
      3 Configures the standard CSR fields. All standard fields are included for demonstration, but this is not strictly necessary. Consult your SSL certificate provider’s documentation for the minimum required fields. Remove any fields that are not used rather than include them with an empty value.
      4 (Optional) Configures the EV CSR fields. All EV fields are included for demonstration, but only businessCategory, serialNumber, and jurisdictionCountryName are required.
      5 (Optional) Configures the subject alternative names (SANs). SANs are domains the certificate will secure in addition to the commonName. Wildcard values in SAN domains are not permitted.
    2. Save your adapted configuration in a local file called openssl-csr.conf.

  2. Create a CSR:

    1. Generate a CSR and private key pair using the configuration in openssl-csr.conf:

      $ openssl req \
      -nodes -newkey rsa:2048 \
      -out csr.pem -keyout key.pem \
      -config openssl-csr.conf
    2. Review the CSR and private key, which are respectively in the local files csr.pem and key.pem:

Step 2: Generate a signed certificate and create a certificate chain

In this step, you create a CA-signed or self-signed certificate, then create a PEM-formatted certificate chain.

  1. Create a certificate from the CSR in one of these ways:

    • CA-signed certificate:
      Supply the CSR to your preferred SSL certificate provider so they can generate a CA-signed certificate. Your SSL certificate provider should provide you with a signed certificate and a CA certificate. They may also provide intermediary certificates.

    • Self-signed certificate:
      Use OpenSSL to create a custom CA certificate and a self-signed certificate.

  2. Combine your signed certificate and CA certificate into a certificate chain and save it in the local file chain.pem. If you used an SSL certificate provider, add any intermediary certificates into chain.pem too, inserted between your signed certificate and the CA certificate:

    $ cat cert.pem [inter.cert.pem ...] ca.cert.pem > chain.pem

    The following is an example of what the certificate chain might look like:

    -----BEGIN CERTIFICATE-----
    content of your signed certificate
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    content of an optional intermediate CA certificate
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    content of a CA certificate
    -----END CERTIFICATE-----

Step 3: Install the certificate and private key

In this step, you install the certificate and private key in your tenant environments.

  1. Create a JSON payload of certificate information:

    1. Add the certificate chain and private key to a JSON object:

      $ (jq -Rs '{certificate: .}' ./chain.pem; jq -Rs '{privateKey: .}' ./key.pem)  | jq -s add  > payload.json

      Summary of command:

      • Creates a JSON object using the jq command. Learn more in Prerequisites.

      • Adds a certificate key to the JSON object set with the contents of chain.pem as a single line.

      • Adds a privateKey key to the JSON object set with the contents of key.pem as a single line.

      • Saves the JSON object in a local file called payload.json.

    2. The contents of payload.json should look something like this:

      {
        "certificate": "-----BEGIN CERTIFICATE-----\ncontent of your signed certificate\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\ncontent of an optional intermediate CA certificate\n-----END CERTIFICATE-----\n-----BEGIN CERTIFICATE-----\ncontent of your CA certificate\n-----END CERTIFICATE-----\n",
        "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----\ncontent of your private key\n-----END ENCRYPTED PRIVATE KEY-----\n"
      }
  2. In each tenant environment where you want to install the certificate:

    1. Get an access token created with the fr:idc:certificate:* scope.

    2. Upload the certificate using the /environment/certificates endpoint:

      $ curl \
      --request POST 'https://<tenant-env-fqdn>/environment/certificates' \(1)
      --header 'Authorization: Bearer <access-token>' \(2)
      --header 'Content-Type: application/json' \
      --data "$(< payload.json)" (3)
      1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
      2 Replace <access-token> with the access token.
      3 The request body is populated with the output of payload.json.
      Show response
      {
          "active": false, (1)
          "expireTime": "2024-06-01T15:14:54Z",
          "id": "ccrt-134425bc-6203-48fe-bbef-b17792faf972", (2)
          "issuer": "CN=Self-signing CA",
          "live": false, (3)
          "subject": "SERIALNUMBER=3463471,CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,POSTALCODE=80202,STREET=1001 17th Street,L=Denver,ST=Colorado,C=US,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,1.3.6.1.4.1.311.60.2.1.1=#130a57696c6d696e67746f6e,1.3.6.1.4.1.311.60.2.1.3=#13025553,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
          "subjectAlternativeNames": [
              "support.pingidentity.com",
              "labs.pingidentity.com"
          ],
          "validFromTime": "2024-05-02T15:14:54Z"
      }
      1 The active key is set to false, which indicates the certificate is not active. This is the default value for a new certificate.
      2 The certificate ID is represented by the id key. You need this ID to activate, deactivate, or delete the certificate. In this example, the certificate ID is ccrt-134425bc-6203-48fe-bbef-b17792faf972.
      3 The live key returns the value false, which indicates the certificate is not installed in the environment’s load balancer. In the next step, you will set the active key to true. This triggers an asynchronous process that installs the certificate in the environment’s load balancer. When the asynchronous process is complete, the live key returns the value true.
    3. Activate the certificate to install it in the environment’s load balancer.

List certificates

List certificates to view all certificates in a tenant environment. Certificates can be active (installed in the environment’s load balancer) or inactive (not installed in the environment’s load balancer). The list includes any certificates the Ping Identity support team added to the environment.

In any tenant environment

  1. Get an access token created with the fr:idc:certificate:read scope.

  2. Get a list of certificates from the /environment/certificates endpoint:

    $ curl \
    --request GET 'https://<tenant-env-fqdn>/environment/certificates' \(1)
    --header 'Authorization: Bearer <access-token>' \(2)
    --header 'Content-Type: application/json'
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <access-token> with the access token.
    Show response
    [
        {
            "active": false,
            "expireTime": "2024-06-01T15:14:54Z",
            "id": "ccrt-4ac300e5-7e0a-4d34-a42c-c41a076458da",
            "issuer": "CN=Self-signing CA",
            "live": false,
            "subject": "SERIALNUMBER=3463471,CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,POSTALCODE=80202,STREET=1001 17th Street,L=Denver,ST=Colorado,C=US,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,1.3.6.1.4.1.311.60.2.1.1=#130a57696c6d696e67746f6e,1.3.6.1.4.1.311.60.2.1.3=#13025553,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
            "subjectAlternativeNames": [
                "support.pingidentity.com",
                "labs.pingidentity.com"
            ],
            "validFromTime": "2024-05-02T15:14:54Z"
        },
        {
            "active": false,
            "expireTime": "2024-06-02T12:58:01Z",
            "id": "ccrt-d7bad9b1-65fa-48ce-b56a-bd320a75d477",
            "issuer": "CN=Self-signing CA",
            "live": false,
            "subject": "CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,STREET=1001 17th Street,L=Denver,C=US,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
            "subjectAlternativeNames": [
                "support.pingidentity.com",
                "labs.pingidentity.com"
            ],
            "validFromTime": "2024-05-03T12:58:01Z"
        }
    ]

Activate a certificate

Activate a certificate to install it in a tenant environment’s load balancer. If you activate more than one certificate at once, the environment’s load balancer will serve the most appropriate for the requested hostname. This lets you rotate certificates by installing and activating a new certificate before an older certificate expires.

In any tenant environment:

  1. List the certificates in the environment and examine the response to find the ID of the certificate (represented as the JSON id key) you intend to activate.

  2. Get an access token created with the fr:idc:certificate:* scope.

  3. Update the certificate by patching the JSON active key to true:

    $ curl \
    --request PATCH 'https://<tenant-env-fqdn>/environment/certificates/<certificate-id>' \(1) (2)
    --header 'Authorization: Bearer <access-token>' \(3)
    --header 'Content-Type: application/json' \
    --data '{"active": true}' (4)
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <certificate-id> with the certificate ID you found in step 1.
    3 Replace <access-token> with the access token.
    4 The request body is set with a new value for the JSON active key (true).
    Show response
    {
        "active": true,
        "expireTime": "2024-06-01T15:14:54Z",
        "id": "ccrt-134425bc-6203-48fe-bbef-b17792faf972",
        "issuer": "CN=Self-signing CA",
        "live": false,
        "subject": "SERIALNUMBER=3463471,CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,POSTALCODE=80202,STREET=1001 17th Street,L=Denver,ST=Colorado,C=US,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,1.3.6.1.4.1.311.60.2.1.1=#130a57696c6d696e67746f6e,1.3.6.1.4.1.311.60.2.1.3=#13025553,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
        "subjectAlternativeNames": [
            "support.pingidentity.com",
            "labs.pingidentity.com"
        ],
        "validFromTime": "2024-05-02T15:14:54Z"
    }
  4. An asynchronous process will automatically install the certificate in the environment’s load balancer. To check when the asynchronous process has completed, poll the /environment/certificates endpoint using the certificate ID until the live key in the response changes from false to true:

    $ curl \
    --request GET 'https://<tenant-env-fqdn>/environment/certificates/<certificate-id>' \(1) (2)
    --header 'Authorization: Bearer <access-token>' \(3)
    --header 'Content-Type: application/json'
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <certificate-id> with the ID of the certificate you updated.
    3 Replace <access-token> with the access token.

    When the asynchronous process has completed and installed the certificate in the environment’s load balancer, the response should look like this:

    Show response
    {
        "active": true,
        "expireTime": "2024-06-01T15:14:54Z",
        "id": "ccrt-134425bc-6203-48fe-bbef-b17792faf972",
        "issuer": "CN=Self-signing CA",
        "live": true,
        "subject": "SERIALNUMBER=3463471,CN=www.pingidentity.com,OU=IT,O=Ping Identity Corporation,POSTALCODE=80202,STREET=1001 17th Street,L=Denver,ST=Colorado,C=US,1.3.6.1.4.1.311.60.2.1.2=#130844656c6177617265,1.3.6.1.4.1.311.60.2.1.1=#130a57696c6d696e67746f6e,1.3.6.1.4.1.311.60.2.1.3=#13025553,2.5.4.15=#131450726976617465204f7267616e697a6174696f6e,1.2.840.113549.1.9.1=#0c1d6578616d706c652e757365724070696e676964656e746974792e636f6d",
        "subjectAlternativeNames": [
            "support.pingidentity.com",
            "labs.pingidentity.com"
        ],
        "validFromTime": "2024-05-02T15:14:54Z"
    }

Deactivate a certificate

Deactivate a certificate to uninstall it from a tenant environment’s load balancer. If you deactivate all certificates in an environment, the load balancer will fall back to using a Google-managed certificate.

To deactivate a certificate, follow the instructions in Activate a certificate with the following changes:

  • In step 3, patch the JSON active key to false.

  • In step 4, poll the /environment/certificates endpoint until the live key in the response changes from true to false.

Delete a certificate

Delete a certificate to permanently remove it from a tenant environment.

In any tenant environment:

  1. List the certificates in the environment and examine the response to find the ID of the certificate you intend to delete, represented by the id key.

  2. If you have not done so already, deactivate the certificate to uninstall it from the environment’s load balancer.

  3. Get an access token created with the fr:idc:certificate:* scope.

  4. Delete the certificate:

    $ curl \
    --request DELETE 'https://<tenant-env-fqdn>/environment/certificates/<certificate-id>' \(1) (2)
    --header 'Authorization: Bearer <access-token>' \(3)
    --header 'Content-Type: application/json'
    1 Replace <tenant-env-fqdn> with the FQDN of your tenant environment.
    2 Replace <certificate-id> with the certificate ID you found in step 1.
    3 Replace <access-token> with the access token.