Products Downloads


French version


 

When you start up the daemon in TLS mode, communications are encrypted between the client and server. The protocol used is TLS in version 1.2.

The encryption mode requires a certificate and server-side encryption key to be provided. The certificate must be signed by a certification authority which is recognized by the client workstations.

The client requires the verification of the certificate string. The Windows client automatically uses the certificates of the Windows "Trusted root certification authorities" store, the Java client uses the "truststore"» configured in the JVM ("lib/security/cacerts" or "jre/lib/security/cacerts" by default according to the Java version), or the store specified via the standard parameters of the Java command line (Djava.net.ssl.trustStore, Djava.net.ssl. trustStorePassword, Djava.net.ssl. trustStoreType).

This means that if you want to use an unsigned certificate or certificate signed by a trusted authority which is private to the company, this must be imported into the client workstation certificate store.

Client authentication (a client-specific certificate is sent and authenticated by the server) is not supported in the initial version.

Note: for Windows and AS/400 daemons, a specific debugging trace can be enabled by enabling the "com.hardis.middleware_tls" logger in the DEBUG level in the LOG4C configuration.


Creating a certification authority and server certificate

This configuration example uses "openssl" to generate a certificate string based on a private certification authority.

Go into a new directory and create the "middleware.ext" file with the following content:

authorityKeyIdentifier=keyid,issuer 

basicConstraints=CA:FALSE 

keyUsage = digitalSignaturenonRepudiationkeyEnciphermentdataEncipherment


Creating the private authority

Creating the authority's private key (a password will be required to protect the key):

openssl genrsa -des3 -out myCA.pkcs1.key 2048


Creating the private authority certificate (valid for 5 years here):

openssl req -x509 -new -nodes -key myCA.pkcs1.key -sha256 \

-days 1825 -out myCA.crt


Creating a certificate for the Middleware server

Creating the server's private key:

openssl genrsa -out adelia-middleware.pkcs1.key 2048


Creating a signature request to generate the daemon certificate via the certification authority:

openssl req -new -key adelia-middleware.pkcs1.key \

-out adelia-middelware.csr


Signing of the server's private key by the certification authority:

openssl x509 -req -in adelia-middelware.csr -CA myCA.crt \

-CAkey myCA.pkcs1.key -CAcreateserial \

-out adelia-middleware-cert.crt -days 1825 -sha256 \

-extfile middleware.ext


Conversion of the key into PKCS-8 format for use by the daemon:

openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt \

-in adelia-middleware.pkcs1.key \

-out adelia-middleware-key.key


At the end of this operation, "adelia-middleware-cert.crt" and "adelia-middleware-key.key" files can be used to start up the daemon.

The myCA.crt file must be imported into the trusted certificate store on the client workstations.

Windows:

    • Double-click on the .crt file in the explorer.
    • Select the Install Certificate option.
    • Select the Current user or Local machine option according to your configuration.
    • Select the Place all certificates in the following store option then specify the Trusted Root Certification Authorities store.
    • Validate with Finish.

Java:

Execute the following command to import the certificate into the Java default certificate store (the default password is "changeit"):

keytool -importcert -file myCA.crt -keystore [path_jre]\lib\security\cacerts -alias "myCA"

↑ Top of page




  • Aucune étiquette