Key/certificate pairs and trusted certificates affect a number of federated SSO and other functions. To execute tasks that use keys and certificates, these items must be in the certificate data store.
If you do not have a key/certificate pair in the certificate data store, you have two options:
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.
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:
Follow these steps:
Otherwise, accept the default No setting to import the certificate as a trusted certificate that is available when configuring partnerships.
The key/certificate pair is imported into the certificate data store.
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:
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:
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.
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:
The signed certificate is imported into the certificate data store and the self-signed certificate is replaced.
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:
Follow these steps:
A file that conforms to the PKCS #10 specification is generated.
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.
You can update key/certificate pairs and standalone certificates in the following ways:
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.
Copyright © 2014 CA.
All rights reserved.
|
|