Part 2: Cryptography; SSL/TLS Encryption

This part covers certificate configuration process based on application requirements this could be Mobile application, web applications and Mutual TLS. Applications such as Java and Apache applications.

Apache configurations;

In this part I will presume you have already done pre-configurations for an apache web server on httpd.conf or ssl.conf file.

On a standard port add the following lines to enable SSL verification and specify the ciphers.

SSL configs on apache are either on /etc/httpd/conf/httpd.conf or /etc/httpd/conf.d/ssl.conf

Listen 443

<VirtualHost *:443>

ServerName www.abc.target.com

SSLEngine On #ensure the engine is on when there are no configs use Off

SSLProtocol -all+TLSv1.2 #this specify the protocolSSLHonorCipherOrder On

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM

Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"Header set X-XSS-Protection "1; mode=block"Header always set X-Frame-Options DENYHeader always set X-Content-Type-Options nosniff

SSLCertificateFile "/path/to/abc.target.com.crt" # Specify path to the cert

SSLCertificateKeyFile "/path/to/abc.target.com.pem"</VirtualHost *:443>

Points to note.

1. Ensure the server name is valid as it might contradict with the certificate Common Name.
2. The path to the certificate should be where the certs are
3. SSL protocol used is added based on the protocol present -all allows all protocol

There are several commands and configurations not discussed here including forcing clients to authenticate via certificates or use of MutualTLS.

To be effective restart apache using service httpd restart or systemctl restart httpd

Nginx Configurations

Nginx has a similar process when configuring SSL certificates. The configuration files are located under /etc/nginx.conf.

server {listen 443

ssl;server_name abc.target.com;ssl_certificate abc.target.com.crt;

ssl_certificate_key abc.taregt.com.pem;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_ciphers HIGH:!aNULL:!MD5;#...}

Keystores and Trustores.

Truststores are used to hold the certificate from Certificate Authorities that are presented by the server during an SSL connection. Most of the certificates are stored under cacerts or ca-bundle on the server.

Keystores store both the private and identity certificate(Leaf) used for the verification and authentication by the client (where the request originates from)

In this example we will use

• abc.target.comCA.crt Intermediate certificate
• abc.target.com.crt as the Leaf Certificate
• abc.target.com_root.crt as root certificate.

Truststores;

Certificate authorities provide three certificates during generation;

A root certificate, Intermediate and Leaf certificate, both the root and intermediate are added to the trust stores using;

keytool -import -alias abc22 -file abc.target.comCA.crt-storetype JKS -keystore cacerts

During java installation on the security folder under /usr/lib/jvm/java/jre/lib/security/ the cacerts file contains several CAs and root certificates that validate server connections.

One can also create their own trustore using

keytool -import -alias abc22 -file abc.target.comCA.crt -keystore myTruststore

Keystores;

Keystore commands do not differ much with trustores, however there are several ways to create keystores for different services.

1. Simple keystore format.

To generate a keystore

keytool -keystore abckeystore -genkey -alias client

The following interactive session will have details of the organization.

View contents of the

keystore - keytool -list -v -keystore abckeystore

The output shows there’s a private entry. This Private Entry in the keystore.

Create a csr from the Keystore;

keytool -keystore abckeystore -certreq -alias client -keyalg rsa -file abc.csr

Certificate signing request (csr) as discussed in part one is used when generating the certificates that match the private key. This can be uploaded to several Certificate authorities such as Thwate, Digicert, Godaddy e.t.c and provides three or two x509 certificates as listed earlier.

Adding the certificate to the keystore;

keytool -import -keystore abckeystore -file abc.target.com.crt -alias certclient

Repeat the commands two times replacing the files with CA and root.crt certificates and different alias names.

1. Mobile application keystores using Bouncy Castle.

Bouncy Castle is a Java library that complements the default Java Cryptographic Extension (JCE), and it many more cipher suites and algorithms than the default JCE provided by Sun (Source Pulsar)

Create bks — https://www.bouncycastle.org/latest_releases.html

keytool -importcert -v -trustcacerts -file "abc.target.comCA.crt" -alias clientCA -keystore "abctarget.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "bcprov.jar" -storetype BKS -storepass changeit

This command creates the .bks file that will be used in the following processes. We can add other certificates on the BKS that will be used by the mobile application for validation.

keytool -importcert -v -trustcacerts -file "abc.target.comCA.crt" -alias client -keystore "abctarget.bks" -provider org.bouncycastle.jce.provider.BouncyCastleProvider -providerpath "bcprov.jar" -storetype BKS -storepass changeit

The bcprov.jar is added on the application to SSL termination during requests.

Other parts of mobile application SSL is pinning (dynamic and Static)

SSL pinning maps a host to a specific certificate. — Every application contains a certificate bundle as created above on bcprov.jar. During communication with the servers SSL pinning is used to ensure that the application can only SSL terminate on that specific server using the matching certificate on the app bundle and server.

python -sBc "from __future__ import print_function;import hashlib;print(hashlib.sha256(open('google.der','rb').read()).digest(), end='')" | base64python -sBc "from __future__ import print_function;import hashlib;print(hashlib.sha256(open('google.der','rb').read()).digest(), end='')" | base64

Mutual Authentication

Zero trust framework applied in client and server authentication. SSL termination only works when the server and client trust the presented certificate.

Source; oracleDocs.

The process;

1. A client makes a request
2. The server presents a certificate to the client; client verifies the servers certificate
3. The client sends its certificate to the server; the server verifies the certificate credentials.
4. If successful the server grants the client access.

Configuration on Java;

Add both the server and client certificates to the trustore;

keytool -import -alias client1 -file abc.target.com.crt -keystore myTruststorekeytool -import -alias server1 -file def.target.com.crt -keystore myTruststore

Add the certificate on the server.keystore on the server

keytool -import -keystore server.keystore -file abc.target.com.crt -alias certclient

Part 3; covers common SSL errors