Skill Level: Any Skill Level

This showcases the break down (mapping) of a TLS Profile from CMC on DataPower.


  1. How the crypto object is mapped on the runtime Gateway


    When you need to reference a crypto object or certificate that is “infused” into the APIC framework, you can locate the name of the object or cert in the APIC generated domain of DataPower.

    For example, if a user-defined policy is going to require a url-open extension function, which uses a SSL Proxy Profile, you will be able to find the name in the APIC generated domain SSL Proxy Profile, as shown in #2 in the diagram. Similarly, if you’re referencing a crypto key name in a user-defined policy, for example, you will locate the Crypto Key object name, and use that to reference as needed.

    The suggestion when building a user-defined policy where you require crypto objects to be referenced, is to refrain from importing it with the user-defined policy. This is because there is no out-of-the-box support to manage those crypto object certificates easily.

    The suggested approach, is to create a TLS profile on CMC, and ensure that the profile is marked with the public check dial enabled, so the profile may be used throughout the provider organizations. Once the TLS profile is created on CMC, it may be used by the user-defined policy, and it can be managed from the CMC, rather than user-defined policy process (exporting from DataPower and re-importing the policy into APIC).

  2. Validating the Present Cert

    From the Crypto Certificate object section on DataPower, you may click on details to view the certificate properties to verify that certificate used is correct despite the renamed certificate file on DataPower. You may also go into the File Management section of DataPower under the cert:/// folder to verify the details.


  3. Validating the Trust Store

    To see the Trust Store certificate populated on the gateway, you will have to select the “Request and validate certificate againt the supplied CAs in the truststore”.


    As you can see I’ve uploaded testCertB into the Trust Store and enabled the Request and validate cert:


4 comments on"API Connect: Referencing Crypto Objects in User-Defined Policies"

  1. Interesting article. In the TLS Profile there are two sections: 1) Present Certificate ; 2) Trust Store. Which is the correct place to upload a public key that later will be referenced as a Crypto Certificate in gatewayscript statements like “decoder.addOperation(‘verify’, cryptoCertName)”? Another question … which is the correct place to upload private keys that will be later used in instructions like “jose.createJWSHeader” ? Can we use the same key / certificate formats that we use when defining Crypto Certificates and Crypto Keys? Thank you.

    • If you have the p12 cert, it should be bundled with the public cert and private key, in which goes into the Present Cert (this is similar to DataPower’s server-side crypto objects), whereas any other intermediate certificates, or public cert itself can go into the Trust Store (this is similar to DataPower client-side crypto objects). Unfortunately, the format for the Present cert will have to be p12, therefore you have to bundle your .pem to .p12 format, which openssl can do easily –> openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt (reference: https://www.sslshopper.com/article-most-common-openssl-commands.html) … the trust store can be .pem.

  2. uhm, with this solution , will be all TLS profiles available for all organizations? could organization A use crypto material designed for organization B?

    • Since this was created on the CMC, once you click on the Public check radio button, all provider orgs should be able to see it. If you created a TLS profile within the APIM provider organization, it’s then you cannot share it across provider orgs. Yes, you can use the TLS profile everywhere because it’s a parent object from the CMC.

Join The Discussion