- The connection from the user's browser or any REST client to the JOC Cockpit can be secured by HTTPS. This includes that a client validates the JOC Cockpit SSL certificate for server authentication.
- In addition the JOC Cockpit can be configured for mutual authentication, requiring in addition the client to present a certificate that is validated by the JOC Cockpit.
- This article describes the steps required to set up secure JOC Cockpit for two-factor authentication including SSL mutual authentication and password authentication. For login to JOC Cockpit a client, i.e. a user browser or REST client,
- is required to hold a certificate stored with the client's device that is validated by JOC Cockpit and
- is required to specify a password.
- JOC Cockpit is set up to use HTTPS Communication.
JOC Cockpit 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:
- 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 the setting will not be required.
Mutual authentication is based on X509 compliant certificates. Self-signed certificates and CA signed certificates can be used.
Certificate Management with the JOC Cockpit
JOC Cockpit hold a certificate that allows validation of the clients' certificate in its truststore. 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.
Certificate Management with the Client
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 to sign 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:
- The Internet Explorer, Edge and Chrome browsers are reported to use the Windows certificate store.
- The FireFox browser makes use of its own certificate store.
- REST clients implemented with programming languages or scripting languages follow individual approaches to manage a certificate store.
The JobScheduler PowerShell Modules for JobScheduler 1.x and for JobScheduler 2 (JS7) both support to specify client certificates from keystores and from the operating system certificate store.
- JobScheduler 1.x: PowerShell CLI 1.2 - Cmdlets - Connect-JobScheduler
- JobScheduler 2.x: PowerShell CLI 2.0 - Cmdlets - Connect-JS7