Connecting to TLS Client Authentication or Mutual Authentication enabled hosts using Host On-Demand

Client Authentication is a process that helps users to securely access a remote host/server by exchanging a digital certificate. TLS (Transport Layer Security) Client Authentication (also referred to as Mutual Authentication or Mutual SSL) is one of the most commonly used Client Authentication mechanisms.
​

As every organization needs to validate the individual users who have access to their host, implementing client authentication ensures that only clients/individuals with the appropriate certificate can access, communicate, and operate on the host.
Client authentication can not only add a second layer of security to the username and password combination of the individuals, but can also prevent unauthorized access. Client authentication and access control also enables organizations to meet regulatory and privacy compliance, while fulfilling internal security policies.

Typical authentication flow when client authentication is enabled

How to enable support for client authentication in Host On-Demand
Host On-Demand supports creating a connection to a client authentication enabled host. For enabling this feature, the Host On-Demand administrator needs to set the "Send a Certificate" to YES by clicking on the radio button next to it in the TLS/SSL panel while configuring the session and provide a certificate source.
​

Certificate Source:
The certificate can be stored in the client browser or within a dedicated security device such as a smart card.
Additionally, it can also be kept in a local or network-accessed password protected certificate store file, in one of the following file formats, that is suitable for storing server certificates:
              1. PKCS12   (Public-Key Cryptography Standards) 
              2. PFX          (Personal Information Exchange)
              3. JKS          (Java KeyStore).
 
While accessing the session from the client system, Host On-Demand prompts for a certificate source. When users provide the required certificate information (like source, path etc.), a connection gets established.

Key Usage and Extended Key Usage
 
Digital certificates used for client authentication may appear to be just like any other digital certificates that you may already be using within your organization, like the certificates for email/document signatures (digital signatures). But these certificates may have a few different properties depending on the use.
 
Purpose of the public key must be defined In the Key Usage section of a certificate. This enables the client user to restrict and limit the usage of the public key to as few or as many operations as needed. For example, if you have a key used only for signing or verifying a signature, enable the digital signature and/or non-repudiation extensions.
 
Extended key usage:
Extended Key Usage (EKU) option in a certificate is used to restrict the applicability of a certificate to be used with a Session Initiation Protocol (SIP) service. Extended key usage further refines the key usage extensions.
 
How to enable Key Usage and Extended Key Usage in Host On-Demand.
Host On-Demand users can enable Key Usage and Extended Key Usage features in the TLS/SSL panel by selecting “Yes” for Enable Key Usage field. During handshake, Host On-Demand ensures that only those certificates whose Key Usage and Extended Key Usage match the ones that you have selected, are sent to the host/server.

After enabling the Key Usage option, users can select ‘Key Usage bits’ and ‘Extended Key Usage’ from key usage panel.

The table below shows the purpose of each Key Usage type:

Key usage ​	Description
Digital signature	Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.
Non-repudiation	Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing).
Key encipherment	Use when a certificate will be used with a protocol that encrypts keys. An example is S/MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment.
Data encipherment	Use when the public key is used for encrypting user data, other than cryptographic keys.
Key agreement	Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers.
Certificate signing	Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates.
CRL signing	Use when the subject public key is to verify a signature on revocation information, such as a CRL.
Encipher only	Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement.
Decipher only	Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement.

Deepak Bohra
Technical Manager
bohra.d@hcl.com