2.1 Prerequisites

Before using the Entrust CA to issue certificates through MyID you must install and configure the following software components on the MyID application server:

You will also need the following information and files in order to configure MyID to use the Entrust CA:

2.1.1 Unlimited strength crypto policy

The Java Cryptography Extension is provided with the latest version of the JDK and JRE.

To configure the extension, you must edit the java.security file and make sure that the crypto.policy security property to unlimited.

Depending on the version of Java you are using, the java.security file is in the following folder:

<java-home>\lib\security

or:

<java-home>\conf\security

For example:

C:\Program Files\Eclipse Adoptium\jdk-11.0.14.101-hotspot\conf\security

The java.security file should contain:

crypto.policy=unlimited

Depending on the version of Java, the file may already contain the following:

#crypto.policy=unlimited

In this case, remove the # to remove the comment from the line.

2.1.2 Entrust ESSC

Entrust ESSC connector has been superseded by the Entrust Authority Security Toolkit for the Java Platform. If you are upgrading an existing MyID installation that uses the old Entrust interface, contact Intercede support for advice.

2.1.3 Before you install MyID

Before you install MyID, you must copy the following files from the Entrust Admin Toolkit:

Copy the files to the following folder on the MyID application server:

Windows\System32

2.1.4 Java Environment

To enable the Java Interface between MyID and the Entrust server to function correctly, all the .JAR files must be in the same location on the MyID application server. You have two options:

2.1.4.1 Check the Path variable

You must check that the Path environment variable on the MyID application server contains both the location of the client jvm.dll file and its parent folder.

Important: If you update your version of Java, you must check the Path environment variable again, and update it if necessary.

  1. Log on to the MyID application server as an account with administrative rights.
  2. From the Windows Control panel, select System.
  3. Click Advanced system settings.
  4. Click Environment Variables.
  5. From the list of System variables, select Path.
  6. Click Edit.

  7. Check that the full path of the folder containing the client jvm.dll file is included in the Path variable.

    For example:

    C:\Program Files\Eclipse Adoptium\jdk-11.0.14.101-hotspot\bin\client

    If this folder is not present in the path, add it.

  8. Check that the path of the parent folder of the folder containing the client jvm.dll file is included in the Path variable.

    For example:

    C:\Program Files\Eclipse Adoptium\jdk-11.0.14.101-hotspot\bin

    If this folder is not present in the path, add it.

    Note: Make sure the paths are correct. If the paths are entered incorrectly, or are missing, you may experience errors, or you may experience a loss of functionality as the failure to find the jvm.dll file causes a silent failure.

    You must make sure that there are no spaces after the semicolons that delimit the entries in the path variable.

    For example:

    <Paths>;C:\Program Files\Eclipse Adoptium\jdk-11.0.14.101-hotspot\bin\client;C:\Program Files\Eclipse Adoptium\jdk-11.0.14.101-hotspot\bin;<More paths>

  9. Click OK to save any changes you have made to the path.
  10. Click OK to close Environment Variables.
  11. Click OK to close System Properties.
  12. Restart the server.

2.1.5 Issuing Certificates to users that do not exist in the directory

If you want to issue certificates to users that do not exist in the directory, make sure you have set the noUserInDirectory=1 setting for the certificate policies you want to issue.

If you do not set this, and attempt to issue a certificate to a user who does not exist in the directory, Entrust displays an error with the code -2976.

This setting can be found in the master.certspec file on the CA. See your CA documentation for the procedure for updating this file.

2.1.6 Certificate lifetime

Previously, when requesting a certificate from Entrust, if the lifetime associated with the original (not the new) request had expired or was less than the minimum time the CA will allow (12 hours), Entrust reported an error that the signing/encryption date was not long enough. The MyID Entrust connector now resets the insufficient date (while still remaining within the card lifetime), allowing MyID to request the new certificates.

The Entrust errors reported by this issue were -2768 or -2767. These errors should now occur only in the correct situations, where you are attempting to request a certificate with a lifetime less than the minimum allowed. This situation may occur, for example, if you are requesting a certificate that is constrained to the lifetime of a card that has less than 12 hours left on its lifetime.

2.1.7 Certificate revocation list

The MyID application server must be able to communicate with the Certificate Revocation List (CRL) location. The CRL is checked for validity whenever MyID connects to the CA.

2.1.8 Multiple Entrust digital identities with a single Luna SA HSM

It is possible for a toolkit application to support multiple Entrust digital identities concurrently with a single Luna SA HSM.

For more information, see the Entrust note reference TN7074.

One example could be two servers, Server1 and Server2 that require separate identities on the same Luna SA. In this case two partitions could be created on the Luna SA: PartitionA and PartitionB. PartitionA would then be assigned to Server1 and PartitionB would be assigned to Server2. When Server1 contacts the Luna SA through PKCS #11, PartitionA will be exposed as a single slot visible on the Luna SA. Similarly Server2 will see one slot, as PartitionB will be exposed to it. Each server based application can then create and log in to separate identities hosted on different partitions on the Luna SA.

In the case of multiple partitions assigned to a single client, for example if Server1 has both PartitionA and PartitionB assigned to it:

The clients will see multiple slots. The ckdemo tool can be used to verify how many slots are exposed.

The Java based clients would just pick the desired slot and attempt to log in to the identity on that particular slot.

The Administration Toolkit for C would take the profile name that is specified and cycle through the slots until it finds the correct identity. The profile name (.tkn entry) should be the concatenation of the "Entrust Path" and "Entrust User" data blobs from the LunaSA with ".tkn" appended. A Windows based example could be something like "d:\\test\\admintk\\luna_officer_wf.tkn".

2.1.9 Certificate content

In some circumstances, it is possible that, for a given user, the contents of certificates will be controlled by the Entrust policy; attributes may appear in certificates that you are not expecting. To prevent this, make sure that any unwanted extensions are explicitly blocked in the certificate policy configuration on the CA; use the SMA UI or another Entrust tool to enforce the Subject Alternative Name content.

2.1.10 Entrust user DN ordering

Entrust user DN ordering and MyID DN ordering should where possible be aligned through the use of the Reverse DN setting for each Entrust certificate policy in the CA workflow. A typical user's ordering reflects the CA's own DN ordering.

For example, for a CA whose DN is in the form:

ou=MyEntrustCA,ou=PKI,ou=CA,dc=mydomain,dc=local

Users (known to the CA) would be in the form:

cn=Arthur Alpha,ou=MyEntrustCA,ou=PKI,ou=CA,dc=mydomain,dc=local

However, for PIV issuance, where the form is:

dc=local, dc=mydomain, ou=CA, ou=PKI, ou=MyEntrustCA, cn=Arthur Alpha

Or in the alternative noUserInDirectory case:

C=US, o=U.S. Government, ou=Department of Administration, cn=Arthur Alpha

That means setting the Reverse DN flag to true.

Note: MyID does not recognize this option when using the Issue Card workflow to issue a card.