Starting version 1.9.8.2.4-1 (April 2019 build) your DMS can be configured to be accessible only via the https protocol (secure http). In this case, all communication between client computers and the DMS will be secured by encryption.

You can use encryption certificates that are issued by a suitable certificate issuer (eg. https://www.thawte.de, https://www.geotrust.com, https://letsencrypt.org, etc.), or you can use self signed certificates. Note that self signed certificates are generally considered less secure and may require to be trusted by the browsers used to access the DMS server. Please find a short guide how to create a self signed certificate here.

Setup DMS

In order to configure your DMS to use secured communication, the following steps must be followed:

  1. Create a directory that will hold the certificate- and key-files ('<certificateName>.cer' and '<certificateName>.key'). For example you can run

    mkdir /storage/nginx/
  2. Obtain a certificate- and key-file from one a certificate issuer or create a self signed certificate- and key-file and move them to the directory that was just created. If you are going to use Letsencrypt certificates, see below.
  3. Update your deploy scripts (Auto-deploy script section "Script Updates").
  4. git pull the most recent version of your client specific configuration - this is crucial so the the deploy using the new mechanism works correct (please contact us to verify if your client specific repository is ready for https deployment before you continue with the deploy process).
  5. Edit the dms.conf file in the client specific git repository in the section 'HTTPS parameters'; uncomment and supplement the relevant settings; in particular add the names (without path) of your certificate files (HTTPS_CERTIFICATE, HTTPS_CERTIFICATE_KEY and, in the case of Letsencrypt, HTTPS_CERTIFICATE_PASSWORD, HTTPS_CHAIN but no HTTPS_CERTIFICATE_PASSWORD). Make sure the NUXEO_URL in this file does not specify a port number.
    n.b. :     in eDMS Versions prior to 1.9.8.2.6 (more precisely in the deploy scripts herefor) the HTTPS parameters in  dms.conf needed a defined path in the settings for HTTPS. Your configuration might need some adjustment if you upgrade your eDMS to 1.9.8.2.6 or better.
  6. Run the deploy command for all containers.

Setup Nuxeolib for https://

from Nuxeolib Version 1.5 or better edit the Windows Registry with these Keys:

[HKLM/SOFTWARE/DocIntegrate/USE_HTTPS] — DWORD32 — values [0;1] (where 1 is https "on")
[HKLM/SOFTWARE/DocIntegrate/HTTPS_PORT] — DWORD32 — int value (defines port number; optional, if not present port 443 will be used)
[HKLM/SOFTWARE/DocIntegrate/SKIP_HTTPS_KEY_VALIDATION] — DWORD32 — values [0;1]

please note that you may also use these Registry Keys with HKCU

Other required setup

  1. If you access CaseBrowser directly through a web browser, such as Google Chrome, make sure that your URLs for accessing CaseBrowser do not include and ports, ie. the URL for casebrowser must be https://<dms-server>/casebrowser/ and the URL for accessing the nuxeo console must be https://<dms-server>/nuxeo/
  2. The address defined in Patricia Maintenance to access the DMS must be modified in the same manner. See Patricia Maintenance and Nuxeo Configuration, section "Configure DMS Links in Patricia Maintenance" bearing the modification outlined under item 1. in mind.
  3. Similarly, the address defined in the client side registry keys for the DocIntegrate Outlook communication to the server need to be modified for https access as per item 1. (DocIntegrateOutlook, section "Installing the registry settings on a client system")
  4. In Patricia Maintenance, Basic Configuration value 315 must not specify a port but only the server address.
  5. Make sure all client computers have DocIntegrate 2.0.9 or newer installed and running.
  6. In the PAT_DMS_SETTINGS table of the Patricia db, set https.enabled=TRUE (if this key is not present, add it) and restart the DMS.
  7. NuxeoLib 

Client side setup when self signed certificates are used

When self signed certificates are used, these certificates will require to be expressly trusted by the client computers. This step is not necessary when certificates are used that are issued by a certificate issuer. 

In order to make InternetExplorer and other windows services trust self signed certificates, please follow the steps described here.

Preparing a CSR (Certificate Signing Request) from your eDMS-server with OpenSSL

When you create a Certificate that you want to have signed by a CA (a commercial one or the one of your corporation) you can generate your csr inside the eDMS Virtual Machine.

in Order to make your cert also compatible with Google Chrome (the browser) you need to prepare a configuration file (here named SAN_CERT.conf) that holds the Additional Names for your certificate. These subjectAltName entries are the Internet Standard (RFC 822) that all browsers comply to, Google Chrome being the only at the Moment completely ignoring the Older Naming Schemes.

An Example is here: SAN_CERT.conf

Edit this file and for all entries in <angle brackets> enter your own data. Copy the modified file to /storage/nginx and execute

To generate .key and .csr file:

openssl req -new -sha256 -out patricia-edms.csr -config SAN_CERT.conf -keyout patricia-edms.key

Replace patricia-edms.* with your chosen name; The hashing algorithm ('-sha256') can also be modified by choice.
This generates a .key and .csr file. Send the .csr file to your CA for signing. In return, you will receive a certificate; place this in the same folder.

To generate only .csr file for an existing .key file, without altering old .key file:

openssl req -new -sha256 -out patricia-edms.csr -config SAN_CERT.conf -key patricia-edms.key

Replace patricia-edms.csr with your chosen name; Replace patricia-edms.key with your existing key file name; The hashing algorithm ('-sha256') can also be modified by choice.
This generates a .csr file. Send the .csr file to your CA for signing. In return, you will receive a certificate; place this in the same folder.

Either way, do NOT send the .key file. Make sure the key file kept secure; if your key file is shared, your security may be compromised.

Setup using Lets Encrypt certificates

You can obtain certificates from Letsencrypt using known methods and tools (eg. certbot). If your DMS server cannot be reached from the internet, you need to use the DNS-challenge to create/renew your lets encrypt certificate (you need control over your DNS server for this to work). An exemplary process to obtain a Letsencrypt certificate is as follows (note that this assumes you have the certbot software installed):

Start a certificate request for <youHostName>, a FQDN: 

certbot -d <youHostName> --manual --preferred-challenges dns certonly

In the process, you will be asked to enter a TXT entry to the zone file of your DNS server, eg. as follows

_acme-challenge.<youHostName>     TXT     HL73AF2MMGol-yFISWyYS_DA1OFqJGdoJNxtSoTre-8

Once done, you will receive a certificate issued by Letsencrypt. Finally, make sure automatic renewal of the certificate will work by adding

certbot renew

to your crontab.

After this process you will find links to certificate files in your lets encrypt folder (eg. /etc/letsencrypt/live/<yourHostName>/) as follows – note that <yourHostName> is replaced with the FQDN of your DMS server that you obtain the certificate for:

lrwxrwxrwx 1 root root  42 Mar 13 18:07 cert.pem -> ../../archive/<yourHostName>/cert1.pem
lrwxrwxrwx 1 root root  43 Mar 13 18:07 chain.pem -> ../../archive/<yourHostName>/chain1.pem
lrwxrwxrwx 1 root root  47 Mar 13 18:07 fullchain.pem -> ../../archive/<yourHostName>/fullchain1.pem
lrwxrwxrwx 1 root root  45 Mar 13 18:07 privkey.pem -> ../../archive/<yourHostName>/privkey1.pem

In the /storage/nginx folder, create link to some of these as follows:

lrwxrwxrwx 1 root root   54 Mar 13 21:36 <yourHostName>.cer -> /etc/letsencrypt/live/<yourHostName>/fullchain.pem
lrwxrwxrwx 1 root root   50 Mar 14 14:16 <yourHostName>.chain -> /etc/letsencrypt/live/<yourHostName>/chain.pem
lrwxrwxrwx 1 root root   52 Mar 13 21:37 <yourHostName>.key -> /etc/letsencrypt/live/<yourHostName>/privkey.pem
  • No labels