Configuring Private Keys for PKI

Private keys are used as unique pieces of data for encryption and signature operations. They can be used to secure data or provide verifiable identities. The  creates a private key for itself that is used as the default private key for all cryptographic functions. For example, this default private key is used for outbound message routing, inbound request listeners, and for signing or encrypting messages.
gateway83
Private keys are used as unique pieces of data for encryption and signature operations. They can be used to secure data or provide verifiable identities. The 
API Gateway
creates a private key for itself that is used as the default private key for all cryptographic functions. For example, this default private key is used for outbound message routing, inbound request listeners, and for signing or encrypting messages.
Contents:
Generating Self-Signed Certificates
The Gateway creates a self-signed certificate when you create a private key. Keep the following in mind:
  • The
    Alias
    field is required.
  • The
    Subject DN
    field defaults to the Alias, but you can modify it to include more subject attributes. For example:
    • Alias:
      cluster.example.com
    • Subject DN:
      CN=cluster.example.com
  • Specify the
    Key type
    and
    Days until expiry
    as appropriate for your organization. The expiry period dictates the longevity of the initial self-signed certificate. Once that certificate expires, you must create a new private key.
  • If the private key will be used to sign client certificates, select the
    CA capable
    option. 
  • In the Advanced tab, select the appropriate
    Signature hash
    . Every private key has a signature that is hashed with a particular algorithm. The default setting
    Auto
    means that the Gateway determines the hash to use. This setting works well in most instances. Check with your Infrastructure Department whether a specific hash setting is required.
For detailed instructions, see Create a Private Key.
Generating Certificate Signing Requests
To convert a self-signed certificate into a signed one, you create a certificate signing request (CSR) and then send it to a certificate authority (CA). The CA signs the CSR, which generates a signed certificate for that particular private key. This signed certificate allows third parties to accept your certificate by trusting its issuer.
For example, a signed certificate may originate from a vendor such as Entrust. The private key of the Gateway has a certificate that is signed and issued by Entrust. A client connecting to the Gateway may not explicitly trust the Gateway’s certificate but the client trusts Entrust. By association, the client trusts the Gateway’s certificate, as it was issued by a trusted CA.
For detailed instructions, see Generate a Certificate Signing Request (CSR).
Replacing Certificate Chains
A signed certificate must be associated with a private key in the Gateway key store. The Gateway combines the signed certificate and the private key into a PKCS#12 archive for use within the Gateway appliance. This PKCS#12 archive links the signed certificate to a particular private key. The key or certificate can then be used in a service policy, listen port, or other aspect of the Gateway.
Most commercial certificate authorities deliver signed certificates with the full certificate chain as a
concatenated certificate chain
. A concatenated certificate chain is used to link a signed certificate to a root certificate authority. This establishes the
chain of trust
that is a central focus of PKI. A user or service consuming a certificate that provides a full certificate chain can verify the issuer of a certificate. This prevents future and potential trust-related problems with PKI.
The following screenshot is an example of a concatenated certificate chain:
Concatenated certificate chain.png
This concatenated certificate chain consists of:
  • A signed client certificate (provided by the certificate authority)
  • An intermediate certificate authority (who directly issued the signed client certificate)
  • A root certificate authority (who issued the intermediate certificate authority’s certificate).
These certificates should appear in descending order within the file (client, intermediate, root).
When you receive the concatenated certificate chain, use it to replace the existing unsigned or expired certificate chain. To do this:
  1. Run the Manage Private Keys task.
  2. Double-click the private key for the certificate to open the properties dialog.
  3. Click
    Replace Certificate Chain
    , and then select the certificate chain to use.
  4. Restart all nodes in the Gateway cluster.
Creating PKCS#12 Key Archives
You can combine a signed certificate and its private key outside of the Gateway, for use in non-Gateway applications. To do this, use the OpenSSL tool that is shipped with the Gateway appliance.
A single command can be used to combine a key and certificate into a useable PKCS#12 key archive:
To combine the key and certificate to produce a PKCS#12 archive, run this OpenSSL command:
openssl pkcs12 –export –in client.pem –inkey client.key –certfile chain.pem –out client.p12
Provide a password when prompted. This secures the private key and its accompanying certificates.
Once the PKCS#12 file is created, import the private key and its certificate into the Gateway. For detailed instructions, see Import a Private Key.
Specifying Special Purposes for a Key
You can designate that a private key has a special purpose within the Gateway. Each purpose serves a specific need, to facilitate certain functionalities. For example, you designate a key as the default SSL key or default CA key.
For detailed instructions, see the "Mark as Special Purpose" setting in the Private Key Properties.