Daily Archives: July 17, 2021

How Two way SSL works

Posted on by

When the client communicates with the server over HTTPS either browser or REST call, the server doesn’t care who the client is, as long as they have the correct credentials. This is what happens in Login forms(Asymmetric communication followed by Symmetric Communication).

Two-way SSL is used for places where you only want the server to accept connections from a restricted number of users. It helps to mitigate the risk of fraud in online transactions. Two-way SSL authentication (also known as “mutual authentication”, or “TLS/SSL with client certificates”) where two parties authenticate
each other through verifying provided digital certificates, so that both parties are assured of the other’s identity.

In One-way SSL, where the browser (the client) establishes an SSL connection to a secure web site and the server’s certificate is checked, creating SSL authentication in RESTful web services. The browser either relies on itself or the operating system providing a list of certs that have been designated as trusted Certificate Authorities (CA).

In context to java, Java Key Store is used to store the certs and keys.It must be password protected and entries in it must have an “alias” that is unique. If an alias is not specified, “mykey” is used by default.

KeyStores provide credentials, TrustStores verify credentials.Clients will use certificates stored in their TrustStores to verify identities of servers. They will present certificates stored in their KeyStores to servers requiring them.

The JDK ships with a tool called Keytool. It manages a JKS of cryptographic keys, X.509 certificate chains, and trusted certificates. 

//Importing a truststore which could be used by client for server certificate verification
>> keytool -import -v -trustcacerts -keystore client_truststore.jks -storepass apassword -alias server -file foo.snaplogic.com.cert

//Importing a keystore which could be used by client when server asks of identity certificate
>> keytool -importkeystore -srckeystore client-certificate.p12 -srcstoretype pkcs12 -destkeystore client_keystore.jks -deststoretype jks -deststorepass apassword

// Viewing list of servcer certificates in Client Truststore  
>> keytool -list -v -keystore client_truststore.jks

We can now complete configuration of the REST SSL Account by uploading our client_truststore.jks and client_keystore.jks KeyStore files

One way SSL

  1. Client requests for some protected data from the server on HTTPS protocol. This initiates SSL/TLS handshake process.
  2. Server returns its public certificate to the client along with server hello message.
  3. Client validates/verifies the received certificate. Client verifies the certificate through certification authority (CA) for CA signed certificates.
  4. SSL/TLS client sends the random byte string that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server’s public key.
  5. After agreeing on this secret key, client and server communicate further for actual data transfer by encrypting/decrypting data using this key.

Two way SSL

  1. Client requests a protected resource over HTTPS protocol and the SSL/TSL handshake process begins.
  2. Server returns its public certificate to the client along with server hello.
  3. Client validates/verifies the received certificate. Client verifies the certificate through certification authority (CA) for CA signed certificates.
  4. If Server certificate was validated successfully, client will provide its public certificate to the server.
  5. Server validates/verifies the received certificate. Server verifies the certificate through certification authority (CA) for CA signed certificates.
  6. After completion of handshake process, client and server communicate and transfer data with each other encrypted with the secret keys shared between the two during handshake.

Certificate Signing Request and Certificate Authority

Posted on by

When Creating a certificate the first thing we do is creating a public and private keys. The Keys generated using java keytool or either by using keystore comes with a self signed certificate which could not be verified with CA. To win third party trust we get our public key signed with someone who is in common between thirdparty and data provider(server). This common entity is nothing but Certificate Authority(CA). To Apply for certificate we should create a CSR Request along with organization name, common name (domain name), locality, and country details.

Certificate Signing Request
A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A certificate authority will use a CSR to create your SSL certificate, but it does not need your private key. You need to keep your private key secret. The certificate created with a particular CSR will only work with the private key that was generated with it. So if you lose the private key, the certificate will no longer work.

The CSR is signed by the applicant’s private key.This proves to the CA that the applicant has control of the private key that corresponds to the public key included in the CSR.

How does a CSR looks like?

-----BEGIN CERTIFICATE REQUEST-----
MIIC5jCCAc4CAQAwcTELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCXRhbWlsbmFkdTEQMA4GA1UEBxMH
Y2hlbm5haTESMBAGA1UEChMJbXVnaWwub3JnMRIwEAYDVQQLEwltdWdpbC5vcmcxFDASBgNVBAMT
C211Z2lsdmFubmFuMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9alda8sBOwSPXBOV
IyWD2bgn96RkCcoP1hNE7wsV1sus6mGFpptcF9qu6NZib+7acjRRjFnC5yTgzVOBLse0c3/EQ8H4
KZ+AAgye2++kFmdfwCjeoPeylUaYL2hEdb/cfSIJD4tulpuuocQf1N/X6+Z7W2ojzz9KpCkVhxYv
iuk+V2/zE5Z+kTwDVEPw/t9FKYTkf4+Viv+AGnyZHI3ZjgfLhccLaVL/kxJ8Y62wBC/muFK4CN92
xotBoTj3u7eQyoKb+NsaEvvQK+8+CYacjwMrsrMSPEmyHEAjmfWFkBi/4ZBF1vWhL9tBYZaXqjk5
0npE8fZTEOexO+hNeZVUQwIDAQABoDAwLgYJKoZIhvcNAQkOMSEwHzAdBgNVHQ4EFgQUV9G4Cp5/
QslDtFRjFOXcjj5kYRkwDQYJKoZIhvcNAQELBQADggEBAAejlSzDMUuAbqSe3zNxOADSTJCqhsJU
FE+0F0lxJlkKB6cDcxSvujoDoCuARk0RF0yLfnQz54qUPjWcPWnawLs9nZF/nzFf/ylF3J41fgVX
VveyKPc7TG40S5zGI5R1Y0zpW0hE/O2vZ4kdD1ZaO7UaUmFPZUcGhJWdf2QJh7enEhK6Z+FM19B/
RTySjmDIYKyMAgh65IDqutJD89FcrQx0UcAK0WCe6xR5dylg0FNiEw4GDorJF+HlMp2YXkUuYHNZ
RAZBvjqoic4CyZ60/HhXUruStn7ElB1hga10HyfGanclmfX2+vU5W+ulkhj1xvo4JHJC4AlmKdFZ
fm69MwU=
-----END CERTIFICATE REQUEST-----

Certificate Authority
Whether it is one-way SSL or two-way SSL, certificate-based communication starts through a handshake mechanism that works on the principles of mutual trust. This trust is rooted at the top level with a root CA who is a certified, highly regulated authority that is trusted and authorized to issue and sign digital certificates.

There are multiple layers of CA with the top-most Certificate Authority known as Root CA which is the most trusted body which can issue Root Certificates and is considered as the primary authority to be trusted. Under Root CA, there can be n number of Intermediate CAs which are themselves trusted by Root CA and are eligible and authorized to issue certificates.

Typically, your web browsers store Root CAs certificates in the trust store, and whenever any secure website is accessed, SSL handshake mechanism works by utilizing this trust store to validate any subsequent intermediate or leaf certificates.

//Generate a Keystore with public and Pricate key along with selfsigned certificate
>>keytool -genkey -alias mugilcert2 -keyalg RSA -keystore “D:\mugil2.jks”

//Exporting a self signed certificate which came along in above step(which is are of no use)
>>keytool -export -alias mugilcert2 -file “D:\mugil2jks.cer” -keystore “D:\mugil2.jks”

//Generate a CSR request to be sent to CA
>>keytool -certreq -alias server -file csr.txt -keystore “D:\mugil2.jks”

Self-Signed Certificate
A self-signed SSL certificate is an SSL Certificate that is issued by the individual using it. It’s issued with software that the user has and controls. This can be good for testing environments but it’s got some major drawbacks, but essentially what you need to know is that when a browser receives an SSL Certificate it’s looking for it to be issued by a party it trusts(CA). When you sign your own certificate you’re essentially vouching for your own identity. The primary operational difference between a self-signed certificate and a CA certificate is that with self-signed, a browser will generally give some type of error, warning that the certificate is not issued by a CA.

Root Certificate, Intermediate Certificate and Leaf (Server) Certificate
Root Certificates are available in the trust-store or root store and a certificate validity is confirmed only if its chain of trust reaches to a trusted CA.Below are the list of companies that holds Root to certificate and could offer intermediate certificates.

  1. IdenTrust
  2. DigiCert
  3. GoDaddy

The above companies has tie-up with companies like google or mozilla which install trust store or root store in users systems.. Root CA is a Certificate Authority that owns one or more trusted roots. That means that they have roots in the trust stores of the major browsers. Intermediate CAs or Sub CAs are Certificate Authorities that issue off an intermediate root. They do not have roots in the browser’s trust stores, instead, their intermediate roots chain back to a trusted third-party root. This is sometimes called cross-signing.

Intermediate Certificates are in turn trusted by a Root Certificate by chain of Trust. CAs issue digital certificates to its clients (usually intermediate CAs).
Server Certificate (also known as Leaf Certificate) is a certificate that has been issued to a server by a intermediate CA. A certificate issued to a server is usually by an intermediate CA and a chain of certificates in the form of certificate bundles gets linked to the Root CA to build a trust chain.

In the above example DigiCert is root CA and Digicert2 extended validation server is Intermeidate CA.

Root Store
A root store contains list of trusted root CA certificates.A public-facing root store is usually maintained under the authority of a major software provider, which distributes their root store along with software which depends upon it to determine trust. Many providers of browsers and operating systems operate their own root store programs, and CAs may apply to be accepted into a root store using the criteria of that program. The device will use whatever root store is native to its OS, otherwise it might use a third-party root store via an app like a web browser. There are several major root programs of note:

  1. Microsoft
  2. Apple
  3. Google
  4. Mozilla

CAs do not issue directly from their roots. They add layers of security by issuing intermediates and then signing certificates with those. This helps to minimize and compartmentalize damage in the event of a mis-issuance or security event. Rather than revoke the root certificate and literally every certificate that it signed by extension, you just revoke the intermediate, which only causes the group of certificates issued off that intermediate to get distrusted.

Google and the other browsers recently distrusted Symantec CA brand SSL certificates. They just removed all of Symantec CA’s roots from their trust stores. Now any certificate that is supposed to chain back to those roots fails and is distrusted