TLS and SSL notes

Following are some concepts used in TLS/SSL configurations:

  1. Private Key: The key that is not shared with other connections but just used to decrypt the payload encrypted with public certificate.
  2. Public Certificate: The certificate that is provided to the remote connection as part of the SSL/TLS negotiations used to encrypt the message.
  3. CSR: certificate signing request is a message sent from an applicant to a certificate authority(CA) in order to apply for a SSL certificate. It usually contains the public key for which the certificate should be issued, identifying information (such as a domain name) and integrity protection (e.g., a digital signature). 
    Before creating a CSR, the applicant first generates a key pair, keeping the private key secret. The CSR contains information identifying the applicant (such as a distinguished name in the case of an X.509 certificate) 
  4. Keystore file, keystore.jks, contains the Application Server’s certificate, including its private key. The keystore file is protected with a password, initially changeit. Change the password using keytool.
  5. Truststore file, cacerts.jks, contains the Application Server’s trusted certificates, including public keys for other entities. For a trusted certificate, the server has confirmed that the public key in the certificate belongs to the certificate’s owner. Trusted certificates generally include those of certification authorities (CAs).
  6. Wildcard certificate—a certificate with the common name *, as in *, rather than a specific host name—can be used for any number of first level sub-domains within a single domain name. For example, a wildcard certificate can be used with,,, and so on.
  7. SubjectAlternativeName or SAN certificate is a certificate that uses the SubjectAlternativeName extension to associate the resulting certificate with multiple specific host names. So one certificate can be used on multiple hosts which are named in the certificate. In the context of clusters, SAN certificates are used in high-availability (HA) configurations in which a load balancer targets two different specific hosts as primary and secondary nodes for fail-over purposes.
  8. Daemons that function as TLS/SSL servers load the keystores when starting up. When a client connects to an TLS/SSL server daemon, the server transmits the certificate loaded at startup time to the client, and the client then uses its truststore to validate the certificate presented by the server.

Command to check the expiration date and details of a certificate:

$ openssl x509 -enddate -noout -in xyzcert.crt
$ openssl x509 -in xyzcert.crt -noout -text

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.