Client certificates

This section discusses how to require a Luna Network HSM 7 appliance to verify the full Distinguished Name of a registered Client, rather than just the Common Name, when validating an NTLS connection.

Prior to Luna Network HSM 7 version 7.8.4, NTLS client connections were validated against the Common Name (CN) field of the Distinguished Name (DN). The value for that field can be freely chosen, which can limit your organization's ability to strictly validate a given client.

From version 7.8.4 onward, the Luna Network HSM 7 provides the ability to have NTLS use the other attributes in the Distinguished Name (DN) field of the client certificate. The Distinguished Name is a set of key value pairs called RDN (Relative Distinguished Name) that uniquely identifies an entity holding the certificate. These attributes include:

>"C", (Country)

>"DC", (domain component - An individual attribute of the Domain Name. For example, DC=hsm, DC=thales, DC=com)

>"CN", (common name)

>"SN", (surname or family name)

>"GN", (given name)

>"ST", (state or province

>"T", (title)

>"O", (organization name)

>"OU", (organizational unit name)

>"serialNumber",

>"L", (locality)

>"emailAddress", (email address)

>"initials", (initials)

>"pseudonym", (pseudonym)

Acceptable input values are "a-zA-Z0-9_@.-" and spaces between values.

Commands are added to the Luna Shell (lunash) to implement this ability for NTLS (STC is not affected). On the Client side, no changes are made in this regard, as a client certificate can be created to match the server-side requirement (which is imposed as a filter when NTLS verifies a presented client certificate), and any deviation simply fails to authenticate.

The assignment operation is permitted only for an already registered client, thus the implication is that the Client certificate is created first, and then the DN filter in the HSM appliance is added, to match the configuration of the certificate. If you attempt to assign a DN filter for a client that is not registered, the system simply responds with "Error: Client not found".

Caveats

>The configured DN filter must be an exact match to the configuration of the client certificate, with the same RDNs in the same order.

>Only one DN filter can be configured per client.

>Multi-valued RDNs are not permitted.

>NTLS IP check validation is performed after the DN validation, and only if the DN validation is successful.

>Assigning a DN filter for a client, where a DN filter already exists, overwrites the current filter. You are warned what is about to happen and prompted to "proceed" or "quit", unless the -force option is used.

Workflow

1.Register a client with NTLS (client register).

2.Configure a DN filter for a client client dn assign.

3.Upon receiving a connection request, NTLS checks if a DN filter is configured for that client.

4.If a DN filter is configured, that filter is validated against the DN in the incoming client certificate.

5.If a DN filter is not configured, then NTLS resorts to using the CN field value in the client certificate to validate the connection.

To show a DN filter for a Client

To see if a DN filter already exists for a registered client, and if one exists, to show its content, use the client dn show command.

To add/assign a DN filter to a client

To add/assign a DN filter to a registered client, if one does not already exist, use the client dn assign command.

To delete a DN filter assigned to a client

To delete a DN filter assigned to a registered client, use the client dn delete command.