Single Sign-On Service › SSO Getting Started Guide › SSO Using Advanced Authentication and Provisioning for a Sensitive Application › Configure an IdP to SP Partnership › Import Keys and Certificates into the Certificate Data Store

Import Keys and Certificates into the Certificate Data Store

Private keys and certificates are required for the following tasks:

• Federation components use private key/certificate pairs for signing, verification, encryption, and decryption of entire assertions, or specific assertion content.
• Federation components employ client certificates for back-channel authentication for artifact single sign-on.
• For establishing SSL connections (SSL server certificates).

Private key/certificate pairs and single certificates for federation functions are stored in the certificate data store (CDS). The certificate data store is collocated with the policy store. All Policy Servers that share a common view into the same policy store have access to the same keys, certificates, CDS-configured certificate revocation lists (CRL), and OCSP responders.

SSL server certificates are stored on the web server where they are installed. SSL server certificates are not stored in the certificate data store.

Each key/certificate pair, client certificate, and trusted certificate in the certificate data store must have a unique alias. The alias allows any private key/certificate pair or single certificate in the certificate store can to be uniquely referenced. The certificate data store can store multiple key/certificate pairs and single certificates. In a federated environment, you can have multiple partners. For multiple partners, you can use a different pair for each partner.

If a signing alias is configured for signing assertions, the assertion generator uses the key that is associated with that alias to sign assertions. If no signing alias is configured, the assertion generator uses the key with the defaultenterpriseprivatekey alias to sign assertions. If the assertion generator does not find a default enterprise private key, it uses the first private key it finds to sign assertions.

Important! If you are going to store multiple keys, define the first key that you add with the defaultenterpriseprivatekey alias before adding subsequent keys.

A given Policy Server can sign or sign and verify responses. You can add keys and certificates for signing and validation to the same certificate data store.

You manage the contents of the certificate data store using the CSP console.

The following types of key/certificate pairs and single certificates are stored in the certificate data store:

If you do not have a key/certificate pair in the certificate data store, you have two options:

• Import a key/certificate pair from an existing file (.p12 or .pfx).
• Generate a key/certificate pair.

  To generate a new key/certificate pair, request a certificate from a trusted Certificate Authority and then import the signed certificate response that the authority returns.

For more information about key and certificate management, see the CA SiteMinder® Policy Server Configuration Guide.

Import a Key/Certificate Pair from an Existing File

If you do not have a key/certificate pair in the certificate data store, import one from an existing .p12 or .pfx file.

The Policy Server treats an imported certificate as a trusted certificate. The exceptions are self-signed certificates, which get treated according to the following guidelines:

• The Policy Server identifies a V3 self-signed certificate as a CA certificate. In this case, it treats it as a CA certificate. This behavior occurs even though you initiate the import from the Certificate/Private Key dialog.
• The Policy Server treats the certificate as a trusted certificate when:
  • The Policy Server does not identify a V3 self–signed certificate as a CA.
  • The certificate is a V1 self–signed certificate.

Follow these steps:

1. Log in to the CSP console.
2. Select Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
3. Click Import New and follow the wizard.
4. Be aware of the following items as you complete the wizard:
   • You can import a single file with a key and certificate in it or separate key and certificate files. Select the appropriate option button for the file you are using.
   • To import a self-signed certificate as a Certificate Authority certificate, set the Use as CA option button to Yes. The certificate is imported as a CA certificate and is not available for when configuring partnerships (for example, for signing or encryption).

     Otherwise, accept the default No setting to import the certificate as a trusted certificate that is available when configuring partnerships.

   • For a trusted certificate file in DER (binary) format, the file can contain one or more certificate entries. For a trusted certificate file in PEM (base 64) format, expects one certificate per file is required.
   • If you are using a .p12 file, you are required to fill in a password.
   • For each entry you plan to add to the certificate data store, enter the alias you want to associate with that entry. If you select multiple entries, each requires a unique alias.
5. At the Confirm step, review the information and click Finish.

The key/certificate pair is imported into the certificate data store.

How to Generate a Key/Certificate Pair

If you do not have a key/certificate pair in the certificate data store, you can generate a new key/certificate pair.

Follow these steps:

1. Generate a certificate request and send the request to a trusted Certificate Authority.
2. Import the signed certificate response from the authority.

Generate a Certificate Request

If you do not have a key/certificate pair in the certificate data store, request one from a trusted Certificate Authority. When the CA returns a signed certificate response, import it into the certificate data store.

When you generate a certificate request, the Policy Server generates a private key and a self–signed certificate pair. The Policy Server stores this pair in the certificate data store. Using the generated request, contact a Certificate Authority and fill out the CA certificate request form. Paste the contents of the generated request into the form.

The CA issues a signed certificate response, usually in PKCS #7 format. You can import the signed certificate response into the certificate data store. After the signed certificate response is imported, the existing self–signed certificate entry of the same alias is replaced.

Follow these steps:

1. Log in to the CSP console.
2. Select Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
3. Click Request Certificate.
4. Complete the required fields.
5. Click Save.

A file that conforms to the PKCS #10 specification is generated.

The browser prompts you to save or open the file, which contains the certificate request. If you do not save this file (or open it and extract the text), the Policy Server still generates the private key and self–signed certificate pair. To get a new request file for the private key, generate a new certificate signing request using the Generate CSR feature.

Import a Signed Certificate Response

After completing a certificate request and sending it to the Certificate Authority, the Certificate Authority issues a signed certificate response.

Import the signed certificate into the certificate data store to replace the existing self-signed certificate entry of the same alias.

Follow these steps:

1. Select Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
2. In the list, locate the self-signed certificate that you want to update.
3. Select Action, Update Certificate next to the self-signed entry.
4. Browse to the file you want. You can use a:
   • .p7 or .p7b file that contains the signed certificate and the corresponding certificate chain.
   • .cer or .crt file (base64 PEM file) with the signed certificate without the certificate chain.
5. Select the appropriate entry.
6. Review the certificate information and click Finish.

The signed certificate is imported into the certificate data store and the self-signed certificate is replaced.

Generate a New Certificate Signing Request

A certificate signing request (CSR) is a message that you send to a Certificate Authority to apply for a digital identity certificate. After you create a private key, you can generate a CSR. The CSR contains the public key.

You can generate a new CSR for a self-signed or CA-signed private key/certificate pair. The private key always generates an identical CSR without modifying the existing private key. You generate a new request for an existing private key for the following reasons:

• You no longer have the original request that was generated for the private key/self-signed certificate pair.
• You need a new certificate for an expiring one, which requires a new copy of a CSR to submit to a Certificate Authority.

Follow these steps:

1. Log in to the CSP console.
2. Select Infrastructure, X509 Certificate Management, Trusted Certificates and Private Keys.
3. Select Action, Generate CSR for the private key entry for which you want a new CSR.

   A file that conforms to the PKCS #10 specification is generated.

4. Save the CSR when prompted.
5. (Optional) If you require a CA-signed certificate, contact a Certificate Authority. Follow the procedure the Certificate Authority requires for submitting a request. Use the PKCS#10 file you saved in the previous step for the request.

After you complete the certificate request process, the Certificate Authority issues a signed certificate response that you import into the certificate data store. The Policy Server replaces the existing certificate entry of the same alias with the newly imported certificate.

Update Certificates in the Certificate Data Store

You can update key/certificate pairs and standalone certificates in the following ways:

• Update an expiring trusted certificate by deleting the existing certificate and importing a new trusted certificate. The new certificate must match the expiring certificate in the certificate data store.
• Update the certificate by importing a signed trusted certificate or a PKCS7-signed response. The new certificate must match the expiring certificate in the certificate data store.
• Update a certificate with a certificate from a PKCS#12 file. The new private key and certificate pair must match the expiring key/certificate pair in the certificate data store.

The new certificate must be valid before the Policy Server can use it to update an expiring certificate. Certificates are updated and become available immediately after they are imported. If the new certificate is not valid, as determined by its validity interval, the Policy Server cannot use the new certificate.

For importing only a trusted certificate, use a file containing the certificate in a PEM or DER encoding. The standard extension for files of these types is *.crt or *.cer. If the file ends in .p12 or .pfx, it is processed as a certificate data store file containing key/certificate pairs. Finally, if a file ends in .p7 or .p7b, it is processed as a signed response file. Anything else is treated as a certificate file, and CA SiteMinder® tries to load a certificate from it.

Note: If you update certificates for a federated environment, you do not have to update any federation objects that use the expiring certificates.