4. SSL Certificates configuration
Read carefully this chapter if:
• you have chosen a secured deployment with HTTPS protocol.
• you have more than 1 server
There are 2 layers of communication for HTTPS:
1: HTTPS Communication between the web browser and IIS Web Server
2: HTTPS Communication between the IIS web Server to HOPEX Application server and between HAS Server themselves.
Each layer/path has its own SSL Certificate.
4.1. Configuring public SSL Certificate (1)
|
This certificate is generated by the customer. Ensure that the generated certificate has:
• a Certificate Authorities and a Certificate Chains that are valid with Trusted Authorities.
• a Certification path that corresponds to the chosen DNS
• a set of Subject Alternative Name that corresponds to the chosen DNS.
|
|
To have a valid deployment you must import this SSL Certificate in all servers (IIS+HAS).
Perform the following task:
• Generate your own SSL signed certificate.
4.2. Configuring HAS Cluster node SSL Certificate (2)
|
This certificate is generated by HAS at first launch by the first server.
• This is a self-signed certificate with a 30-year validity
• This certificate is named root.pfx and is available on the first HAS Server of the farm
• This root certificate is used to generate a node.pfx certificate for each HAS node. This node.pfx is generated automatically.
|
|
To have a valid deployment you must import this root.pfx SSL Certificate in all servers (IIS+HAS). This certificate has no password.
Perform the following tasks:
1. Access the first HAS server installed.
2. Go to C:\...\HOPEX Application Server\<<port>>\.certificates folder.
3. Search for root.pfx file.
4. Copy and keep this file.
6. If prompted for a password, leave it blank, as this certificate has no password.
4.3. Adding certificate on the server
Follow the instruction provided by Microsoft to install the certificate in the local computer store:
1. In the search box, type mmc, and then click OK.
2. On the File menu, select Add/Remove snap-in.
3. In the Add/Remove Snap-in dialog box, select Add.
4. In the Add Standalone Snap-in dialog box, select Certificates, and then select Add.
5. In the Certificates snap-in dialog box, select Computer account, and then select Next.
6. In the Select Computer dialog box, select Local computer: (the computer this console is running on), and then click Finish.
7. In the Add Standalone Snap-in dialog box, click Close.
8. In the Add/Remove Snap-in dialog box, click OK.
9. In the left pane of the console, double-click Certificates (Local Computer).
10. Right-click Trusted Root Certification Authorities, point to All Tasks, and then select Import.
11. On the Welcome to the Certificate Import Wizard page, click Next.
12. On the File to Import page, click Browse, locate your certificate file, and then click Next.
13. If the certificate has a password, enter the password on the Password page, and then click Next.
14. On the Certificate Store page, select Place all certificates in the following store, and then click Next.
15. Click Finish, and then click OK to confirm that the import was successful.
Some Screenshots of the process:
In this example the public certificate is named “VP-IIS1-V5.fr.mega.com”.
If the certificate is not signed by a trusted authority, ensure that this certificate is present in all servers and laptops that will use the website.
Make sure that the certificate path is also present on all of the servers. Should one certificate path appear with a “red cross” fix it.
4.4. Creating and using a custom cluster SSL certificate
This SSL certificate is only for the communication between cluster nodes. This is not the public SSL certificate.
This is an optional step to perform only if requested by your security team because self-signed certificate is not allowed.
4.4.1. Creating a custom SSL certificate
Caution: this sub-chapter does not intent to present best practices in term of security to create an SSL certificate but only to show an example that works with required elements.
To create a valid root.pfx certificate you must comply with the following constraints:
• The certificate must be trusted and belong to a hierarchy of trusted certificate. Ideally owned by the customer.
• The certificate must embed its private key.
• The certificate must be CA Authority
1. Create a file called ca.cfg that will contain the required characteristic of your SSL certificate.
Adjust settings based on your company constrains.
|
ca.cfg file content
|
|
[req]
default_bits = 4096
default_keyfile = db.key
distinguished_name = req_distinguished_name
req_extensions = v3_ca
extensions = v3_ca
prompt = no
[req_distinguished_name]
C = FR
ST = Paris
L = Paris
O = mega.com
OU = mega.com
CN= localhost
emailAddress = contact@mega.com
[v3_ca]
basicConstraints = CA:TRUE
|
2. Create the certificate with these elements. Here is a sample script using openssl to create the certificate.
Create the certficate private key ans save it in the file rootCA.key
openssl genrsa -out rootCA.key 4096
Create a crt file
openssl req -x509 -new -nodes -key rootCA.key -days 1024 -config ca.cfg -extensions v3_ca -out rootCA.crt
Create an PFX file to be imported in all server of the cluster (HAS+IIS)
openssl pkcs12 -export -out root.pfx -inkey rootCA.key -in rootCA.crt
4.4.2. Use the custom cluster certificate.
To use the newly created certificate:
1. Clean existing self-signed root.pfx/node.pfx certificate. You may skip this step if you have never installed in HTTPS the cluster.
• From the HAS Instance Manager stop all cluster instances/nodes.
• For each IIS server and HAS server of the cluster:
a) Delete file node.pfx and root.pfx located in the default location here: C:\...\HOPEX Application Server\...\.certificates
b) From MMC console under Certificates>Trusted Root Certification Authorities delete the existing certificate called “HOPEX Application Server” and/or “HOPEX Application Server (Dev Only)
2. Import your new certificate.
For each IIS server and HAS server of the cluster:
a) Access Certificates > Trusted Root Certification Authorities > Certificates menu, right-click and select All tasks > Import. Make sure you import with a user that will give enough privilege to the certificate to be read by HAS later.
b) Click Next.
c) Browse and select the PFX file you just created.
d) Click Next.
e) When prompted enter the password for the private key if you have set one (in this example there is no password).
f) (optional) You may want to select “Mark this key as exportable. This will allow you to back up or transport your keys at a later stage” for future use if you lose the original file.
g) When prompted make sure to place this certificate in “Trusted Root Certification Authorities”.


3. Get the thumbprint of your certificate.
a) From the MMC Console, search for your certificate.
b) Right-click the certificate and select Open.
c) In the Details tab, scroll down to Thumbprint.
d) Copy and save its Value for later use.

4. Use the thumbprint within the HAS Instance Manager:
a) Connect to HAS Instance manager.
b) Click the start button of the first node of the cluster.
c) Click Advanced.
d) Past your thumbprint in the area planned for these purposes. Make sure the certificate file path and password are empty.
e) Click OK.
f) Wait for the first node to be fully running. Do not continue if this fails.
g) Repeat the operation on each node of the cluster.
5. Check everything is OK:
a) Ensure all HAS instances are running for each node.
b) Open the settings.cfg files of each node and ensure you see the certificate thumbprint.
4.5. Disabling vulnerable cypher suites
In Windows Server 2019, TLS 1.0 and 1.1, which have known vulnerabilities, are activated by default.
It is highly recommended to disable vulnerable protocols by removing Schannel and cipher suite from the Windows registry.
You can use one of the following:
• directly from the Windows registry
To remove the Schannel and Cipher directly from the Windows registry, see Windows documentation.
• using IIS Crypto (recommended)
• using script
4.5.1. Disabling vulnerable cypher suites with IIS Crypto
2. Connect to IIS Crypto.
3. In Schannel, disable the vulnerable algorithms and protocols: TLS below 1.2, PKCS, MD5, SHA, DES, and RC4.
4. In Cipher Suites, disable other weak cipher suites:
The best hardening is to disable all cipher suites with cbc or no key exchange. (others were already disabled by SChannel configuration).
4.5.2. Disabling vulnerable cypher suites using script
You need to disable those by running the:
- TLS1.0.reg
- TLS1.1.reg
- Triple DES 168.reg
- PCKS.reg
- RC4 128-128.reg
By default others are disabled
These scripts keep some “good but not perfect cipher-suite” suites like some with CBC (no PFS).
Download these scripts from the “Secure server toolkit.zip”.
Make sure the .NET layer will accept to use TLS 1.2:
1. Through the Startup menu, go to “Run” and enter:
regedit.exe
2. Browse through the registry until you reach the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
3. In that key, create an entry of type DWORD (32 bit) with the following details:
Name: SchUseStrongCrypto
Value: 1
Reboot the server to take everything into account.