Create and Sign Certificates for Production

In this article:
In this article:
Verify the Prerequisites
Review your DNS entries and make sure the values match the prerequisites listed in Configure Your DNS Server.
Important Portal Certificates
API Portal exposes services publicly over HTTPS. Before going into production, ensure that the following two certificates are signed to protect your services:
Service Name
Common Name (CN) Value
: If required, you can replace the wildcard for multiple domains using
subject alternative names
Protects all public facing HTTPS traffic.
: Customers using a release prior to may have a PORTAL_TENANT_ID value that is different than the 'apim' value.
Protects the OTK token HTTPS traffic.
Signing Portal Certificate
To use a Portal certificate:
The example uses the following values:
  • foobar
    is the name of your Portal.
    is the PORTAL_DOMAIN variable defined in the configuration file (
  1. SSH into the VM that is running API Portal.
  2. Navigate to the
    directory and execute the following command:
    sudo ./ FQDN
    Where FQDN is your fully qualified domain name that combines the value of your tenant ID with your domain. As shown in the following example, the FQDN is
    sudo ./
    From this input, the script will look for the cert (
    .crt) and key (
    .pem) associated to the FQDN in
    /<portal installation dir>/certs/
    . If not found, the script will generate a CSR with the FQDN using the pem file(key).
  3. To generate the Portal certificate, fill in the prompt with the following inputs:
    • Organization Name
    • Organizational Unit Name
    • City or Locality Name
    • State or Province Name
    • Country Name (2-letter code)
    • Email Address
  4. Navigate to
    and send the newly generated CSR file (
    ) to a trusted CA authority to be signed.
    The CA authority returns a signed certificate with the extension .crt.
  5. Ensure that the certificate file is valid and that the certificate name matches your tenant URL. For example:
  6. Put the certificate file back in
  7. Re-run the dispatcher command with your FQDN:
    sudo ./
Signing the APIM Portal Certificate
If you cannot get an already signed certificate from your Certificate Authority (CA), then you can follow this procedure to sign the APIM Portal certificate. The APIM Portal certificate (for example,
) should also be signed by the CA authority key.
To generate the key and Certificate Signing Request (CSR), follow these steps:
  1. To generate the key and Certificate Signing Request (CSR), execute the following commands using OpenSSL and substitute
    openssl genrsa -des3 -out <FILENAME>.key -passout pass:<PASSWORD> 2048
    openssl req -new -key <FILENAME>.key -passin pass:<PASSWORD> -out <FILENAME>.csr -days 365 -subj "/CN=XXXX"
  2. After the private key is created, store the key in a secure location.
  3. Send the CSR to a trusted CA authority to be signed.
    The CA authority returns a signed certificate.
  4. Create a PKCS12 container to hold a private key and signed certificate for consumption by our application. This PKCS 12 file
    hold one private key and one signed certificate and the password
    be protected. Use the following command to create a PKCS12 container:
    openssl pkcs12 -export -inkey <FILENAME>.key -in <FILENAME>.crt -out <FILENAME>.p12 -passin pass:<PASSWORD> -passout pass:<PASSWORD>
    If you want to use a different key for the HTTPD service (the dispatcher service) and the APIM service (the Ingress), run the
    command in this step twice to generate two different p12 files.
    If you want to use the same key for both the HTTPD service and the APIM service, run the
    command only once and define the same key file location for the
  5. The PKCS12 (p12) file(s) should be signed by CA authority key in production. To configure CA Services to use the new keys and certificates, perform the following steps:
    1. Edit the
      file that is located in the
      directory by adding the following configuration to the file:
      , and
      character cannot be used in any of the key passwords. If special characters are used in
      , the values should be in single quotes.
      PORTAL_HTTPD_SSL_KEY='/home/qa/dispatcher_new.p12' PORTAL_HTTPD_SSL_KEY_PASS='[email protected]#%^*()_-+=' PORTAL_TSSG_SSL_KEY='/home/qa/tssg_new.p12' PORTAL_TSSG_SSL_KEY_PASS='[email protected]#%^*()_-+='
    2. Save and exit the file.
    3. Run the
      file to update the containers in the background.
Getting a Signed SAN Certificate Installed
This section is only applicable to customers who are using multi-public facing host names for Portal - that is, Portal being accessible in the internal and external network that has two or multiple domains.
CA Portal currently does not support multi-tenancy. However, for exempted customers (who previously implemented solution or underwent a technical assessment by CA), a SAN Certificate can be used to address multiple host names for a signed certificate versus using a wildcard certificate.
If you already have a signed certificate, perform the following procedure:
  1. Prepare a CA signed SAN cert (for example,
    ) and key (
    ) in the
    /<portal installation dir>/certs/
  2. Run the
If you have a new Portal install or you have no certificate, perform the following procedure:
  1. Since
    doesn't support SAN, follow these steps to temporarily modify
    to provide an additional
    subject Alt Name
    to include in this cert:
    1. Run the
    2. Modify
      function generate_ssl_cert
      to add
      (for example,
      ) Certificates Configuration.png
  2. Generate a CSR by going through
  3. Take the CSR to get a certificate signed by a CA.
  4. Replace the self-signed certificate (.crt) found in
    /<portal installation dir>/certs/
    with the signed certificate.
  5. Run
  6. Remember to roll back the temporary change made on
Verifying the Install of a Self-Signed SAN Certificate
  1. On the browser, select
    Not secure
    in the address bar. The following is an example in Chrome:
    Certificates Configuration 2.png
  2. Expand the certificate, and look for the Subject Alternative Name, as shown in the below example:
    Certificates Configuration 4.png
Other Trust Relationships for Portal Certificates
A few services are exposed on the PSSG and Ingress service endpoints that are publicly accessible but have self-signed certificates. These services are not meant to be accessible through a web browser. The services are protected through 2-way SSL (mutual authentication) and have an explicit trust between the caller and the service. The trust is established during provisioning. Although these services are discoverable, users cannot access them because these services do not have the proper certificate to access the endpoints.
PSSG and Ingress services are accessible on the following endpoints which are not accessible for API Portal:
PSSG service:
  • sso.<domain>
  • sync.<domain>
  • enroll.<domain>
Ingress service:
  • analytics.<domain>
  • broker.<domain>