TLS and certificates

To ensure that communication between client and server happens securely, the data is encrypted when passed in the network.

Fundamentals

• Encryption: Converting Data into “gibberish”
• Decryption : Getting original data from “gibberish”
• Symmetric Key : Sender and receiver use same “key”, e.g. take ‘a’, get ascii value and 26, adding 26 is the key . Receiver does a reverse process to original data.
• Asymmetric keys : Key is different for encryption and decryption but is related. Data is encrypted using public key and decrypted using private key. Idea is that, in theory you cannot derive private key from public. Public key is shared with others whereas private key remains on the server.
• Certificate: some metadata about key pair and public key signed by an entity called Certification Authority (CA) . A certificate is normally assigned to one DNS name (like medium.com)
• (root)CA : An entity that signs the certificate. Some CA’s are GoDaddy, Amazon, DigiCert
• Private CA: entity that issues certificate for limited users, like an organization. For e.g, intranet apps which are not accessed in public domain don’t need to have certs signed by known root CAs. You would need to install cert in clients (such as browser or your JRE) so that you don’t get error similar to “this connection is not trusted”. Reason, browser comes pre installed with known root certs only, hence the error. The problem is often mitigated by your enterprise IT since they roll out computers with such certs pre installed.
• Certificate chain: Root and intermediate CA’s. Essentially adds layer of security. Top level (root) cert is self signed by CA. In a typical cert, you would see. Root->Intermediate->Domain . Click on the padlock in the address bar of the browser you are reading this and notice the certificate.

Extensions Used

• X 509 : is a certificate which is digitally signed according to RFC 5280, it has public key
• .CER, .DER : binary DER encoded
• PEM : Base 64 encoded with— BEGIN line
• CRT : ASCII PEM which has certificate
• .KEY = The KEY extension is used both for public and private PKCS#8 keys. The keys may be encoded as binary DER or as ASCII PEM.

Enabling TLS on a website

• Generate private key and Certificate Signing Request ( CSR ) . Consider CN (Common Name ) and SAN ( Subject Alternative Name )
• Install private key on the server, typically a Load balancer. See an example Configuring HTTPS servers (nginx.org)
• In k8s based microservice see Ingress | Kubernetes
• Install root and intermediate on a client(browser) if CA is not known.
• Decide where to decrypt data. Typically at Load balancer.

1. SSL Termination : End point where data is decrypted
2. SSL passthrough: unencrypted data is passed to the web server by load balancer

How TLS communication is handled in browser

• During TLS handshake the domain/server presents the certificate to the browser
• Note that you do not need to install a domain’s cert in your browser.
• Together with intermediate and root cert the domain cert is validated. If the validation succeeds the TLS communication starts. It is a complex process and you can google and find in depth the complete process.

How TLS communication is handled in Java Apps

• Trust store: The default trust store is at /jre/lib/security/cacerts and it comes with list of trusted root certificate. This is the location to put root and intermediate certs of web applications signed by private CA. The process to validate domain certificate is similar to the one covered for browser.
• Key store : if you are a server, put private key in here. Won’t recommend this approach to secure the website. Better to use a proxy server. For web apps refer to Enabling TLS on a website section above.
• Tip : If you are getting certificate errors for spring.io, gradle etc see it is referring to Zscaler cert, install Zscaler root and intermediate certificate in the trust store

Truststore/Certificate Location in OS

Ubuntu/Debian: /etc/ssl/certs
RHEL: /etc/pki/ca-trust

ubuntu/debian has a file named ca-certficates.crt under /etc/ssl/certs which is a concatenated list of certificates under that folder. To add a new certificate put it under /usr/local/share/ca-certificates and run update-ca-certificates command. RHEL has similar mechanism albeit different location and command to update. Now you can verify ca-certificates.crt with newly added certificate by running
openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt