Introduction

• The connection from a client (user browser or REST client) to JOC Cockpit can be secured by HTTPS. This includes that the client validates the JOC Cockpit's SSL Server Authentication Certificate. In addition the JOC Cockpit can be configured for mutual authentication, requesting in return the client to present a Client Authentication Certificate that is validated by JOC Cockpit.
• This article describes the steps required to set up JOC Cockpit for certificate based authentication.
• Use with JS7 - Identity Services 
  • For the JOC Identity Service certificates can be used for single-factor and for two-factor authentication.
  • For any other Identity Services certificates can be used for two-factor authentication.
• Authentication Schemes
  • Single-factor authentication includes that use of a Client Authentication Certificate is sufficient to login to JOC Cockpit, no specification of user account and password is required.
  • Two-factor authentication includes that
    • the client (user browser, REST client) presents a Client Authentication Certificate and
    • the client specifies the user account and password for login.

Prerequisites

• JOC Cockpit is set up to use JS7 - JOC Cockpit HTTPS Connections
• Clients are equipped with a Client Authentication Certificate.

JOC Cockpit Configuration

Jetty Configuration

JETTY_BASE is Jetty's base directory which is specified during the JOC Cockpit installation:

• C:\ProgramData\sos-berlin.com\joc (default on Windows)
• /home/<setup-user>/sos-berlin.com/joc (default on Linux)

Add the following entries to the JETTY_BASE/start.ini configuration file:

## enable use of client authentication certificates
jetty.sslContext.needClientAuth=false
jetty.sslContext.wantClientAuth=true
jetty.sslContext.endpointIdentificationAlgorithm=

Hints

• Line 2: if needClientAuth is set to true then a Client Certificate is required. If this setting is false and the wantCientAuth setting is true then users have the option for user/password based authentication or certificate based authentication.
• Line 4: this setting looks weird, however, it is required due to a bug in Jetty 9.4, see https://github.com/eclipse/jetty.project/issues/3466. With later releases of Jetty that fix this bug this setting is not required.

Certificate Management

Mutual authentication is based on X.509 compliant certificates. Self-signed certificates and CA signed certificates can be used.

JOC Cockpit has to hold in its truststore a certificate that allows validation of the clients' certificate. The location of the Jetty truststore is specified with the JETTY_BASE/start.ini configuration file.

• Self-signed Certificates
  • JOC Cockpit holds the client's certificate in its truststore. 
  • Each client's individual certificate is required to be in place.
• CA signed Certificates
  • JOC Cockpit holds the CA certificate, i.e. the root certificate/intermediate certificate(s), in its truststore.
  • Connections from any clients that use a certificate signed by the CA will be accepted.
  • This approach is more flexible as it does not require to modify the Jetty truststore when adding/removing clients.

Client Configuration

Certificate Management

Self-signed certificates and certificates signed by trusted root certification authorities (CA) can be used.

For use with self-signed certificates the root certificate has to be added to the client's certificate store. Certificates from trusted root CAs frequently are available from a client's keystore.

Certificate Store

The client holds its private key and certificate in its keystore. 

• The private key is created by the client when generating a key pair for a self-signed certificate and respectively when creating a Certificate Signing Request (CSR) for its CA.
• For CA signed certificates the client's certificate store includes the certificate chain, i.e. client certificate and root certificate/intermediate certificate(s) that have been used when signing the client's certificate.
• Frequently private key and certificate(s) are stored in a PKCS12 keystore that comes with a .pfx or .p12 file extension. However, other file formats for private key and certificate(s) are available.
• The clients' keystore has to be imported into the client's certificate store. The location of the certificate store depends on the client application that is used to access JOC Cockpit:
  • Browser Clients
    • Firefox (any platform): support for use of an individual certificate store that is available with the browser, see Options -> Privacy & Security -> Certificates.
    • Chrome, Vivaldi, Edge (Windows): supports use of the Windows Certificate Store
    • Chrome, Vivaldi (Linux): support for use of an individual certificate store that is available with the browser, see Options -> Privacy
    • Chrome, Safari (Mac OS): support for use of the Mac OS Certificate Store
  • REST Clients
    • JS7 PowerShell Module (Connect-JS7): Windows, Linux, Mac OS: support for use of a PKCS12 keystore (.p12); Windows: support for use of the Windows Certificate Store.
    • Other REST Clients: REST clients implemented with programming languages or scripting languages follow individual approaches to manage a certificate store.

Certificate Encryption Algorithms

X.509 certificates with RSA or ECDSA encryption algorithms can be used.

Certificate Verification

For incoming connections from a Client, for example a browser, the Jetty servlet container that ships with JOC Cockpit will challenge the Client to present its Client Authentication Certificate.

• Jetty will verify the Client Authentication Certificate and check if this was signed by a CA using the Root CA Certificate that is available with the Jetty truststore.
• During login the user does not have to specify the account to be used. Instead, the Common Name (CN) entry of the Client Authentication Certificate's subject specifies the account used for login with JOC Cockpit. Consider that an exact match of the CN is required: 
  
  • Assume a user account: apmacwin
  • The certificate subject could look like this: