This section describes how to install, configure, and use Reflection to operate within the Department of Defense (DOD) or other Public Key Infrastructure (PKI) environment. PKI configuration affects both Secure Shell and SSL/TLS connections.
Running Reflection in DOD PKI mode
By default, Reflection applications allow some configurations that do not meet DOD PKI requirements. Administrators can use Reflection Group Policies to configure all Reflection sessions to meet DOD PKI requirements.
To configure DOD PKI mode
Run the Group Policy Editor using one of the following techniques:
On the command line, enter Gpedit.msc
-or-
In the Active Directory Users and Computers console, open the properties for an Organizational Unit, click the Group Policy tab, and edit or create a new policy object.
Install the Reflection template (ReflectionPolicy.adm) if you have not already done so.
NOTE:For information about how to download and install the Reflection policy template, see Knowledge Base Article 7021501.
Under Local Computer Policy > User Configuration > Administrative Templates > Reflection Settings, disable the setting Allow non-DoDPKI mode.
Configuring DOD PKI mode has the following effects.
You must configure Reflection to use either CRL A digitally signed list of certificates that have been revoked by the Certification Authority. Certificates identified in a CRL are no longer valid. checking or an OCSP A protocol (using the HTTP transport) that can be used as an alternative to CRL checking to confirm whether a certificate is valid. An OCSP responder responds to certificate status requests with one of three digitally signed responses: "good", "revoked", and "unknown". Using OCSP removes the need for servers and/or clients to retrieve and sort through large CRLs. responder. In DOD PKI mode, the option to use neither form of checking is disabled. (For SSH connections, certificate revocation is configured using the PKI tab of the Secure Shell settings dialog box. For SSL/TLS connections it is configured using the PKI Configuration dialog box.)
Reflection enforces FIPS-approved encryption algorithms. For SSH connections, this means that only FIPS-approved options are available on the Encryption tab of the Secure Shell settings dialog box. For SSL/TLS connections this means that you cannot set Encryption strength to 40 Bits or 56 Bits.
For a connection to succeed, the certificate host name must exactly match the host name specified for your Reflection connection. This means that the setting Certificate must match host name being contacted is automatically selected and cannot be modified. (For SSH connections, this setting is configured using the PKI tab of the Reflection Secure Shell Settings dialog box. For SSL/TLS connections it is configured using the PKI Configuration dialog box.)
Intermediate CA certificates signed using the MD2 or MD5 hash are not supported for certificate validation.
Installing and Removing Trust Points
A trust point is any CA A server, in a trusted organization, which issues digital certificates. The CA manages the issuance of new certificates and revokes certificates that are no longer valid for authentication. A CA may also delegate certificate issuance authority to one or more intermediate CAs creating a chain of trust. The highest level CA certificate is referred to as the trusted root. certificate in a chain of trust.
To add a trust point to the Reflection certificate store:
Click the Trusted Certificate Authorities tab.
Click Import, then browse to locate a certificate (typically *.cer or *.crt).
To remove a trust point from the Reflection certificate store,
Click the Trusted Certificate Authorities tab.
Select the certificate and click Remove.
NOTE:
Intermediate CA trust points can be retrieved from an LDAP A standard protocol that can be used to store information in a central location and distribute that information to users. or HTTP server which may be identified by explicit URIs defined in the Authority Information Access (AIA) extension of a certificate, or using LDAP server information configured on the LDAP tab of the Reflection Certificate Manager. These certificates are stored in the cert_cache file located in either <My Documents>\Micro Focus\Reflection\.pki or \%programdata%\Micro Focus\Reflection\.pki
When Reflection is running in DOD PKI mode, only those root certificates you have added to the Reflection Certificate manager are used. There is no need to remove any non-DOD PKI certificates that may be present in the Windows Certificate Store.
Configuring Certificate Revocation Checking
Reflection's default value for certificate revocation checking is based on your current system setting. If your system is configured to do CRL checking, Reflection sessions will check for certificate revocation using CRLs A digitally signed list of certificates that have been revoked by the Certification Authority. Certificates identified in a CRL are no longer valid. by default. You can also configure Reflection to use an OCSP A protocol (using the HTTP transport) that can be used as an alternative to CRL checking to confirm whether a certificate is valid. An OCSP responder responds to certificate status requests with one of three digitally signed responses: "good", "revoked", and "unknown". Using OCSP removes the need for servers and/or clients to retrieve and sort through large CRLs. responder.
Reflection also supports a setting to disable CRL checking. You may want to use this setting for testing purposes, however this option is not available if Reflection is running in DOD PKI mode.
CAUTION:Disabling CRL checking compromises your security. Use this option only for testing purposes.
You can define one or more LDAP A standard protocol that can be used to store information in a central location and distribute that information to users. servers from which to retrieve intermediate certificates or CRLs.
To define an LDAP server
Click the LDAP tab.
Click Add, then specify the server using the following URL format:
ldap://hostname:portnumber
For example:
ldap://ldapserver.myhost.com:389
To configure OCSP
You can define one or more OCSP servers from which to request certificate revocation information.
Set Certificate Revocation to Use OCSP. (For SSH connections use the PKI tab of the Secure Shell settings dialog box. For SSL/TLS connections use the PKI Configuration dialog box.)
NOTE:OCSP responder URLs required by a certificate are identified in the AIA extension of the certificate. If this information is not provided in the certificate, you can use the following steps to configure OCSP responder information.
Click the OCSP tab.
Click Add, then specify the server using the following URL format:
URL:portnumber
For example:
https://ocspmachine.host.com:389
Using Uniform Resource Identifiers for DOD PKI Services
Reflection supports the use of URIs A string of characters that represents the location or address of a resource. URIs can be used to locate resources on the Internet or on an LDAP server. for automatic CRL A digitally signed list of certificates that have been revoked by the Certification Authority. Certificates identified in a CRL are no longer valid. updating and retrieval. As defined in section 4.2.1.14 of RFC3280.
If CRL checking is enabled, Reflection checks for certificate revocation as follows:
Check the crl_cache file for valid revocation information. If none is found, continue on to step 2.
Check the CDP extension in the certificate for HTTP or LDAP URIs and query these in the order specified (first HTTP, then LDAP). If the certificate is found to be revoked, close the connection. If the certificate is not found continue on to step 3.
If one or more LDAP servers is specified in the Reflection Certificate Manager LDAP tab, assemble the Distinguished Name for the CA listed in the Issuer extension of the certificate and query for the CRL file. If the certificate is not found to be revoked in any CRL, continue to the next validation step.
Updates for expired CRLs are handled automatically, and do not require administrator intervention or configuration.
If OCSP checking is enabled, Reflection always checks all available OCSP responders to ensure that the connection will fail if any of these responders knows that the certificate has been revoked. For the connection to succeed at least one OCSP responder must be available and return a value of 'good' for the certificate status. Reflection performs these checks as follows.
Check the AIA extension in the certificate for one or more OCSP responders and query each of those responders. If the status of the certificate comes back as 'revoked' from any responder, close the connection.
Check for one or more user configured OCSP responders specified using the Reflection Certificate Manager OCSP tab and query each of those responders. If the status of the certificate comes back as 'revoked' from any responder, close the connection.
If all responders returned 'unknown' close the connection. If a 'good' response was returned from at least one of the queried OCSP responders continue on to the next validation step.
Using URIs to Retrieve Intermediate Certificates
As defined in section 4.2.2.1 of RFC3280, Reflection can use URIs A string of characters that represents the location or address of a resource. URIs can be used to locate resources on the Internet or on an LDAP server. to retrieve intermediate CA A server, in a trusted organization, which issues digital certificates. The CA manages the issuance of new certificates and revokes certificates that are no longer valid for authentication. A CA may also delegate certificate issuance authority to one or more intermediate CAs creating a chain of trust. The highest level CA certificate is referred to as the trusted root. certificates as follows:
Check the cert_cache file for the required intermediate certificate. If it is not found, continue on to step 2.
If either HTTP or LDAP URIs are defined in the Authority Information Access (AIA) extension of a certificate, attempt to use these (first HTTP, then LDAP) to retrieve intermediate CA certificates.
If the preceding attempts fail, assemble a Distinguished Name from the issuing certificate's Subject Name, and queries the defined LDAP server for the contents of the CACertificate attribute.
Because Reflection does not enforce the security policy extension of a certificate, security policy configuration is not necessary.
Configuring and Protecting Certificates and Private Keys
To configure client authentication using certificates:
On the Personal tab, click Import, then browse to locate a certificate (typically *.pfx or *.p12). You will be prompted to create a passphrase that will be required any time this key is used. Entering a passphrase is advisable to help protect this key on your system.
For Secure Shell connections, open the Reflection Secure Shell Settings dialog box, click the User Keys tab and select the certificate(s) you want to use for client authentication to the currently specified host. (This step is not required for SSL/TLS connections.)
Private Key Safeguards
If a client private key is stolen, a malicious user can gain access to files on any servers accessible to that user. To minimize this risk, each client user should always protect his or her private key with a passphrase. This ensures that only someone who knows the passphrase can authenticate with that key. Users should create and protect passphrases following the password specifications in your organization’s Security Policy.
Actions to Take if a Key is Compromised
Consider a private key compromised if it has become available to any unauthorized entity, or if you have reason to distrust the actions of any person who has access to the key.
If the client key is compromised, revoke the client certificate.
To replace a compromised key:
Generate a new private key and certificate and import the key into the Reflection Certificate Manager.
On the server, update the map file line for this client if the identifying information has changed.
To remove the compromised key from the client computer:
Remove the key from the Personal tab of the Reflection Certificate manager. This removes this key from the identity_store.p12 file.
If the original file containing the old key and certificate (*.pfx or *.p12) is still on the client computer, use a DOD-approved file erasure utility to delete this file.