To create a signed certificate
1. Generate a new certificate for use with the SSL protocol’s public key encryption. The key pair includes:
◦ A public key, published in the certificate
◦ A private key, accessible only by the Integrity Lifecycle Manager Agent
The following example assumes the current directory is the root directory of the Integrity Lifecycle Manager Agent:
% jre/bin/keytool -genkeypair -alias myname -storetype PKCS12
-keystore data/tls/certificate.p12 -keyalg RSA
where
◦ -genkeypair specifies to generate a new key pair.
◦ -alias specifies a name to associate with the new key entry in the keystore.
|
|
Ensure the alias name you specify is written down or memorable because you need to specify it again in the later steps of this procedure.
|
◦ -storetype specifies the format of the keystore. The format must be PKCS12. The certificate cannot be read from any other type of keystore.
◦ -keystore specifies the pathname to the keystore.
|
|
At command run, you are prompted to specify additional information, such as the keystore and certificate passwords. The passwords are identical, and must also be specified in the mksagent.privatekey.password property of the agent.properties file. For more information on presented prompts, consult the keytool documentation.
|
◦ -keyalg prevents any conflicts with higher strength keys. The format must be RSA.
2. Generate a Certificate Signing Request (CSR), and then send the request to a CA, for example:
% jre\bin\keytool -certreq -alias myname -storetype PKCS12
-keystore data\tls\certificate.p12
-file data\tls\certificate.csr
where
◦ -certreq specifies to generate a CSR.
◦ -alias specifies the name of an existing entry in the store to use to create a CSR. This name is the name specified in step 1.
◦ -file specifies the path of the file to write the CSR to.
The CSR must include the following information:
◦ Keystore password
◦ First and last name (this should be the fully qualified domain name of the host machine)
◦ Organizational unit/department name
◦ Organization name
◦ City or locality
◦ State or province
◦ Two-letter country code (for example, CA or US)
◦ Key pair password (if different from keystore)
3. When retrieving the signed certificate from the CA, ensure that it is in one of the following formats:
◦ DER encoded binary X.509 (.der / .cer)
◦ Base-64 encoded X.509 (.pem / .cer)
◦ PKCS #7 Certificate (.p7b)
If possible, ensure that all certificates in the certification path are in this format.
If custom Root CAs or custom Intermediate CAs (in the case of Verisign) are being used, do one of the following:
◦ Import the custom Root CA or custom Intermediate CA certificates into the cacerts keystore:
jre/bin/keytool –importcert –alias <alias> -storetype PKCS12
–keystore data/tls/certificate.p12 –file <custom_ca_certificate>
◦ Obtain a PKCS #7 Certificate (.p7b) when the signed server certificate is retrieved.
4. If any custom Root CAs or custom Intermediate CAs were used, import them into the jssecacerts keystore of the Integrity Lifecycle Manager Agent’s JRE environment, for example:
% jre/bin/keytool –importcert –alias <alias>
–keystore <Integrity Agent installdir>
/jre/lib/security/jssecacerts –file <custom_ca_certificate>
|
|
• This command prompts for a keystore password. If the jssecacerts keystore does not exist, you can specify any password as the initial password. For future references, write down the password in a safe location.
• If the Certification Authority (CA) has updated its own Root CA certificate or Intermediate CA certificates, they must be added to the jssecacerts keystore. Due to the method which Java uses to locate keystores, all relevant CA certificates must be present in the jssecacerts keystore.
|
5. When you receive the certification, import the certificate into the keystore, for example:
% jre\bin\keytool -importcert -alias myname -storetype PKCS12
-keystore data\tls\certificate.p12
-file data\tls\certificate.pem
where
◦ -importcert specifies to import the certificate response.
◦ -alias specifies the name of the existing entry from which to import. This name is the name specified in step 1.
◦ -file specifies the path from which to read the CA response.
6. If any custom Root CAs or custom Intermediate CAs were used, they must be imported into the jssecacerts keystore of the JRE environment for all Integrity Lifecycle Manager servers. Ensure that the custom Root CAs or custom Intermediate CAs are imported before connecting to the Integrity Lifecycle Manager Agent.
For example:
% <Integrity server installdir>/jre/bin/keytool –importcert –alias <alias>
–keystore <Integrity server installdir>/jre/lib/security/jssecacerts
-file <custom_ca_certificate>
Alternately, you can distribute the jssecacerts keystore on the Integrity Lifecycle Manager Agent to each Integrity Lifecycle Manager server instead of importing the certificates. Copy the jssecacerts keystore to <Integrity server installdir>/jre/lib/security and restart the Integrity Lifecycle Manager server.
7. Ensure that SSL is in effect by checking:
<Integrity Agent installdir>/config/properties/security.properties
If SSL is in effect, the security policy key mks.security.policy.scheme should indicate that a private security policy is being used.
|
|
The security policy key is not set automatically. The system is not secure for all user interfaces until you set a security policy that uses _private.
|
