Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • The connection of the user's browser and any REST client to the JOC Cockpit can be secured by HTTPS. The connection of This includes that a client validates the JOC Cockpit SSL certificate for server authentication.
  • In addition the JOC Cockpit - REST Web Service to the JobScheduler Master can be secured by HTTPScan be configured for mutual authentication, requiring the client to present a certificate that is validated by the JOC Cockpit.
  • This article describes the steps required to set up secure HTTPS communication with Jetty and with the JobScheduler Master.


  • The only prerequisite is to have the Java Keytools installed with your Java JRE or JDK.

Certificate Management

  • JOC Cockpit for mutual authentication. For login to JOC Cockpit a client, i.e. a user browser or REST client,
    • is required to hold a certificate that is validated by JOC Cockpit and
    • is required to specify a password.


JOC Cockpit Configuration

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

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

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

Code Block
titleAdd HTTPS mutual authentication to Jetty
## force use of client authentication certificates


Certificate Management

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.