Configuring the server for Certificate Based Authentication with Android devices

There are several reasons why companies may wish their users to authenticate using a client certificate. Admins can easily issue and revoke certificates using MDM solutions. There is no need for users to remember or provide credentials. And there is additional security with two factor authentication using the certificate.

An admin generates a Certificate Authority type certificate that is installed on the server or gateway. From this certificate, the admin may generate client certificates that chain from the CA certificate. These each contain some piece of data unique to a user. The Admin can choose to place the data in any certificate field. The client certificates are then distributed to users (or directly to their devices).

When a user wishes to access the server, the application must provide the client certificate to the server in order for the SSL handshake to be completed and establish a secure connection to the server. Normally, the user identifies the certificate to use once and the application remembers to use that same certificate in follow-on connections. Only if the server is configured for two factor authentication does the user need to enter user ID and password information.

HCL Verse specific support

Starting with Verse for Android 9.5.5, support was added for Certificate Based Authentication. Two authentication scenarios are supported:
  1. The server (or access gateway) requires the client device to provide only a certificate.
  2. The server (or access gateway) requires the client to provide a certificate AND a user ID/password.
  3. The server (or access gateway) requires the client to provide a certificate OR a user ID/password.
Note: Transitioning from a client certificate only authentication model to a username/password authentication model is not supported and will require the uninstall and re-install of the HCL Verse for Android application.
Note: In order to reduce confusion in deployments where both client certificates and username/password authentication is used, please be sure to use consistent naming for your certificate user ID and your credential user ID. To identify the username to display in the HCL Verse for Android Settings > Account screen, the Common Name field of the client certificate is queried. If this cannot be read for any reason, then the name provided by the user during the installation of the certificate - the Alias - will be used for the account ID in the application.
Note: Ensure you select Require password when device turns on when using certificated based authentication.

Android supports certificate stores of type PKCS#12. These typically have a file extension of ".p12" or ".pfx". As a result, when an admin generates client certificates, they should be exported into a PKCS#12 store.

Usually, a password is required to access the certificate store, and the admin provides this with instructions to users about the migration to certificate based authentication.

Admins should configure the server to require client certificates. They should also specify the CA certificate that the client certificates must chain to. In addition, admins must configure what client certificate field will be used to obtain the user unique piece of information, and how this will be used by the server to determine the user's identity.

For a company currently using Verse, once the admin has distributed client certificates to all users, the admin can change the server configuration to require that users provide a client certificate.

Optimal user scenario

The admin deploys and installs the client certificates using Android for Work. The Android for Work profile can also specify the certificate alias that Verse will use. In this case, the migration will be transparent to the end user, since Verse will use the deployed certificate as soon as the server requires it.

The following link goes to documentation about how to install a certificate using Android for Work:

https://developers.google.com/android/work/security#grant_access_and_remove_access_to_a_client_certificate

A list of Android for Work settings are defined in our APK, and can be accessed as defined here:

https://developers.google.com/android/work/build-dpc#apply_managed_configurations_to_work_apps

The AIDL API interface can be used for setting the client certificate alias. Use the key "ClientCert.Alias" in the SetConfig call.

"Next best" user scenario

The admin deploys the client certificate store file using a Mobile Device Manager (MDM), but the certificate is not installed (only Android for Work can do that). In this case, when the server requires a certificate, the client connection will fail and Verse informs the user that a certificate is required. After that, Verse prompts the user to install/choose a client certificate. The user must choose Install, pick the certificate store to use, provide the store password and then choose that newly installed certificate. Verse can then connect to the server.

Base level user scenario

The admin provides the certificate store to the user, who must get it onto the device, then follow the installation steps from the case above.

"Fresh install" user scenario

Upon installing Verse for Android 9.5.5 or higher on a device for the first time, Verse can use MDM provided configuration data which may include the server URL. If not provided by the MDM, the user must enter the server URL. If Verse detects that the specified server requires a client certificate, the user is asked to choose a certificate that is already installed on the device or to install a certificate. Once the correct certificate is selected, the configuration process proceeds. If a user ID and password are also required, they are asked for them at this time.

SafeLinx setup for Certificate Based Authentication

Various programs can be used to generate certificates. Their use is outside the scope of this document.

A variety of gateway software can be used to implement certificate based authentication. The following example illustrates using SafeLinx to create a SafeLinx profile.

On the profile's LDAP tab:
  1. Select the Traveler server that hosts the directory of allowed user IDs.
  2. Ensure Disable password verification is checked.
  3. Ensure Chase LDAP referrals is checked.
On the profile's LTPA/SSO tab:
  1. Ensure Enable LTPA is checked.
  2. Set the LTPA token domain to the Traveler server address.
  3. Select the appropriate LTPA token user identification field.
  4. Ensure Enable SSO is checked.
  5. Set the appropriate SSO Cookie domain.
  6. Ensure User secure connection is checked.
  7. Ensure Server session with client certificate validation is selected.
  8. Ensure Extract from client certificate is selected.

On the Mode tab, ensure HTTP 401 basic authorization challenge is selected.