1. What is a certificate?

A certificate is for verifying the identity of any entities involving in a communication flow. The entities can be server / user / client.

Normally, a certificate contains:

• Public key of the server you request
• Meta data: issuer, expire date, server details, signing algorithms

There are 2 types of certificate in terms of Issuer :

• Public certificate: issued by well-known CA such as Digicert, Let's Encrypt Authority, Codomo
• Self-signed certificate: issued by yourself, using OpenSSL or alternatives

3. Client certificate and Server certificate

What is client certificate?

Don't confuse client certificates with server certificates. Both are digital certificates that involve client and server applications but they're two different things.

• A server certificate is sent from the server to the client at the start of a session and is used by the client to authenticate the server.
• A client certificate is sent from the client to the server at the start of a session and is used by the server to authenticate the client.

How client certificate works

Server must enable client certificate authentication.

• Client sends CLIENT HELLO as described in the above image
• Upon receiving the CLIENT HELLO, if the server is configured for Client Certificate Authentication, it will send a list of Distinguished CA names & Client Certificate Request to the client as a part of the SERVER HELLO apart from other details depicted above.
• Upon receiving the Server Hello containing the Client Certificate request & list of Distinguished CA names, the client will perform the following steps:
  • The client uses the CA list available in the SERVER HELLO to determine the mutually trusted CA certificates.
  • The client will then determine the Client Certificates that have been issued by the mutually trusted Certification Authorities.
  • The client will then present the client certificate list to the user so that they can select a certificate to be sent to the Server.
• Upon selection, the client responds with a
  • ClientKeyExchange message which contains the Pre-master secret
  • Certificate message which contains the Client certificate (Doesn’t contain the private key).
  • CertificateVerify message, which is used to provide explicit verification of a client certificate. This message is sent only if the Client Certificate message was sent. The client is authenticated by using its private key to sign a hash of all the messages up to this point. The recipient verifies the signature using the public key of the signer, thus ensuring it was signed with the client’s private key.

NOTE:

• On the Client the Client Certificates must have a Private Key. If absent, then the certificate is ignored.
• If the server doesn’t provide the list of Distinguished CA Names in the SERVER HELLO, then the client will present the user with all the client certificates that it has access to.

Why client certificate is needed?

To strengthen user authentication by implementing in different ways a.k.a. factors:

• By asking information only the user should know (e.g. a password)
• By asking something only the user should have in his possession (e.g. a key, a card, or a digital certificate)
• By asking something that's physically part of the user (e.g. a thumbprint or retinal scan)

Combining 2 or multi factors of authentication makes it significantly more difficult for an attacker to succeed.

4. Other terminologies:

0. Private key is NOT solely for decrypting. Public key is NOT solely for encrypting. If one key signs, the other decrypts.

1. PEM: Privacy-Enhanced mail just means the file contains a base64-encoded bit of data.

Although PEM is widely used for certificates and many PEM files are certificates, be aware PEM is used for many other things as well, such as merely Private key or Public key.

It can have a variety of extensions (.pem, .key, .cer, .cert, more)

Don't assume a PEM file is a certificate; instead check the label in header line.

Format:

• one-line header, consisting of "-----BEGIN "
• A label, and "-----" and
• A one-line footer, consisting of "-----END ", a label, and "-----".

The label determines the type of message encoded. Common labels include "CERTIFICATE", "CERTIFICATE REQUEST", "PRIVATE KEY" and "X509 CRL"

example

-----BEGIN CERTIFICATE-----

MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G

A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y

aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0

ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw

CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy

dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu

dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB

BwNCAARS2I0jiuNn14Y2sSALCX3IybqiIJUvxUpj+oNfzngvj/Niyv2394BWnW4X

uQ4RTEiywK87WRcWMGgJB5kX/t2no0MwQTAPBgNVHRMBAf8EBTADAQH/MA8GA1Ud

DwEB/wQFAwMHBgAwHQYDVR0OBBYEFPC0gf6YEr+1KLlkQAPLzB9mTigDMAoGCCqG

SM49BAMCA0gAMEUCIDGuwD1KPyG+hRf88MeyMQcqOFZD0TbVleF+UsAGQ4enAiEA

l4wOuDwKQa+upc8GftXE2C//4mKANBC6It01gUaTIpo=

-----END CERTIFICATE-----

2. X509: is a standard defining the format of certificate.

Certificate

Serial Number

Signature Algorithm ID

Issuer Name

Validity period: not before, not after

Subject name

Subject Public Key Info

Public Key Algorithm

Subject Public Key

...

Certificate Signature Algorithm

Certificate Signature

3. CER, CRT are both EXTENSIONS of a file containing X509 Certificate. In general, they are the CERTIFICATES

(Just like .mp4 and .avi, they are two different extensions which contain video data.)

4. DER and PEM: they are two different Encodings for certificate file content

• DER: binary encoding
• PEM: encode DER string with base64. PEM is written by OpenSSL

5. pfx, p12: bundle a private key with its public corresponding X.509 certificate.

It can contain a chain of "intermediate" certificate to form a better trust chain.

This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys

6. OpenSSL and Keytool:

• Both OpenSSL and Keytool have the same purpose: generating/storing keys and certificate(s).
• Keytool has the additional feature of manipulating Java's key & cert storage - the KeyStore (JKS)
  • KeyStore is a vault to store key for Java. Likewise, Windows stores certificates in certlm.msc
• Java can only work with certificates/keys contained INSIDE its Keystore. Those certificates and keys are generated using the keytool library, not by using openssl.
• It is possible to generate a key and/or certificate with OpenSSL, and then import that key/cert into a KeyStore using keytool, but you can't put the key/cert into the KeyStore directly using OpenSSL.
• OpenSSL can also be used to create a similar vault, namely PKCS12 (.p12). This is a password protected vault containing keys and certificates (just like Java's keystore). However, it's not compatible with Java... You'd need to convert the .p12 container to .jks before your Java application will be able to work on the certificates.

To list all key stored in cacert file (which is a keystore .jks):

keytool -list -keystore ${cacertsPath} -v

   where ${cacertsPath} is path to cacerts file (JAVA_HOME---> JRE -->lib---> security--> cacerts)

         -v for all details of each entry

eg: keytool -list -keystore /Library/Java/JavaVirtualMachines/amazon-corretto-8.jdk/Contents/Home/jre/lib/security/cacerts -v

7. The basics command line steps to generate a private and public key using OpenSSL are as follow

openssl genrsa -out private.key 1024

openssl req -new -x509 -key private.key -out publickey.cer -days 365

openssl pkcs12 -export -out public_privatekey.pfx -inkey private.key -in publickey.cer

Step 1 – generates a private key

Step 2 – creates a X509 certificate (.cer file) containing your public key which you upload when registering your private application (or upgrading to a partner application).

Step 3 – Export your x509 certificate and private key to a pfx file. If your chosen wrapper library uses the .pem file to sign requests then this step is not required.