A certificate from a certificate authority (CA) is commonly referred to as trusted root. A trusted root is a trusted certificate, or the certificate of a known CA. These certificates are self-signed and are recognized as representing a CA that is trusted. To validate a digital signature, you must trust at least one of the certificates in the user or server’s certificate chain. You can directly trust the certificate of the user or server, or you can choose to trust any other certificate in the chain. Typically, the certificate that is trusted is the root CA’s certificate.
In the Administration Console, click Security > Trusted Roots.
Select form the following actions:
Import: Allows you to import trusted roots so that Access Manager devices can trust the certificate sent by other computers at runtime. For more information, see Section 3.4.1, Importing Public Key Certificates (Trusted Roots).
Delete: To delete a trusted root, select the trusted root, then click Delete.
Auto Import From Server: To import a trusted root from another server, click Auto Import From Server. For more information, see Section 3.4.2, Auto-Importing Certificates from Servers.
You import trusted roots so that the specific device can trust the certificate sent by other computers at runtime. After you import a trusted root, you can assign it to the proper trust store associated with a device, which allows the device to trust certificates signed by the trusted root.
In the Administration Console, click Security > Trusted Roots.
Click Import, then specify a name for the certificate.
This is a system-wide, unique name used by Access Manager Appliance.
Select one of the following methods to import the public key:
Certificate data file (DER/PEM/PKCS7): Select this method to browse to a file. Click Browse to locate the file on your file system.
Certificate data text (PEM/Base64): Select this method to paste Base64-encoded certificate data text.
Click OK.
You can import certificates from other servers (such as an LDAP server, an identity provider, or service provider) and make them available for use in Access Manager Appliance. You must provide the IP address, port, and certificate name.
In the Administration Console, click Security > Trusted Roots > Auto-Import from Server.
Fill in the following fields:
Server IP Address: Specify the server IP address. You can use a DNS name.
Server Port: Specify the server port.
Certificate Name: Specify a unique name of the certificate to store in Access Manager.
Click OK.
You can export a trusted root or a public key certificate to a file so that a client can use it to verify the certificate chain sent by a cryptography-enabled application, or to have a backup copy of the file.
You can export the certificate in the following formats:
DER-encoded (.der) to a file.
PEM-encoded to a file. This is a Base64-encoded DER certificate that is enclosed between BEGIN CERTIFICATE and END CERTIFICATE tags.
PEM CUT/Paste Buffer. This displays the certificate data so you can copy it to the system Clipboard. You can then pasted it directly into a cryptography-enabled application.
To export the public certificate:
In the Administration Console, click Security > Trusted Roots.
Click the name of the trusted root.
On the Certificate Details page, click Export Public Certificate, then click the file type.
Save the output file.
In the Administration Console, click Security > Trusted Roots.
Click the name of a trusted root.
View the following information:
|
Field |
Description |
|---|---|
|
Issuer |
The name of the CA that created the certificate. |
|
Serial number |
The serial number of the certificate. |
|
Subject |
The subject name of the certificate. |
|
Valid from |
The first date and time that the certificate is valid. |
|
Valid to |
The date and time that the certificate expires. |
|
Key size |
The key size that was used to create the certificate. |
|
Signature algorithm |
The signature algorithm that was used to create the certificate. |
|
Finger print (MD5) |
The certificate's message digest that was calculated with the MD5 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely identify a certificate. For example, users can verify that a certificate is the one they think it is by matching this published MD5 fingerprint with the MD5 fingerprint on the local certificate. |
|
Finger print (SHA1) |
The certificate's message digest that was calculated with the SHA1 algorithm. It is embedded into the certificate at creation time. It can be used to uniquely identify a certificate. For example, users can verify that a certificate is the one they think it is by matching a published SHA1 fingerprint with the SHA1 fingerprint on the local certificate. |
The Subject Alternate Names section indicates whether an application should reject the certificate if the application does not understand the alternate name extensions. Any configured alternate names are displayed in the list.
The Key Usage section indicates whether an application should reject the certificate if the application does not understand the key usage extensions. The following are possible:
Sign CRLs: Indicates whether the certificate is used to sign CRLs (Certificate Revocation Lists).
Sign certificates: Indicates that the certificate is used to sign other certificates.
Encrypt other keys: Indicates that the certificate is used to encrypt keys.
Encrypt data directly: Indicates that the certificate encrypts data for private transmission to the key pair owner. Only the intended receiver can read the data.
Create digital signatures: Indicates that the certificate is used to create digital signatures.
Non-repudiation: Indicates that the certificate links a digital signature to the signer and the data. This prevents others from duplicating the signature because no one else has the signer’s private key. Additionally, the signer cannot deny having signed the data.
CRL Distribution Points: Displays a list of Certificate Revocation List (CRL) distribution points that are embedded into the certificate as an extension at certificate creation time. Implementations search the CRL from each distribution point (the distribution point is usually a URI that points to a store of revoked certificates) to see whether a certificate has been revoked.
Authority Info Access (OCSP): Displays a list of Online Certificate Status Protocol (OCSP) responders that are embedded into the certificate as an extension at certificate creation time. Implementations query the OCSP responder to see whether a certificate has been revoked.
Export Public Certificate: Allows you to export a trusted root to a file so that a client can use it to verify the certificate chain sent by a cryptography-enabled application. For more information, see Section 3.3.4, Exporting a Public Certificate.
Click Close.