What is TLS and digital certificates, How to secure your website using https

 

As per the internetsociety.org

Transport Layer Security (TLS) is a cryptographic protocol that provides end-to-end security of data sent between applications over the Internet. TLS encrypts data sent over the Internet to ensure that eavesdroppers and hackers are unable to see what you transmit which is particularly useful for private and sensitive information such as passwords, credit card numbers, and personal correspondence

TLS is normally implemented on top of TCP in order to encrypt Application Layer protocols such as HTTP, FTP, SMTP and IMAP.

TLS used in HTTP is called HTTPS, where the additional 'S' represents secure connection. In HTTP the communication is plain and unecrypted, anyone connected to the same network and access to network logs can see the data you are sending. But using HTTPS lets your data encrypted at client and can be decrypted only at sever end, so even anyone eaves drops on your network, all they can see is the encrypted data.

A typical https handshake is made as shown in below image (taken from ssl.com), this connection is made on the top of TCP 3-way handshake connection.

As shown in the step 3 of the above image, apart from end to end encryption we also get to verify the server that we are talking to the one whom we are intended to talk to, this can be verified using the digital certificates.

What are digital certificates?

As per the digicert.com Digital certificates is

"A Digital Certificate is an electronic file that is tied to a cryptographic key pair and authenticates the identity of a website, individual, organisation, user, device or server. It is also known as a public key certificate or identity certificate. The certificate contains the subject, which is the identity piece, as well as a digital signature."

What is a cryptographic key pair?

It is an asymmetric key pair where you have a public and a private key, in the end of this article we will how to generate a key pair with RSA using java sdk keytool binary.

Who verifies the identity?

A certificate authority, also known as a certification authority, is a trusted organisation that verifies websites (and other entities) so that you know who you’re communicating with online. Their objective is to make the internet a more secure place for organisations and users alike. This means that they play a pivotal role in digital security.

But what is the process for CA to verifies the identity of a website/organisation/user etc.?

1. You have to create a private key and a certificate (certificate contains public key and details about the website, org and other details to whom CA has to issue the certificate)
2. Generate the certificate signing request (CSR).
3. Provide the CSR file to the CA. CA will digitally sign the certificate with its private key.
4. Based on the requirement CA issues 3 different types of certificates
1. Domain Validation (DV): CA verifies only the domain to see if domain actually belongs to the one who is asking to get a certificate, CA might send a mail to the domain and expects a reply from the mail. otherwise CA verifies the domain name from the domain register. This is basic level of certificate issued by CA to any one who needs the certificate.
2. Organization Validation (OV): CA validates the organisation along with the domain, CA asks for some additional documents to verify the organisation authenticity to issue the certificate,  OV certificate is a level above in terms of trust than the DV certificate.
3. Extended Validation (EV): is the highest level of certificate in terms of trust because CA has been thoroughly checked all the details of the website, organisation and also its address and other details mentioned in the certificate.

To understand how to identify different types of certificates look at this link https://security.stackexchange.com/questions/35076/how-does-an-end-user-differentiate-between-ov-and-dv-certificates

you can see the digital certificate from the browser when you visited any website as shown below using the chrome browser

After clicking on the padlock button as shown above, click on “connection is secure” —> “connection is valid”, then you will the certificate as shown below.

The chain you see in the top box of the above image is called the certificate chain,

DigiCert High Assurance EV Root CA — is the root CA’s Certificate

DigiCert SHA2 Extended Validation Server CA — is the intermediate certificate

www.paypal.com — is the actual certificate issued to the website by the certificate authority

Now you understood the root certificate which is issued by the root CA, and the certificate issued to the website. But what is the intermediate certificate?

Certificate Authorities do not issue server/leaf certificates (end user SSL certificates) directly off of their roots. Those roots are too valuable and there’s just too much risk.

So, to insulate themselves, CAs generally issue what is called an intermediate root. The CA signs the intermediate root with its private key, which makes it trusted. Then the CA uses the intermediate certificate’s private key to sign and issue end user SSL certificates. This process can play out several times, where an intermediate root signs another intermediate and then a CA uses that to sign certificate. These links, from root to intermediate to leaf – are the certificate chain.

Ok now coming back to TLS/SSL handshake in the image shown above, in step 3 it is said that the client will verify the server certificate, 

But what exactly client verifies in the certificate to trust the certificate and identity of the server?

1. Client verifies the Common name/ Subject Alternative name (will discuss in the next few lines) in the certificate and the domain name we are trying to access to.
2. Validity of the certificate, every certificate comes with the expiry date, when the certificate expires client will not trust the user.
3. Validates the certificate chain with that of the browsers trust store (every browser will maintain a trust store with preloaded trusted CA certificates). If the root certificate matches with the one in the trust store then the certificate is valid.

But how the certificate chain is validated?

Anytime a browser or device is presented with an SSL certificate it receives the certificate itself as well as the public key associated with the certificate. Using the public key, it verifies the digital signature and sees who it was made by – what certificate signed it. You can probably start piecing this together now. When your browser is authenticating the end user SSL certificate on a website, it uses the public key that is provided to verify the signature and move one link up the chain. It continues repeating this process – authenticating the signature and following the chain to the certificate that signed it – until eventually it arrives at one of the root certificates in the browser’s trust store.

In client verification, common name in the certificate is checked to the domain name we are actually accessing to, 

Lets say is a certificate is issued www.paypal.com we cannot use it for any other domain or sub-domain also, so for every sub-domain we have to create a new certificate which is not a feasible idea.

So here comes the wild card certificates, using wild card certificates we can use the same certificate for subdomains also,

If you check in the browser a wild card certificate may look like this.

Observe the common name in the above certificate it is “*.ssl2buy.com”, which means the certificate is valid for ssl2buy.com and also all its subdomain, for example the same certificate can be used for blog.ssl2buy.com also

Ok so far so good, now is there any way to use the same certificate not just for subdomains but for other domains also.

Yes it is possible, there is another field in the certificate called “Subject Alternative name” also called as SAN in short form. 

During the server verification, client checks the domain name in the SAN list also.

A SAN for a certificate looks like in the below image.

The above PayPal certificate is valid for all the domains mentioned in DNS name list under the Subject Alternative Name in the above image.

In the next few steps we will see how we can create a certificate using the Java’s Keytool, and also how to create a CSR and sign the certificate using a dummy CA.

We had a dummy trusted CA called Dummy CA who will issue the certificates to a websites.

We had a website called mytechlearns.com who is looking to secure its website adding a certificate.

First generate a dummy root CA key pair and certificate using key tool using the below command,

keytool -genkeypair -alias dummy_rootCA -keyalg RSA -keysize 2048 -validity 365 -storetype pkcs12 -keystore dummy_ca.p12 -storepass 123456 -dname "CN=Dummy CA Inc., OU=Dummy OU, O=Dummy Org, L=New York, ST=New York, C=US"

Extract the private key and cert using the below commands, which we will use later to sign our CSR.

openssl pkcs12 -in dummy_ca.p12 -nodes -nocerts -out rootCA.key

openssl pkcs12 -in dummy_ca.p12 -nodes -nokeys -out rootCA.crt

Generate a key pair with certificate using the below command for the mytechlearns.com website

keytool -genkeypair -alias mytechlearns -keyalg RSA -keysize 2048 -validity 365 -storetype pkcs12 -keystore mytechlearns.p12 -storepass 123456 -dname "CN=mytechlearns.com, OU=mytechlears, O=mytechlears Org, L=Los Angeles, ST=California, C=US"

Now create a cert request using the below command

keytool -certreq -alias mytechlearns -file mytechlearns.csr -keypass 123456 -keystore mytechlearns.p12 -storetype pkcs12 -ext "SAN=dns:mytechlearns.net,dns:mytechlearns.org"

Observe the ext we added 2 more domains in the SAN, so we can use the same certificate for those domains also

Now lets sign the certificate using the CA.

When using openssl to sign the certificate SANs given in CSR file are not copied into signed certificate directly, hence create a file calls sans.txt with the below contents

subjectAltName = DNS:mytechlearns.net, DNS:mytechlearns.org

Then execute the below command to create a signed certificate.

openssl x509 -req -CA rootCA.crt -CAkey rootCA.key -in mytechlearns.csr -out mytechlearns.crt -days 365 -sha256 -extfile sans.txt

If everything has gone well and if you open the “mytechlearns.crt” in Mac OS (right click on the file and click on “quick look”), it looks like below.

References:

https://www.comparitech.com/blog/information-security/tls-encryption/

https://www.internetsociety.org/deploy360/tls/basics/

https://hpbn.co/transport-layer-security-tls/

https://www.ssl.com/article/ssl-tls-handshake-overview/

https://www.thesslstore.com/blog/root-certificates-intermediate/