Introduction to SSL

SSL, also known as TLS (Transport Layer Security), is widely used in websites no matter what kind of website it is, whether it’s a simple blog or a shopping portal. Moreover, if you have ever noticed the URLs of websites, they either show HTTPS or HTTP. The difference between the two is the ‘S’ at the end. HTTPS indicates that the website is secured by an SSL certificate that helps in securing the communication that happens between your web browser and the website you’re visiting.

In other words, SSL one of the security technologies that offer a secure connection between the web server and web browser. It assures that the data transferred between the web server and browser is secured and original.

Let’s read its history and see how it all started.

Later in 1994 , Netscape made some improvements and launched the second version of SSL, SSLv2 (Deprecated in 2011), that overcame the previous problems and offered security for sensitive information. Thus, SSL became a standard protocol for the protection of HTTP based web traffic.

1995 – Netscape went further down the road to make more improvements to strengthen the cryptographic algorithms to solve the problems of SSLv2. As SSLv2 used weak MAC construction, the upgraded version called SSLv3 was released. This fixed the problem related to SSLv2 and also offered enhanced features like support for several security algorithms that were not supported previously.

1999 – In the form of upgrading SSL3.0, TLS 1.0 (Transport Layer Security) written by Christopher Allen & Tim Dierks, was defined in RFC 2246. As per the RFC, “the differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough to preclude interoperability between TLS 1.0 and SSL 3.0.”

2006 – TLS 1.1 was introduced in RFC 4346

2008 – TLS 1.2 was introduced in RFC 5246

2018 – Unsafe technologies in the previous versions were removed and TLS 1.3, the current version was released. TLS 1.3 offers better privacy than its predecessors.

TLS certificates are still known as SSL certificates, but the reality is that whenever someone purchases an SSL Certificate, they are actually purchasing the latest TLS certificates with options like RSA or DSA encryption. The reason is because SSL is the most commonly used term that has become more familiar among internet users.

Why SSL?

Few other reasons to have an SSL are; it helps to secure communication that happens between the website and the customer’s web-browser, communication on the corporate intranet, email communications sent between the network or any private email address, transfer of information between internal as well as external servers, information sent and received between mobile devices.

Moreover, whenever someone enters any information, it goes through multiple devices before reaching its destination, which can be checked using a simple command prompt: command “tracert.”

For Windows Users:

1. Go to Start and Click on Run
2. Type “cmd” and hit Enter
3. Once the Command Prompt opens, type a website URL. For eg. tracert domain-name.com
4. Hit Enter

You will now see a list of devices. Here, every “node” you see is a device where your sent data gets recorded before reaching its destination. Generally, 20 to 30 listings happen. This means your information has been recorded on all those devices.

Features & Benefits of SSL Certificate Security

SSL Protects Data Through Encryption

SSL/TLS Certificate protects website visitors’ sensitive information which includes their login details, passwords, account details, and credit card numbers by establishing a secured encrypted tunnel between the Client (Web Browser) and the Server. SSL/TLS Certificates come equipped with strong 256-bit encryption standard that cannot be cracked easily.

SSL Confirms Your Identity

It’s not easy to trust someone on the internet, nor can you be sure that the website you are visiting is genuine. Many fake websites dupe their visitors and gain sensitive information by using someone else’s name. SSL certificates can help avoid such situations. The first step in getting an SSL Certificate is to complete the verification process. SSL providers verify the legitimacy of the person or the organization purchasing the SSL certificate through a process that is done based on certain rules and regulations set by CA/B, a joint forum of CAs and Web browsers.

SSL Offers Non-Repudiation

Combination of Encryption, Integrity and Authentication establishes non-repudiation. This means none of the parties in a secured transaction can legally say that their communication has come from someone else. SSL removes the option of a party to repudiate or in other words “take back” information which has been communicated by them online.

Helps in Avoiding “Not Secure” Warning Message

Earlier in 2014, the leader of Search Engines, Google, declared that websites that have an SSL/TLS Certificate installed would get a little more preference in search results, as a part of their mission to make the entire websafe and encrypted. Since 2018, Google Chrome and other popular web browsers like Mozilla Firefox have taken one more serious step towards it. With the release of their latest web browser versions, they even started displaying the “Not-secure” warning on non-SSL websites. Some websites even fail to load on these popular browsers. So, if you want your visitors to visit your website, it’s mandatory to have an SSL.

What could go Wrong, if an SSL/TLS Certificate is not Installed?

APT (Advanced Persistent Threats)

As the name implies, it is an “Advanced” attack, which means attacks carried out by those who are proficient in technology and well-funded by an external entity. Various techniques like drive-by-downloads and Microsoft SQL injection are also used.

Moreover, it is a targeted attack, done with a purpose. However, it does not mean all targeted attacks are APT, as it uses customized attacking methods such as zero-day vulnerability exploits, viruses, worms and many other techniques. It is a type of attack that takes time and often it is noticed after a very long time, i.e., after the damage is done.

Man-in-the-middle (MITM) Attacks

MITM is a serious problem, which is a threat to authentication capabilities. It’s one of the attacks where an attacker is capable of secretly changing the data between two people who think they are directly communicating with each other and it is quite challenging as it is done remotely with a fake address. In other words, it is one of the attacks that takes place when two systems are intercepted by an unauthorized entity.

Protocol Attacks

It is one of the attacks that focuses on the resources of the server. Attacks like Slowloris and HTTP Flood are examples of this kind of attack. HTTP flood is an attack which takes place by portraying fake GET or POST requests, making it appear as legit. Additionally, less bandwidth is used for HTTP flood attack, which forces the server to use maximum resources. On the other hand, Slowloris an invention of Robert “RSnake” Hansen, is a denial-of-service attack tool which is used to attack a web server with minimal resources. In other words, Slowloris tries to keep multiple connections open with HTTP flooding. The desired target is connected with the partial request of HTTP header that never completes resulting in denying of any additional connection attempt from clients, due to attack it’s filled with the maximum concurrent connection pool.

HOW DOES SSL WORK?

As per a layman’s standpoint,

• First, the server or browser tries to connect with an SSL secured website (i.e., web server). The server or browser makes a request to identify the web server.
• The web server sends a copy of the SSL/TLS Certificate to the web browser or server.
• The web server or browser checks whether the SSL certificate is trustworthy or not. If it is trustworthy, it sends a message to the web server.
• To start an SSL encrypted session, the web server sends back a digitally signed acknowledgment.
• Finally, the encrypted session begins and the encrypted data is shared between the server/browser.

Also, the working of an SSL may look like a seamless process. But there are several things working in the background that make the SSL connection successful. For example, what are the different types of encryption, how the authentication of the message is done, what ciphers & algorithms are used and much more.

SSL Architecture and Protocols

SSL/TLS is a protocol which operates directly on top of the TCP, (though there are some other implementations for a datagram-based protocol like UDP.) This is the reason how protocols of higher levels are left unchanged while providing a secured connection (for example, HTTP). One thing to note is that HTTP is identical to HTTPS beneath the SSL layer.

SSL involves two entities, Server and Client. Here, Client is the one that initiates the transaction and the other entity Server is the one that responds to it. (Client is the Web-browser and the Website server is the Server.)

SSL Handshake Protocol

SSL Handshake Protocol is the technical name given to the process which establishes an HTTPS connection. Almost all the important work is done here in this protocol. In other words, it establishes a secure channel between the server and the client.

The main purpose of the SSL handshake protocol is to perform all the needed cryptographic work for having a secure connection such as checking the authenticity of the SSL certificate, are they created and signed by a trusted Certificate Authority, proving that the private key owned by a server is associated with the certificate and this entire SSL handshake is done within few hundred milliseconds. Moreover, SSL handshake is the first thing that happens in an HTTPS connection, even before the webpage loads completely.

Every software is different from one another. Due to this, the first step in the handshake protocol allows the client and server to share their capabilities to find out the mutually supported cryptographic features. For example, Web browsers are one of the typical clients, but their features differ depending upon the browsers like Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. Similarly, when it comes to the server, like Windows Server, Apache and NGINX, their features are different from each other.

Though one thing to note that SSL Handshake is a series of several steps that is done to achieve the following three main tasks.

• Exchange of Encryption Capabilities
• Authentication of the SSL/TLS Certificate
• Exchanging or Generating a Session Key

If you are interested in understanding what the exact process is, below are the complete illustrated steps. (Note that in TLS 1.3, the forthcoming protocol version, the handshake design has changed. Thus, these steps are related to TLS 1.2.)

SSL Record Protocol

The SSL Record Protocol is responsible for handling encryption of all messages. This protocol offers a common format used to frame all the messages of the Handshake, Alerts, ChangeCiperSpec and Application Protocols. In other words, it offers basic security to other higher layer protocols, namely Handshake Protocol, Change Cipher Spec Protocol and Alert Protocol.

SSL Alert Protocol

This protocol provides SSL related alerts, as it is responsible to handle questionable type of packets.

Generally, it handles three different types of alert messages:

• Warning
• Critical
• Fatal

Here, the session is further restricted depending on the received message (i.e., warning or critical) or else terminated (fatal).

The ChangeCipher Spec Protocol

The change cipher spec protocol occurs for signaling the transitions in cipher strategies. It contains a single message which carries a single value byte of 1. The purpose of this protocol is to compress and encrypt that message under the connection state. Likewise, the message of this protocol is sent by both the party server and the client for notifying the receiver that successive records will stay protected under the newly exchanged CipherSpec and keys.

Authentication

Network communications are generally done between two clients — for example, a web browser and a server. Here, client authentication is the identification of a client by a server and server authentication is the identification of a server by a client. (For example, the client is the person who is using a software/web browser and the server is the organization running their server at the network address.)

Server and Client authentication are not limited to the form of authentication supported by the certificates, but it also ensures nonrepudiation. For example, an email message with the digital signature combined with the certificate identifies and authenticates the sender of the message and at the same time makes it difficult for the signer to tell that the email is not sent by that person.

One thing to note is that Client authentication based on certificates are part of the SSL protocol. Here, the client digitally signs a piece of data generated randomly and sends that signed data as well as the certificate to the network. Lastly, the server confirms the validity of the certificate after validating the signature.

1. The client software manages a database which consists of private keys corresponding to the public keys published in all the certificates issued for that client. Here, the client asks for the password of the database to access it for the first time for any given session. For example, the user attempting to access an SSL-enabled server requires authentication for the certificate-based client.

Note: Once the password is entered, it will not be asked again during the whole session, even to access other SSL-enabled servers.

1. After that, the Client unlocks the database consisting of the private-key and retrieves it for the user’s certificate and uses that private key for signing data which is generated randomly from the input made by both the server and the client. In return, the data and the digital signature work as evidence that the private key is valid. Additionally, a digital signature is only created with a private key and it’s validated with the corresponding public key against the data which is signed and it stays unique to the SSL session.

3. Randomly generated data as well as the user’s certificate, are both sent across the network by the client

4. To authenticate the identity of the user, the server uses both the signed data as well as the certificate.

5. The server may also perform other authentication tasks like checking whether the certificate is stored in an LDAP directory in the user’s entry, presented by the client. And once it is checked, it also evaluates whether the identified user is allowed to access the requested resource. Furthermore, the evaluation process may use other authorization mechanisms, maybe company databases or information consisting of an LDAP directory. If the result of the evaluation is positive, then the server will allow the client to access the requested resources.

Here, the authentication part of the client and the server interaction is replaced by the certificates. Rather than requesting the user to send passwords through the network frequently, the single sign-on feature is used. Here, the user enters the password of the private-key database for the first time, without sending it through the network. Once it’s done for the whole session, the user’s certificate is provided by the client to authenticate every new server encountered by the user. Lastly, existing authorization is not affected, which was founded on the authenticated user identity.

Encryption

Encryption Behind SSL/TLS Cryptography

SSL/TLS is one of the standard security technologies that offer an encrypted link between a client (browser) and a server (website) or a mail client like Outlook, to transmit sensitive information like Credit Card details, Login Details, Social Security Numbers safely.

But how it’s all achieved? Let’s understand the technology that works behind SSL encryption to provide a secure connection, namely Public Key (Asymmetric) encryption and Symmetric Key encryption.

What is Public-Key Encryption and How does it Work in Certificates?

Public-key encryption, also called as Asymmetric Encryption is one of the encryption schemes that uses two different keys namely a public key and a private key. The Public Key will be accessible to everyone as it’s public and Private Key will remain private with the owner of that key. Though these keys are mathematically related, they are not identical. Here, both the keys are used for different purposes. The public key is used to encrypt the data, whereas the Private key is used to decrypt it.

Likewise, Asymmetric encryption uses certain encryption algorithms such as RSA & DSA to create the public and private keys that are based on the difficulty of mathematical problems. However, from a computational point of view, it’s quite easy to make the public and private keys and to encrypt with the public key and decrypt with the private key. But, it’s almost impossible for anyone to derive the private key based on the public key.

Note: Session keys often change and many times, a different session key is used for each message.

Bulk/Symmetric Encryption

As we saw earlier, to confirm the genuineness of the server, the authentication process takes place through the Public Key Encryption (Asymmetric Encryption) and Digital Signature. But, once the server authentication is done, for the rest of the session, the Client and the Server make use of Bulk/Symmetric- Key encryption, for encrypting all the exchanged information and detection of any tampering.

In other words, asymmetric encryption is used at the time of the SSL Handshake as a verification method, where the browser and the server negotiate an encrypted connection and exchange Session Keys.The session keys use symmetric encryption to further communicate during the entire secure session.

Let’s understand the difference between the two:

• Asymmetric Encryption
• Bulk/Symmetric Encryption

What Is Bulk/Symmetric Encryption and How It Differs from Asymmetric Encryption?

Symmetric encryption is the encryption method which involves one secret key to cipher and decipher the information. It’s one of the old techniques, which uses numbers, words, or strings of random alphabets as a secret key.

However, to encrypt and decrypt the message, the recipient must be aware of the secret key. Some examples of symmetric encryption algorithm are Blowfish, AES, DES, RC4, RC5 and RC6.Among them, the most widely used algorithms are AES-128, AES-192, and AES-256.

Besides, a message encrypted via public key can only be decrypted through its private key and a message encrypted through a private key can only be decrypted with its public key. However, the public key does not require any security and it’s available to anyone over the internet. Lastly, Asymmetric encryption is one of the most widely used encryption for daily communication over the internet. Some of the well-known asymmetric key encryption algorithms are ElGamal, RSA and DSA.

Quick Look at the Differences Between Asymmetric & Symmetric Encryption

• A single key is used by symmetric encryption and it’s shared among people who are looking to receive the message whereas asymmetrical encryption uses a pair of keys called public and private keys for encrypting as well as decrypting the message whenever the communication takes place.
• Comparatively, Symmetric encryption is an old method, whereas Asymmetric is new.
• Asymmetric encryption was invented to overcome shortcomings of the Symmetric encryption model of sharing the key. Asymmetric encryption eliminates the sharing of the key by making using of a pair of public-private keys.
• Asymmetric encryption is more time consuming compared to Symmetric encryption.

Asymmetric & Symmetric Encryption: How SSL/TLS Uses Both?

PKI (Public Key Infrastructure), the set of policies, procedures, hardware, software and people are important for creating, managing, using, storing, distributing and even revoking digital certificates. Using Certificate Authority (CA), PKI binds keys with user identities. For example, SSL Certificates contain an asymmetric public key and a private key pair.

• Copy of asymmetric public key is sent to the Server.
• Once the copy is received, the symmetric session key is created by the Browser while encrypting it with the asymmetric public key and sends it back to the server.
• To get the symmetric session key, the Server uses an asymmetric private key to decrypt the encrypted session key.
• Now, Server & Browser, along with the symmetric session key encrypt and decrypt all the transmitted data. Lastly, it allows a secure channel as only the server and browser are aware of that symmetric session key and it’s used only for that session. If the browser wants to repeat the same session with the server the next day, a new session key will be created.

Ciphers and Algorithms

First, let’s see what ciphers are and then we will get into details of cipher suites. Put simply, ciphers are algorithms. To be more precise they are a set of instructions to perform a cryptographic function which can be encryption, decryption, digital signatures or hashing.

As the years pass by, ciphers have changed a lot and become more and more complex. But the concept behind ciphers is still the same. Whether it’s the first historical Cipher of Caesar, the notorious Enigma cipher of World War II or any algorithm of today’s date, the idea is still the same; encoding or enciphering a message in a way that only the intended party or a person can read it.

Cipher Suite: What is it and What Makes it so Important?

A cipher suite is a set of algorithms used to help determine the security settings at the time of the SSL/TLS handshake. When the ClientHello and ServerHello messages are exchanged, firstly the client has to send a prioritized list of supported cipher suites and then the server responds with its selected cipher suite.

In other words, cipher Suite is a set of information which helps in letting know how the web server will communicate data securely over HTTPS, SMTP, FTPS and other network protocols.

Here, the web server uses some of the algorithms and protocols to know how it will secure the web traffic.

A typical cipher suite looks like below.

ECDHE-ECDSA-AES128-GCM-SHA256

Some of the things that depend on cipher suites are:

• The security level of the HTTPS traffic, where your safety and that of your website visitors are considered.
• The compatibility of HTTPS traffic to decide who can see warning messages, errors or other issues related to it.
• The performance of your HTTPS traffic, such as how fast your website loads on the user’s device or what is the page speed of your website.

Cipher suites are a blend of different things just like recipes that are made with different ingredients. For example, to make banana bread, we need certain ingredients like:

FLOUR-BANANAS-EGGS-SUGAR-BUTTER

Same as the above, to provide a successful and secured connection, cipher suite needs different ingredients that are protocols and algorithms instead of food items.

• ECDHE is a type of Key Exchange Algorithm
• ECDSA is a type of Authentication Algorithm
• AES128 is a type of Bulk Encryption Algorithm
• SHA256 is a type of MAC Algorithm

If your web server uses HTTPS, then it will have a list of cipher suites separated by a colon (:) that looks like:

ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256

So, after binding it with TLS, its anatomy will look like the below the example where TLS is similar to the latest version, TLS 1.3:

What Are Cipher Suites Made Of?

Below are the four different components based on which cipher suites are made:

1. Key Exchange Algorithm:

To assure confidentiality at the time of data transmission through different secure file transfer protocols such as HTTPS, the data needs to be encrypted. To get this process in action, two communicating parties need to have a shared key that can encrypt and decrypt the data. This is achieved with symmetric encryption. But Symmetric encryption comes with a weakness. For example, if the shared key becomes accessible to attackers, they can easily decrypt all the data. To avoid such situations, the industry has developed certain key exchange protocols. They are the key exchange algorithms such as ECDHE, ECDH, DHE, and RSA that help in securing the exchange of symmetric keys over the networks.

2. Authentication Algorithm:

To ensure secure and correct data transmission, a web server has to verify the identity of the user who will have access to the data. Basically, in this process, a user is asked to provide credentials that include a username and password. To keep this authentication process secure, cipher suites have an authentication algorithm such as ECDSA, RSA, and DSA.

3. Bulk Encryption Algorithm:

To ensure the secure transmission of data, cipher suites offer a bulk data encryption algorithm. Some of the widely used algorithms that come under this category are CAMELLA, AES, and 3DES. Moreover, as per Microsoft, the key of bulk encryption is generated by hashing one of the MAC keys with CryptHashSessionKey along with the content of the message and other data.

4. MAC (Message Authentication Code) Algorithm:

MAC (Message Authentication Code) algorithm is one of the algorithms, which is used for the verification and authentication of the received message. Here, both the sender and the receiver share a common key to make the MAC algorithm work. But it does have a drawback, as it’s not capable enough to protect the message even if any intentional change occurs in the authentication. Due to this, it is possibile for an intruder to make a change in the message while calculating the new checksum and replacing it with the original one. To avoid such situations, CRS (Cyclic Redundancy Check) algorithms are used which can help at a certain level by randomly detecting damaged parts of the messages. However, it cannot detect conscious damages done by an attacker. Some of the common algorithms are MD5 and SHA.

Note: GCM (Galois Counter Mode), is a type of cipher mode, a block of operation which uses universal hashing over a binary Galois field to offer authenticated encryption and authenticated decryption. In other words, it’s a mode of operation for symmetric key cryptographic block ciphers widely used due to their performance and efficiency — for example, running AES (Advanced Encryption Standard) in GCM with 256-bit keys.

What Do Cipher Suites Do?

The cipher suites that are on the web server help in determining how secure, fast and compatible your HTTPS traffic will be. Moreover, it’s important to know that a cipher suite used by a web server affects several things like security, speed, and compatibility that are essential and helpful for webmasters to make improvements by adjusting used cipher suites.

Cipher Suites: Selection & Compatibility

Also, Mozilla, the inventor of the Firefox web browser, provides a resource for the recommended security configurations, including sets of cipher suites further divided into the following three different categories.

• Modern Compatibility

It’s for the clients that support TLS 1.3 and do not need backward compatibility. It provides an extremely high level of security. The cipher suites listed in this category are the latest ones, which can be used by anyone who do not expect any website visitors who rely on any older machines or web browsers.
For example, a tech blogger, may not run into a problem for using the modern cipher suites as mostly their users will already be tech-savvy who will most likely stay updated.

• Intermediate Compatibility

It has a default set of cipher suites compatible with most websites.
For example – Services that do not want compatibility with legacy clients like WinXP, but still want to support various types of clients compatible with Chrome 1, Firefox 1, and Safari 1.

• Old Backward Compatibility

It’s a set of cipher suites that are not advisable to use but could be used as a last resort for websites which rely on users who have older machines, operating systems and older software.
For example – With Clients using Windows XP/IE6

How to Know Which Cipher Suites are Used by Web Servers?

Public Key Infrastructure (PKI)

What is Public Key Infrastructure?

For most people, PKI means the public-key infrastructure as often seen on the Internet. However, the meaning of PKI is much broader because its development is originally for other uses. Also, the term “PKI or Internet PKI” was introduced by PKIX, a working group of IETF (Internet Engineering Task Force) for using it on the Internet through X.509, where it focuses on how browsers validate and consume certificates.

In other words, PKI (Public Key Infrastructure) is a set of rules, procedures and policies that are needed to create, distribute, manage, store, use or revoke certificates and manage public-key encryption.

Apart from this, PKI is based on asymmetric encryption and it is majorly used to secure electronic communication for email, internet banking, online shopping and also communications of millions of users and the website to which they connect with the help of HTTPS.

Key Components of PKI (Public Key Infrastructure)

Certificate Policy

Fundamentally, the certificate policy is the security requirement used to define the hierarchy and structure of the PKI environment. Also, the policies bounded with the handling & management of keys, revocation, profiles & formats of the certificate, secure storage with many other details.

Root Certificate Authority (CA)

As its name implies, root CA is an entity which is the “main root of trust” in the implementation of PKI and it’s accountable for identity authentication in the PKI environment.

Subordinate or Intermediate CA

The intermediate or subordinate CA is certified through a root CA to use it specifically as per the definition provided by the certificate policy. Additionally, digital certificates are signed and issued by sub-CAs.

Certificate Database

As its name implies, it’s a database of certificates which stores the records of a certificate.

Revocation Services

They are the servers who post updated CRLs (Certificate Revocation Lists) or OCSP (Online Certificate Status Protocol) responders which makes use of CRLS to respond to revocation lookup checks for all the devices that cannot process CRLs by their own.

Digital Certificates

It’s a type of digital identity which is embedded with a device which offers security and authentication between servers and the devices while granting access to resources. It’s generally issued by the sub-CA.

PKI Hierarchy

PKI hierarchy or Hierarchical PKI is one of the PKI trust models. PKI hierarchy can have one or multiple tiers. If it’s a single-tier PKI environment, the Root CA will only be your CA server. If it’s multiple tiers, the Root CA will issue other subordinate CA certificates right below the root and there won’t be any need to access the Root CA server daily. All the certificates can be requested by users from the subordinate CA itself while letting the Root CA offline.

Likewise, having the Root CA offline will also increase the security of the PKI environment as no one will have network access to the server. Lastly, how many tiers can be used depends on what your goal is with the PKI environment, the requirements of security or the trust you want to keep in the environment.

Let’s illustrate PKI. In the below diagram, we can see that every CA provides rights to sub-CAs (Subordinate CAs) to sign digital certificates for devices. And these digital certificates stay at the end of the hierarchy. They are accepted by the devices and authorized by the sub-CA that signs and generates them. They are also called as device certificates.

Apart from this, some of the reasons for the PKI environment to be arranged in hierarchies is because it allows to revoke or deny access to selected levels if a leak or compromise of a private key happens. Below is an example of the same.

Lastly, one of the main benefits is that a single sub-CA is capable and is generating more than millions of device certificates used to authenticate millions of devices with only one single public key of sub-CA.

TLS 1.3: Faster and More Secure

You can say, it is more like a milestone, as due to accomplishing 0-RTT Resumption, the client can connect with the server, even before TLS 1.3 permits a zero-round trip handshake. It is typically accomplished by storing secret information such as Session ID or Session Tickets of previous sessions and using them for future use whenever both parties connect.

Benefits of TLS 1.3 over TLS 1.2

TLS 1.2 provides some extensive improvements over TLS 1.2. Hence, optional parts that caused the chances of vulnerability have been removed and provided support for stronger ciphers, which is required to implement Perfect Forward Secrecy (PFS) and other like short handshake process.

Security

Granted, it’s possible to deploy TLS 1.2 securely, but the optional parts of the protocols and some outdated ciphers have been exploited by several high-profile vulnerabilities. Here, TLS 1.3 helps by removing those problematic options and provides support to algorithms which is not known to any vulnerabilities till date.

The renegotiation attack is an example of such a threat which is not possible in TLS 1.3.

Privacy

PFS is enabled by default in TLS 1.3. Due to this, an additional layer of confidentiality is added to an encrypted session, which ensures that the traffic can only be decrypted by the two endpoints. Additionally, even if someone tries to record an encrypted session and later get access to the private key of the server, PFS will not allow using that key for decrypting the session.

Performance

As already discussed, with TLS 1.3, the entire round trip is eliminated from the connection while establishing handshake, resulting in half encryption latency. Additionally, it’s possible to send data to the server on the first message itself, if you access a previously visited website, which is known as 0-RTT (Zero Round Trip Time).

TLS 1.3 vs. TLS 1.2

Removed Vulnerable Algorithms and Ciphers

It removed support for ciphers and algorithms that are both theoretically and practically vulnerable to attacks:

• RSA Key Exchange
• RC4 Stream Cipher
• CBC (Block) Mode Ciphers
• MD5 Algorithm
• SHA-1 Hash Function
• Many short-lived Diffie-Hellman groups
• DES
• 3-DES
• Export Strength Ciphers

Removed RSA key exchange while making Perfect Forward Secrecy (PFS) mandatory

RSA and Diffie-Hellman, two popular mechanisms were used to exchange the secure session key at the time of HTTPS connection next to the SSL handshake. Now RSA, along with all static (non-Forward Secret) has been removed as it has specific problems like Oracle Padding Attacks.

Moreover, RSA doesn’t offer an ephemeral key mode, which is mandatory for PFS. And the reason to make PFS compulsory is that without that the private key can get compromised and the encrypted conversation can be decrypted, and if there’s perfect forward secrecy, it can provide security against it. Eventually, reducing the time by eliminating one entire round-trip and giving better performance of the website.

As the negotiations have been eliminated from the handshake process, the size of the cipher suites has also got smaller.

TLS 1.2 and its prior versions used cipher suites, which included four ciphers. For example:

Moreover, the defined encryption algorithm of the TLS 1.3 cipher suite must be an AEAD (Authenticated Encryption with Additional Data) algorithm, as it provides both confidentiality and message authentication in a single crypto algorithm. Here, the main concept of the integrity and encryption function has been changed with the AEAD algorithm.

Due to the introduction of AEAD and reduction of the supported cipher, it will not be possible to send unencrypted data through TLS 1.3, which was an option in a TLS 1.2 by using NULL encryption cipher suites.

Lastly, the recommended cipher suite list has also shrunk down significantly.

Browsers Supporting TLS 1.3

Mostly, all the popular web browsers support TLS 1.3:

• Google Chrome Ver. 67+
• Mozilla Firefox Ver. 61+
• Apple – Mac OS 10.3 and iOS 11

How to Upgrade TLS 1.3 on Server?

TLS 1.3 update is similar to upgrading any software library. Simply, update SSL/TLS library to one of the below versions:

• GnuTLS 3.5x
• Google’s Boring SSL (Latest)
• FaceBook’s Fizz (Latest)
• OpenSSL 1.1.1

How to Enable TLS 1.3 in Different Web Browsers?

Different web browsers require different steps.

Enabling TLS 1.3 in Google Chrome

• Open Google Chrome
• In the address bar, type “chrome://flags/” and press Enter.
• Go to TLS 1.3 and select the option Enable TLS 1.3 (Draft 23)
• Now, go to https://istlsfastyet.com/ and press F12 and go to the tab “Security”
• Reload the website and under the “Main origin,” click on the listed link

Enabling TLS 1.3 in Mozilla Firefox

• Open Firefox and type “about:config” in the address bar and hit Enter
• Search for tls.version.max
• Double click on it and change the value to 4
• Restart Firefox and go to https://istlsfastyet.com/
• In the URL bar, click on the padlock icon, go to Connection and under that, click on More Information
• A Certificate Details window will open and in that, at the bottom under technical details, you will find that the website is protected with the TLS 1.3 protocol.

TLS 1.3 Errors

Browser Error

Users may see an error while opening your website
ERR_SSL_VERSION_INTERFERENCE

It means TLS version is not available mutually between the client and the server for the connection. It generally happens when there’s a mismatch in TLS 1.3 versions supported by the web browser and the web server.

Note: Due to these types of situations, it’s essential to support TLS 1.2.

TLS 1.3 Older Version Error

Generally, this problem occurs when the older version of TLS 1.3 draft process is used, which was available before the protocol was finalized. To avoid, be assured you and your website visitors are using the latest TLS 1.3 version with the respective browsers, software libraries and OSs. Trying to connect via an outdated draft version of TLS 1.3 may cause errors.

Is it a Right Time to Start using TLS 1.3?

It has almost been a year since TLS 1.3 has been officially released, yet it has not been adopted as it has to be. But, due to the compulsion of SSL/TLS and HTTPS and the users being more aware of cybersecurity, maybe it will be used at large in the next two to three years.

Trust Hierarchy

Who decides whether a CA is Trustworthy?

Authorized CA ‘membership’ programs are operated by operating systems, browsers and mobile devices, where the CA must meet the detailed criteria for being a member. Once the CAs are accepted, they can issue SSL Certificates that are trusted by browsers, devices and people relying on it.

However, there are a limited number of authorized CAs. Whether they are private companies or government entities, the longer the CA is active, the more the browsers and devices will trust the certificates issued by that CA. Likewise, to be trusted, certificates must be able to provide backward compatibility with older versions of browsers and specifically for mobile devices. This is also known as ubiquity, one of the important features of a CA. All these happen in a hierarchical manner, which is also known as Trust Hierarchy of a CA.

Hierarchy of Trust

Browsers, operating systems, devices and even mobile carrier operate a root store which is a database of all the approved CAs that comes pre-installed in them. Also, CA is trusted if their Root Certificate is accepted by that root store.

Generally, CAs create several Intermediate CA (ICA) Root Certificates that are used to issue end-entity certificates, for example, SSL Certificates, referred to as Trust Hierarchy and it looks like below:

What is Certificate Authorities (CAs)

A Certification Authority or Certificate Authority (CA), is one of the trusted entities that issue security certificates. These certificates help in verifying the ownership of public keys used to secure communication on the internet. It is a part of the PKI (Public Key Infrastructure) with the Registration Authority (RA) who helps in verifying the information provided by the requester of a security certificate. And, once the requested information is verified, CA will issue a certificate.

In other words, a CA is a trusted third-party entity that offers security certificates in the X.509 format, standard to organizations that wish to assure users that they provide secure authentication and connection. These security certificates, generally known as SSL/TLS Certificates provided by CAs, which helps in building trust between the users and the providers.

The business of Certificate Authority is fragmented worldwide with providers dominating their home market. But the market for globally trusted SSL/TLS Certificate who provides it legally binding digital signatures and links to regulations, local law and accreditation schemes of certificate authorities are still limited with the handful of multinational CAs like Sectigo, DigiCert Group, GoDaddy Group, GlobalSign and further their resellers like TheSSLStore, RapidSSLOnline, CheapSSLSecurity.

What is Root Programs?

Some major softwares come equipped with a list of CAs (Certificate Authorities) that are by default trusted. Due to this, it becomes easier for users to validate certificates and easier for organizations or people who are requesting a certificate to know which certificate authorities are trustworthy and can issue a widely trusted certificate. And it’s one of the important things every site administrator will look for while getting a certificate, as they would like to go for a certificate which is trusted by nearly all the website visitors. For all these, documents and guidelines are maintained under the regulations and restrictions made by the CA/B Forum’s Baseline Requirements, known as Root Certificate Programs (RCP) and they have the responsibility to tell what procedures are required by a company to get the Root Certificate to be included in the browser.

In other words, policies and processes used by a software provider to decide which Certificate Authority’s Root Certificate should be trusted by the software are known as Root Programs or Root Certificate Programs. Lastly, to maintain its trust, it processes through many 3rd party auditing.

Some of the globally known Root Programs are:

• Apple Root Program
• Oracle Java Root Program
• Mozilla Root Program
• Microsoft Root Program

What are Roots/Intermediates?

Security provided by SSL certificates is based on a Chain of Trust that originates from the Root Certificate of Certificate Authorities like Sectigo, DigiCert, GeoTrust, etc to the user’s certificate. And further, these SSL certificates are accepted by popular web browsers that contain the validated digital signature of the CA. Though the CA’s identity is built by adding the root certificates in the web browsers and without that, no browser would know whether to accept an SSL Certificate issued by a CA.

Furthermore, the Certificate Authorities are very strict with their guidelines and to guard their Root Certificates from getting compromised, they use an Intermediate Certificate which helps in issuing the user’s end-entity or leaf certificate.

Let’s understand what Roots and Intermediate Certificate are.

Root Certificate is a public key certificate, which helps in identifying a root certificate authority. These root certificates are self-signed while forming the basis of X.509 based PKI (Public Key Infrastructure), used to issue other certificates. Additionally, the lifespan of these root certificates is more than the leaf SSL certificates, that are two years and one CA can have many root certificates.

What is Leaf Certificate?

A leaf certificate, also known as the end-entity certificate, is the last non-CA certificate of the chain which consists of a public key which is used by the users. These are the end-users’ SSL Certificates which is not directly issued by the Certificate Authorities from their roots, as those roots are much valuable and a lot of risks are involved around it.

Certificate Chain / Chain of Trust

A chain of trust is established by validating the component of hardware and software from the end entity to the root certificate. The main reason behind establishing it is to ensure that the trusted software and hardware keep getting used while keeping the flexibility.

Types of SSL Certificate

Additionally, SSL/TLS Certificates are categorized based on two characteristics:

• Validation Level
• Certificate Functionality

Let’s look at each of them in detail.

What are the Different Validation Levels of SSL Certificates?

When it comes to validation of SSL/TLS Certificates, there are three different levels. Below are the three different types of validation:

1. Domain Validation (DV)
2. Organization Validation (OV)
3. Extended Validation (EV)

2. Organization Validation (OV) – OV was the first SSL certificate that came into existence. Later, DV was created to expand greater access towards encryption, and EV was created to offer the highest degree of authentication. But the very first was OV. To get an Organization Validated SSL/TLS Certificate, it’s mandatory for an organization to go through a light business vetting process, in return, they get the certificate that displays the details of the verified business. Before issuing an OV SSL certificate, the CA will verify the organization’s credentials of the applicant.

3. Extended Validation (EV) – EV SSL/TLS Certificates offer the highest level of authentication. The vetting process of an EV SSL certificate is also very stringent when compared to DV and OV SSL certificates. It verifies several things regarding your business, such as Physical Address, Telephone Verification, and Operational Existence of your business, which can take anywhere from 1 to 5 days.

Different Types of SSL Certificates

There are four different types of SSL/TLS Certificates.

• Single Domain
• Multi-Domain
• Wildcard
• Multi-Domain Wildcard

For example, a single domain SSL certificate can protect
www.My-New-Domain.com and My-New-Domain.com but it cannot protect blog.My-New-Domain.com or mail.My-New-Domain.com

Multi-Domain/SAN SSL

Multi-Domain/SAN certificates also called as UCC (Unified Communications Certificates) are certificates that can encrypt multiple domains. These certificates will help save a lot of time and money as a single certificate is enough to secure up to 250 domains and subdomains. Multi-Domain certificates come with 2 to 4 SANs and based on your needs, you can purchase additional SANs. If you are an organization that has multiple domains and subdomains, Multi-Domain/SAN certificates are for you.

For example, a multi-domain SSL certificate can secure the following domains

• www.My-New-Domain.com
• www.My-New-Domain2.com
• secure.My-New-Domain.com
• www.My-New-Domain.org
• mail.My-New-Domain.com.net
• dev.My-New-Domain2.org

Wildcard SSL

Do you have one main domain with multiple sub-domains? If yes, you do not have to purchase separate SANs to encrypt the main domain and all its sub-domains? Certificate Authorities offer Wildcard SSL/TLS Certificates that can help you protect an unlimited number of sub-domains.

For example, a wildcard SSL certificate you purchase for www.My-New-Domain.com, will allow you to secure its subdomains like the following.

• mail.My-New-Domain.com
• forum.My-New-Domain.com
• blog.My-New-Domain.com
• and many more

Moreover, EV Wildcard SSL/TLS Certificates are not available, so there’s no other way around other than settling for an OV. If you’re looking to encrypt sub-domains of multiple domains, then you will need to purchase multiple Wildcards for those different domains.

Multi-Domain Wildcard SSL

Following are domains and subdomains a multi-domain wildcard SSL certificate can secure.

• My-New-Domain-1.com
• www.My-New-Domain-1.com
• My-New-Domain-2.org
• My-New-Domain-2.net
• blog.My-New-Domain-2.net
• My-New-Domain-3.com
• My-New-Domain-1.edu

Here, you will get two options in one single SSL Certificate. Other than protecting multiple domains, you will also be able to secure subdomain levels.

SSL/TLS: Structure & Formats

Version 1 of X.509

X.509 Version 1 certificate contains the below mentioned basic fields:

Version: Specifying the number of encoded certificates, where currently the values of this field are 0,1 or 2.
Serial Number: It contains a unique and positive integer assigned to the certificate by the CA (Certificate Authority).

Signature Algorithm: It contains an object identifier (OID) specifying which algorithm will be used by the CA to sign the certificate. For example, 1.2.840.113549.1.1.5 specifies an SHA-1 hashing algorithm in combination with the RSA encryption algorithm.

Issuer: It contains the X.500 DN (Distinguished Name) of the certificate authority that created and signed the certificate, where X.500 is a computer network standards’ series that covers the services of an electronic directory.

Validity: As the name implies, contains the validity period, i.e., issuance date and expiry date of the certificate.

Subject: Contains the name of the entity related to the public key contained in the certificate as per the X.500 distinguished name.

Public Key: Contains information related to the public key and its associated algorithm.

Version 2 of X.509

X.509 version 2 certificate contains the below mentioned fields along with the basic fields of Version 1.

Issuer Unique Identifier : It’s an optional field which contains a value to uniquely identify the certificate authority.

Subject Unique Identifier : It’s an optional field which is used to provide a unique ID for the subject.

Version 3 of X.509

Along with Version 2 and Version 1 of X.509 certificate, it contains an additional field extension which is used to support different applications.

Extensions : It is defined as a series of data type Extensions, where every extension has three different parts, namely Extension ID (extnId), Critical and Extension Value (extnValue).

X.509 Certificate File Format

Furthermore, there are different X.509 certificate formats like DER, PEM, PKCS#7 and PKCS#12. CAs will provide the certificates with one of these formats. Here, PKCS#7 and PEM formats use Base64 ASCII encoding & DER and PKCS#12 use binary encoding. Likewise, all the certificates have different extensions based on their used encoding and format.

PEM Format

Usually, CAs (Certificate Authorities), provide certificates in PEM format which are encoded files in Base64 ASCII. The file type of this certificate can be .crt, .pem, .cer or .key. And this .pem file can include the server certificate, the intermediate certificate and the private key file within a single file. It’s also possible that the server and the intermediate certificate can be provided in a separate file, .crt or .cer and the private key in a .key file.

PEM files can be opened through text editors like notepad and MS word, as it uses an ASCII encoding. Also, the PEM file contains the certificate between the statements —- BEGIN CERTIFICATE—- and —-END CERTIFICATE—-. The private key is between the —- BEGIN RSA PRIVATE KEY—– and —–END RSA PRIVATE KEY—– statements and the CSR is between the statements —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—–.

PKCS#7 Format

The PKCS#7 format is a Cryptographic Message Syntax Standard which uses a Base64 ASCII encoding file with .p7b or .p7c extension. Also, only this certificate can be stored and not its private keys. This certificate is contained within the statement —–BEGIN PKCS7—– and —–END PKCS7—–.

DER Format

DER Certificates are mainly used for Java-based web servers and they are in binary form with an extension of .der or .cer files.

PKCS#12 Format

The PKCS#12 certificates are mostly used in the Windows platform and they offer two different extensions of files, .pfx and .p12. It uses a binary form and helps to store the server certificate, the intermediate certificate and the private key within a single .pfx file with password protection.

SSL Certificate Lifecycle – How To Manage SSL Certificates

Granted, the usage of SSL/TLS Certificate is widespread, and it’s used throughout the organization, but there are many reasons to consider a Lifecycle Management Approach as it’s one of the critical tasks to maintain an accuracy of SSL/TLS Certificates which should not be taken lightly. Let’s understand in detail.

What is an SSL Certificate Lifecycle Management?

As said, SSL Certificates comes with limited validity and don’t allow updates like any software. But SSL management throughout the network ensures protection and prevents failures, some of the basic needs of the businesses. By employing a proper SSL/TLS Certificate Lifecycle Management, it ensures a proper approach and increases the effectiveness as well as efficiency. Likewise, the SSL certificate requires proper management, which is divided into certain stages as below:

Enrolment of Certificate

Enrolment of SSL Certificate is done as per the request the user makes to the trusted CA. It’s a cooperative process between the CA and a user. The enrolment request contains enrolment and the pubic key information. Once the user requests the certificate, the CA verifies all the information. Based on its policy rules, the CA creates and posts the certificate and sends a certificate to the user. During this distribution, the CA sets certain policies which affect the user of the certificate.

Validation of Certificate

Whenever an SSL Certificate is used, the status of that certificate is verified to know whether that certificate is valid. During this process, the CA checks and verifies the status of the certificate to be sure that it’s not in its Certificate Revocation List (CRL).

Revocation of Certificate

All the certificates issued by the CA comes with a validity period. In case the certificate needs to be revoked before its expiry date, the CA can be instructed to add the certificate into its CRL. If the person responsible for handling the SSL leaves the company, if the certificate is lost or if the private key or the certificate gets compromised, the certificate could be revoked.

Renewal of Certificates

Once the certificate reaches its expiration date, it must be renewed automatically or manually by users. Also, while renewing a certificate, you must choose whether to generate new private and public keys.

Abolishing Certificates

If the certificate is no longer needed, then that certificate and any backups related to that certificate must be abolished with its associated private key. In return, it helps in ensuring that the certificate is not used or compromised by anyone.

Inspecting Certificate

Tracking the creation, revocation, and expiration of certificates come under certificate inspection. Sometimes, it also tracks every successful usage of a certificate.

If the organization fails to maintain proper lifecycle management of the certificate, it can face negative consequences such as expiry of the certificate, loss of reputation and revenue.

Some other important steps that involve in the SSL/TLS Certificate lifecycle are:

• CSRs
• Validation Process
• Expiration
• Renewal

Certificate Signing Request Generation

What is A Certificate Signing Request?

A Certificate Signing Request (CSR) is one of the request blocks in an encoded text format which is provided to a Certificate Authority when a Client applies for an SSL/TLS Certificate. Usually, it’s generated on the same server where the SSL/TLS Certificate has to be installed, and it contains information which will also be included in the SSL Certificate such as the name of the Organization, Common Name (Domain Name), Locality and Country.,

Also, CSR plays a crucial role in the issuance of an SSL/TLS Certificate, as it’s used by a CA (Certificate Authority) to create your SSL Certificate. But as mentioned above, it does not have a private key. Additionally, SSL Certificate created with a particular CSR only works with its matching Private Key, which was generated along with it. So, if you lose your Private Key, the Certificate will no longer be considered secure, and it’s recommended that you create a new one by replacing or reissuing your SSL/TLS Certificate.

Information Contained in Your Generated CSR

What Does a CSR Look Like?

Generally, a CSR is created in the PEM format encoded in Base-64 that can be opened using a text editor such as Notepad. However, it’s a must to include the header and footer lines “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–” at the beginning and the end of the CSR.

Sample of a CSR

SSL Validation Process

Moreover, there are three different validation levels and all have a different process. Let’s see each one in detail.

DV SSL: Validation Process

Domain Validated (DV) SSL/TLS Certificate is one of the most basic SSL Certificates and the validation steps are also simple compared to Organization Validated (OV) and Extended Validated (EV) SSL Certificates. To get a Domain Validated SSL/TLS Certificate, you just need to confirm that you own the domain for which you are purchasing an SSL Certificate. Following are the options to complete Domain Validation.

Email Based Verification: It’s one of the easiest and preferred verification methods. The Certificate Authority (CA) will send an email to the WHOIS registered email address asking you to verify that the certificate is registered for the specified domain name. Once the email verification is done, the validation will be complete, and the certificate will be issued in minutes.

The authentication email might be sent to one of the five pre-approved email addresses that are generally associated with the website.

• Admin@name-of-site.com
• Administrator@name-of-site.com
• Webmaster@name-of-site.com
• Hostmaster@name-of-site.com
• Postmaster@name-of-site.com

File-Based Verification: If you choose this method, the Certificate Authority (CA) will provide you with an HTML file called Authentication File (auth file), which includes the Hashed content. You simply need to upload that file onto your server directory and verify it. Once it’s verified by the Certificate Authority, your SSL Certificate will be issued.

CNAME-Based Authentication: This method is used only for SSL/TLS Certificates purchased from Comodo. Comodo will provide you with two unique hashes, one using the MD5 algorithm and another using the SHA2 algorithm. Once you receive these values, you have to enter them as your CNAME DNS record. For that, the format is: .yourdomain.com CNAME .comodoca.com. Once you complete this step, Comodo will verify it.

OV SSL: Validation Process

As the name implies, the Certificate Authority (CA) will verify whether the organization for which the OV SSL/TLS Certificate is purchased is a legal entity.

Every business must fulfill the following requirements:

Organization Authentication

The Certificate Authority (CA) checks whether the organization is registered and active within the state or country. Additionally, all the information you provided about your organization must match the organization’s registration details. It’s also important to note that all the registration information like the organization operated under any trade names, assumed names or DBAs must be up to date and accurate, as well.

Locality Presence

To fulfill this requirement, the CA (Certificate Authority) will verify that the Organization has a legit physical presence within the country or in the state it’s registered. To verify all this information, the Certificate Authority will look through the Online Government Database or any other relevant database and check all registration details such as city/state/country.

Telephone Verification

The organization must have an active telephone listing that can be verified by looking at an acceptable online telephone directory.

Domain Verification

Here, the domain name will be verified, and the organization has to prove that it owns the website. To verify, the CA will look through the WHOIS registry and the internet database that stores the information of the registrar. Apart from this, for this process to work, the record must be available publicly and it should also display the verified business name with the corporate identifier with a physical address, as well.

Final Verification Call

It’s one of the simplest requirements for an Organization Validated SSL Certificate. To complete this requirement, the Certificate Authority will call the phone number associated with the organization and ask certain easy-to-answer questions such as “Did you order this?” or “What is the name of your company?,” to verify the order details. Moreover, if the given phone number does not connect directly to your desk, there are other ways such as IVR Extension or Transfer or Alternate Number, that are accepted during the Final Verification Call process.

For legal entities, it shouldn’t be a problem if they fail to meet the requirements as per the expectations as there are other methods, as well.

Official Registration Documents

You can provide official business registration documents issued by the government. For example,

• Articles of incorporation
• Chartered licenses
• DBA statements

or any other government document which shows your company is a legal entity.

Dun & Bradstreet

It’s an organization well-known for the financial reporting of businesses. CAs hold their credit reports in high value and they are used to meet multiple requirements like

• Operational Existence
• Physical Address
• Telephone Verification

Their reports are also used to verify specific details associated with the business entity.

Legal Opinion Letter

Legal Opinion Letters, also known as Professional Opinion Letters (POLs), are quite hard to obtain as an attorney or an accountant has to vouch for the legitimacy of your organization by signing a letter. These letters are very useful when it comes to the validation process as they satisfy multiple requirements.

• Organization Authentication
• Operational Existence
• Physical Address
• Telephone Verification
• Domain Authentication

Third Party Directory

CA’s can use an existing or a new telephone listing of an accepted third-party directory, such as

• Yellow Pages
• Scoot
• 192.com

The business name and physical address in the listing and that on the enrollment form and your company’s certificate must be the same.

Note: The Certificate Authority can choose any document from the given list to fulfill the validation requirement and it can also differ from one to another.

EV SSL: Validation Process

An Extended Validated (EV) SSL/TLS Certificate offers the highest level of authentication and security compared to the Domain Validated and Organization Validated SSL/TLS Certificates. It goes one step further to offer more trust by verifying the existence of business to let users know that the website is genuine and trustworthy.

It provides the highest possible security, its validation process is also rigorous compared to the other two, i.e., Domain Validated SSL Certificates and Organization Validated SSL Certificates. Moreover, no matter which Certificate Authority you choose to purchase from, the validation requirement of an EV SSL/TLS Certificate is almost the same because of the CA/B (Certificate Authority and Browser) forum which is a regulatory body run by the CAs (Certificate Authorities).

Validation Requirement for EV SSL Certificate

• Enrollment Form:

The enrollment form, also known as Acknowledgement of Agreement, is the very first and easiest requirements a business or an organization has to meet to get an Extended Validated SSL/TLS Certificate. You simply need to fill the form that requires basic information such as:

• The Organization’s name
• The Organizational contact’s official title
• The full name of the Organizational contact
• The signature of the Organizational contact
• Date & place of signing

A contact in HR to verify that the Person (Organizational Contact) who has applied for the certificate is employed within the company.

The main purpose of this form is to verify that the Organizational Contact has the right to act on behalf of the mentioned Organization, as no one would like to give out an EV SSL Certificate to an imposter website.

• Organization Authentication

The Certificate Authority verifies that your company is a legal entity which is active and registered in the local municipality.

• Operational Existence

Here, the Certificate Authority will confirm that your company has been operating for three or more years. If its existence is more than three years, it is a breeze as there’s a chance that you won’t have to provide any additional documents and it will be covered with Organizational Authentication via online checking.

• Physical Address

The Certificate Authority will ask you to prove that your Organization is well established, and it has a physical presence within the country or state where it’s registered. To complete this requirement, the Certificate Authority will verify the complete address of your company through the Online Government Database that includes the street address, city, state, and country.

• Telephone Verification

The Certificate Authority will ask for an active telephone number. First, it will look through the Online Government Database and if it matches with the other information, this step will be completed without any difficulty.

• Domain Authentication

It’s a straightforward approach where the CA will confirm that your company legally owns the domain for which the EV SSL/TLS Certificate was ordered. The very first way is to check through the details available in WHO.IS. (a website which displays the domain registrar information). If the record of your company is publicly available and it shows the exact information such as the verified business name and physical address as mentioned in the Enrollment Form, you won’t have any trouble.

• Final Verification Call

This requirement is easy as it takes place after the completion of the prior requirements. The Certificate Authority calls you on the verified business telephone number and asks simple questions such as “Did you order this?” or “What is the name of your company?” to verify the order details.

The CA will try its best to verify each and every requirement. But if the information is not found, or if it’s not updated in the Online Government Database, there are few other ways to fulfill those requirements.

• Email or Fax the Documents

If due to any reason, the Enrollment Form requirement is not completed, you can send the paper version of the form through mail to the CA’s physical address, or it can even be faxed.

• Official Registration Documents

If you fail to meet the Organization Authentication, Operational Existence or the Physical Address requirements, you can provide documents issued by your local government as proof. For example

1. Articles of Incorporation
2. DBA Statements
3. A Chartered License

• Dun & Bradstreet

Credit reports from well-known and reliable financial reporting companies such as Dun & Bradstreet are accepted by CAs to fulfill the following requirements.

1. Operational Existence
2. Physical Address
3. Employment Verification
4. Telephone Verification

• Legal Opinion Letter

A Legal Opinion Letter or a Professional Opinion Letter (POL), is a letter given by an accountant or attorney that has vouched for the authenticity of an organization. It helps fulfill the following requirements.

1. Organization Authentication
2. Operational Existence
3. Physical Address
4. Telephone Verification
5. Domain Authentication

• Recognized Third-Party Directories

It’s an alternative for the telephone verification requirement. Here, Certificate Authorities will use the telephone listings in a recognized third-party directory like

1. Yellow Pages
2. Scoot
3. 192.com

• Bank Confirmation Letter

In case the establishment of your organization is less than three years old, the Certificate Authority would accept a letter from the bank telling your organization has an active checking account (Demand Deposit) with them.

Note: Certificate Authority can choose any document from the given list to fulfill the validation requirement.

SSL Certificate Expiration

Why Do SSL Certificates Expire?

Several times, people raise questions regarding the shorter validity of an SSL certificate and relate them to some scam of making money. It’s even valid to ask such questions as the annual bills are something hard to ignore. But again, the reason for the expiration of SSL/TLS certificates is to keep websites updated with all the latest security standards. This way, you will always have the latest TLS ciphers and versions.

Moreover, technology advancement happens very often, and SSL certificate is not an exception. By having an expiry date for SSL certificates, users are enforced to stay updated with all the latest developments, with updates happening periodically.

If the certificate does not have a validity period, it will become hard to keep it updated with all the latest encryption technologies, which makes it open to cyber-attacks due to loopholes in outdated encryption standards.

For example, there are two latest updates, SHA-2 and the latest TLS1.3. Everyone has the privilege to enjoy the benefits of these two updates, and if the certificate does not have an expiry date or has a longer duration like a decade, it will become next to impossible to keep the customers updated till the certificate expires and they will be open to cyber-attacks.

What happens when your SSL certificate expires and how to Avoid it?

Many times, people forget to do things on time even if it’s important. But there are some tasks that should not be delayed or else it can cause a negative impact. Renewing a website’s SSL/TLS Certificate is one of those. Primarily, if your website deals with financial transactions such as banking or online shopping, it becomes more vital to avoid this situation.

Among many services, the security service provided via SSL/TLS Certificate also comes with a specific expiry date, which shouldn’t be missed. Every SSL/TLS Certificate has a validity period of 1-2 years. It could be one year or two years. Once that validity period is over, the certificate needs to be renewed and if you fail to do so, it will expire.

Moreover, if a website owner allows the SSL/TLS Certificate to expire, it will result in an invalid certificate and the website will no longer be considered safe to do transactions. So, you can imagine how important it is to avoid the expiry of an SSL/TLS Certificate and how it can become a problem if someone fails to do so.

But again, sometimes, especially in big enterprise-level businesses, this type of scenario is possible. Mainly, due to oversight or maybe because the contact person is moved, being promoted or maybe some other reason. Because, when it comes to enterprise businesses, they do not deal with one or two, but several SSL/TLS Certificates, which is not that easy to maintain.

Apart from this, Website users also face problems while accessing websites with expired certificates such as warning or error messages that will eventually result in the loss of trust and also decline in sales & revenue. This will ultimately have an adverse effect on the brand and reputation of the business.

So, how to prevent an SSL from getting expired? Below are some of the actionable tips that may be helpful to you:

• Find a good certificate management platform. Visibility is one of the biggest challenges faced by enterprise businesses. It’s a fact that website owners may not remember the expiration dates of their SSL certificates. To cope with these types of situations, Certificate Authorities like Comodo and DigiCert offer a platform that helps enterprises to manage SSL Certificates and the entire infrastructure.
• Take your time and decide which CA(s) you would like to work with and then set up CAA records for restricting who can issue SSL for your domains. This will help you eliminate the chances of new rogue certificates from getting issued.
• Track email addresses used for purchasing SSL/TLS Certificates. Set reminders.

One thing to note is that the expiry of SSL certificates plays an essential role in offering trust to customers. Many times, organizations forget to renew their SSL certificates on time, which can create uncertainty in the minds of website visitors. It’s recommended renewing your SSL before it gets expired rather than losing your valuable customers.

How to Renew SSL Certificate?

SSL/TLS Certificate renewal is the process in which a user buys a new certificate for the same public key which was used in the expiring SSL certificate. Mostly, the SSL/TLS Certificate expires after one or two years from the purchase date. To maintain the trust of site visitors, renewing a certificate within the last quarter of the certificate’s validity period is essential. Likewise, by renewing your SSL/TLS Certificate, you also reap the benefit of keeping the latest and updated SSL/TLS versions and ciphers.

Moreover, the renewal process of SSL/TLS Certificate is simple and if you’re an existing customer of any certificate provider, then there’s no need to worry about the expiration date. As, it’s the responsibility of the system to remind you about the expiration date, to give a smooth experience while avoiding the last-minute hassles. SSL Certificates can be renewed before 90 days of expiration, reminders also start coming during that period.

Also, the reasons for renewing your SSL Certificate before its expiration plays an important role. For instance, no one would like to lapse the protection of their website. And, if you go for renewing your SSL Certificate once it expires, you’re not renewing it but purchasing it all over again. CA’s will make you go through the entire process you went through when you initially purchased your SSL certificate. Likewise, until the process is complete, your website will remain unprotected.

Lastly, you should remember that once you renew the certificate, your job will not be over until you install it. Newly issued certificates still have to be validated by the CA or else it will keep you unprotected when the installed certificate expires.

What is SSL Revocation?

Besides, whenever an SSL connection is established by a client, as a part of the SSL handshake, the server provides the chain of certificates. In addition to that chain verification, the correct behaviour of the client also includes confirmation of all the certificates belonging to that chain are not revoked before that SSL connection continues. And, all the certificates come with data pre-included regarding where and how to check for the revocation information.

The Need of SSL/TLS Certificate Revocation & How to Address it?

Besides checking the validity period of the certificate, it’s also essential to check whether the certificate has been revoked or not. There are numerous reasons which make the revocation of certificate necessary. For example,

• If a person responsible for handling certificates leaves the company or changes his role
• If an improper certificate is issued by the CA
• If the domain is no longer owned by its owner for whom it was issued
• If the original certificate is replaced with a different one from another issuer
• Owner of the Certificate stops operations or if the site is no longer active

Moreover, different methods are available for querying and publishing these lists. But many are not used widely, due to the slow and prone to fail methods or because it’s not easy to understand and implement.

CRL (Certificate Revocation Lists)

CRL is one of the basic forms of revocation checking methods., Here, a text file is created by the CA (Certificate Authority), which contains a list of (serial number, revocation timestamp, revocation reason) data record/certificates before their expiration, which is signed by the CA. Also, an authenticating device like a web server or ADC (Application Delivery Controller) checks this text file containing a list for every session where it must be authenticated. Also, it’s acceptable for the user to proceed further if the presented certificate is valid and does not appear on the list.

Likewise, CRLs do share some critics as well. They are simple to use but challenging to implement, operationally. Moreover, they are not even updated regularly, making it difficult to manually import in authenticating devices like ADC. Lastly, they can grow in large numbers, making it difficult to consider because of the multiple CRL sources.

CRLDPs (CRL Distribution Points)

CRL Distribution Points are configured to overcome the CRL problem of manually importing a CRL file so the webserver or ADC can automatically read it from an online source, usually LDAP or HTTP(S). Though, one of the larger problems of CRL, which is size, still exists.

OCSP (Online Certificate Status Protocol)

OCSP is an improvement and solution to the problem of size, faced in CRL. Here, the process is quite similar to CRL checking, but the difference is that the client only has to fetch the status of the specific certificate compared to the entire list.

• As every client has to check the revocation status of every certificate, the number of queries hitting the CA server (OCSP responders) will get high.
• As the OCSP responder has the log of IP addresses and the websites visited by every client, it can create a privacy leak.
• The entire process already gets slow because the client has to go through another series of round trips for connecting and querying the status of the certificate. If there’s a poor mobile network or any other high latency connection, then the delay will be furthered more.

Additionally, the main issue of the revocation methods is that the client handles all the burden. Every user and web browsing request must have their query for the revocation service. OCSP stapling is another approach to this.

OCSP Stapling

In OCSP Stapling, the burden of proof is moved from client to the ADC or web server. For example, ADC periodically fetches the OSCP status for the certificate it manages. And the OCSP responder result is digitally signed, so if there’s any tampering, it may get spotted.

Some of the things improved by OCSP Stapling are:

• It removes the amount of time spent on page load by eliminating the requests of the OCSP service
• Fixes the privacy issue, as now the OCSP responder gets requests only from one place, ADC or the webserver
• Also cut downs the overhead on the OCSP responder, as it now only serves infrequent requests of the webserver or ADC

Still, OCSP Stapling also has some issues like chances of active man-in-the-middle (MITM) attacks like in OCSP. Also, OCSP stapling is not mandatory but an option, as it’s possible to block the OCSP response and trick the web browser into thinking that the malicious certificate is genuine.

Certificate Revocation in Browsers

Popular web browsers like Google Chrome and Mozilla Firefox have their approach towards certificate revocations.

For example, Google Chrome does not use CRL lists or OCSP servers, but they have their CRLset, which is the list of revoked certificates compiled and embedded inside the Chrome browser. They are auto updated by periodically crawling the CRLs of all the major CAs around the globe. And Mozilla Firefox has an analogue solution known as OneCRL and also uses the regular OCSP approach.

Firefox usually shows SEC_ERROR_REVOKED_CERTIFICATE error like below, when the revoked status is encountered from OCSP responder:

Lastly, revocations and expiration of the certificates are entirely different., Expired certificates are considered invalid and not every active certificate is not valid either. Revocation and other validation techniques are an essential part of all the proper PKI procedures, as in real-world environment, there’s a chance of making mistakes in vetting and in the certificate management process.

Managing SSL/TLS at Scale

Managing SSL certificates is not that time consuming as everyone thinks. With the right guidance and tools like a centralized platform which can help in automating the certificate management operations and offer timely insights on an environment of organization’s SSL, managing the SSL Certificate lifecycle becomes quite easy.

Features of SSL Management Tools

• A single management interface to improve speeds while simplifying the issuance, deployment, discovery, and renewal of all certificates, no matter where it’s located in your organization.
• Ability to communicate with all the leading operating systems, devices, protocols, and chipsets while allowing you to secure your infrastructure, no matter which technology is used.
• Automated management feature which helps in performing discovery and installation, renewal and replacement.
• Reduced staff time and operational costs associated with individual certificate management

Common SSL/TLS Mistakes

Using Self-Signed SSL Certificates

In the same way, web-browsers will not accept it and will also warn your website visitors by displaying a warning message saying, “The site’s security certificate is not trusted!”, eventually preventing users from visiting your website.

Choosing an Untrustworthy Certificate Authority

Mistake in CSR (Certificate Signing Request)

Generating a Certificate Signing Request (CSR) is one of the crucial steps. While installing an SSL certificate, it is mandatory to complete this step without a single mistake. The CSR generation process differs depending on the server you are using, so it’s better to thoroughly go through everything to generate the CSR. You will not be able to install your SSL/TLS certificate if you make mistakes or enter incorrect information. Apart from this, it’s also recommended that you verify the CSR using tools such as CSR Decoder once you finish it, as it will be helpful to know whether you should move to another step or not.

Not Fully Prepared for the Validation Process

Validation is one of the mandatory steps. Before the SSL/TLS Certificate gets issued to you, the Certificate Authority verifies you and your organization. If it’s a Domain Validated SSL/TLS Certificate, it will only verify the WHOIS registry information and you should respond through the email registered with it. For the Organization Validated (OV) and Extended Validated (EV) SSL/TLS Certificates, the process is a bit complex, as you have to provide certain proofs for verification.

So, if anything goes wrong, for instance, if your organization does not have a telephone number which is publicly listed, then there could be a delay in the issuance of your SSL certificate and in the worst case, it may not get issued at all.

Problems with Your Private Key

Not Following the Installation Guide Properly

If you’re not an IT professional, it’s better to go through guides that can help you install an SSL/TLS Certificate. Whether you purchase your certificate from a reseller or a Certificate Authority, they do offer knowledge base which consists of several guides and tutorials on SSL/TLS certificate installation for different web servers.

Once You Encounter a Mistake, You Don’t Contact Customer Support Service

You might already be aware of a certain mistake you made but you might try to solve it on your own. It’s good to take matters into your hands, but if you’re one of those inexperienced persons for whom SSL is quite new, rather than taking risk, it would be better to contact Customer Support Service. Certificate Authorities and SSL Certificate Providers offer chat, email and telephone support. They even offer installation services at a lower price. So, why not get done with it within a short period rather than spending endless hours on errors about which you’re not aware of?

You Didn’t Check Once the Installation Is Over

Once the certificate is installed you might want to test it to make sure that your time has not been wasted. It’s also recommended that you check whether the SSL certificate is installed properly, because at times you may assume that it has been installed properly and your site is secured and trustworthy for your website visitors, but in reality, it may not be so. It’s better you do a basic test by visiting your website through an HTTPS protocol, for example, by typing “https://domain-name.com” in the address bar to verify whether the padlock appears just to confirm it has been properly done. You can also use certain tools like SSL Checker to get more specific results.

You Forgot to Renew Your Certificate

The SSL/TLS Certificate you purchase and install comes with a specific validity period of 1 or 2 years. Once it’s over, they expire. The main reason to keep an expiry date is to keep the customers updated with the latest evolving security standards by continually authenticating their identity.

In other words, it’s mandatory that you keep renewing the certificate to enjoy the benefits of a secured website. But sometimes, it happens and even big companies like LinkedIn, Yahoo and Google forgot to renew their SSL Certificates, which made the websites temporarily unsecured. Popular web-browsers such as Mozilla Firefox may even block such unsecured websites. To avoid such situations, it’s better to remember SSL renewal dates and renew it before it gets expired. SSL providers also send email reminders, so don’t take it lightly.

Common SSL Certificate Errors

SSL is one of the protocols used to encrypt information sent to a web server from a web browser. So, when something prevents your computer from initiating this secure session with the website you want to access, an error is displayed, which is known as an SSL Error.

There are more than one SSL Errors, let’s see them one by one:

This SSL certificate is untrusted

If you see the warning message “This site’s security certificate is not trusted,” it generally means that the browser has failed to link the certificate of that website with the trusted root certificate or it’s not signed by a trusted root certificate.

If a trusted certificate authority (CA) has signed the certificate, then the chain/intermediate certificate may not have been installed on the webserver in between the primary and the root certificates.

If you face any problem while installing the chain/intermediate certificate, the best bet is to contact your Certificate Authority.

The security certificate was not issued by a trusted certificate authority

If you see this error, it means the SSL/TLS Certificate is not approved or signed by a trusted company, according to the web browser. This could be due to the following reasons:

• Self-Signed Certificate Used by a website: Though a self-signed certificate is created free of cost, it’s not as trusted as an SSL Certificate issued by a trusted third-party.
• Free SSL/TLS Certificate is installed on the website: Free SSL/TLS Certificates are offered by certain Certificate Authorities that are trusted by all major web browsers, for example, Google Chrome & Mozilla Firefox, but for a free SSL/TLS Certificate, the Root Certificate has to be imported manually to overcome this error.
• Intermediate/Chain Certificate is missing, though the trusted SSL is installed on the website: Most probably, all the trusted certificates will ask you to install minimum one chain/intermediate certificate on the server to link your certificate to a trusted source.

The Site’s Security Certificate has expired

All SSL/TLS Certificates come with a validity period of 1-2 years. If the certificate is not renewed before it expires, it will expire and it will cease working, which will lead to this error. The simple solution is to renew it.

Some times browser displays the SEC_ERROR_EXPIRED_CERTIFICATE Error.

The connection between the browser and the website might not be secure

You might be trying to access a website on an unsecured public Wi-Fi connection. This may lead to the display of this error on your web browser.

This page contains both secure and nonsecure items

Generally, this error occurs when certain elements on a secured page (page loaded with https:// in the address bar) are not loaded from a secure source. Maybe because, images, frames, javascript, and iframes are loaded from HTTP and not HTTPS. This error also called Mixed content warning. To be more specific about the same, you can use a tool like WhyNoPadLock, which will help you to locate the problem.

Certain steps you can take to solve this issue are:

1. Change all URLs to https
2. Change all links to // or make them relative
3. Change the settings of your web browser

Invalid Server Certificate Error

It’s one of the errors which is displayed when the web browser fails to find a valid server certificate to start a secured communication, as a server certificate issued by a trusted Certificate Authority is mandatory to start an encrypted session.

To solve this error, the following operations may be helpful:

• Clear Web Browsing History and Cookies.
• Check whether the system time zone matches the current time zone. Reset, if it doesn’t.
• Check whether the SSL/TLS Certificate is installed properly using the SSL Checker tool. If it’s not installed properly, install it again.
• Check Firewall and Antivirus definition. If the website is blocked, unblock it.

‘SSL Certificate Name Mismatch’ error

More to add, different web browsers show the same error but with different messages.

• Google Chrome: “Your connection is not private.” Attackers might be trying to steal your information from “wrong.host.badssl.com” (for example, passwords, messages, or credit cards). NET::ERR_CERT_COMMON_NAME_INVALID
• Mozilla Firefox: “Your connection is not secure.” The owner of “wrong.host.badssl.com” has configured its website improperly. To protect your information from being stolen, Firefox has not connected to this website.
• Microsoft Edge: “This site is not secure.” This means someone’s trying to fool you or steal any info you send to the server. You should close this site immediately.
• Safari: “This Connection Is Not Private.” This website may be impersonating “wrong.host.badssl.com” to steal your personal or financial information. You should close this page.
• Furthermore, below are some of the reasons due to which this error occurs:
• When someone tries to access the website via an IP address, and the issued certificate is for the public-facing fully qualified domain name and not that IP address.
• The certificate is issued for test.com, but someone tries to reach the website through www.test.com. Technically speaking, WWW is a sub-domain. Though most of the time, certificates secure both WWW and non-WWW variations, there’s a slim chance to experience this error.
• Generally, as it happens in shared hosting environments, multiple websites being hosted on the same IP address lead to this issue as the SSL handshake occurs before the web browser requests the hostname via an HTTP header. Because of this, the server fails to give enough information to the SSL/TLS Certificate resulting in generating an error. However, if you have SNI, the problem can be resolved and even a Multi-Domain SSL Certificate can also prevent this issue.

Additionally, Name Mismatch error can be checked using an SSL Certificate Checker tool, and to resolve the same, you should know what the exact reason is. This will help solve the problem by adjusting the website’s configuration.

Apart from this, there are several different types of errors such as certificate expired, wrong host, revoked, pinning test, etc. To know more about these errors, you can check out free websites like BadSSL.

How to View SSL/TLS Certificates

How to View SSL/TLS Certificates in Different Web Browsers

If you have come this far, you might now be well aware of how important it is for a website to have an SSL/TLS Certificate. But as a normal internet surfer, how to know if the website has an SSL/TLS Certificate installed? There must be a certain way, right? Here, we will debunk the same. Let’s see how to check for an SSL Certificate on different web browsers.

How to view SSL/TLS Certificate Details in Google Chrome (Ver. 60+)

If you’re not using the latest updated version of Google Chrome, then please do it. No matter which version you’re using, if it’s above or equal to version 61, follow the below mentioned steps:

1. Go to an SSL enabled website.

How to view SSL/TLS Certificate Details in Mozilla Firefox

Viewing SSL Certificate details in Mozilla Firefox is quite easy. It just takes a few clicks and you’re done. Follow the steps below to check SSL Certificate details.

How to view SSL/TLS Certificate Details in Internet Explorer

Viewing certificate details in Internet Explorer is as simple as any other web browser. Just visit an SSL Enabled website and follow the steps below.

How to view SSL/TLS Certificate Details in Microsoft Edge

It’s a simple one-way step. Visit an SSL enabled website and click on the padlock in the address bar, and the details will be displayed as below:

How to view SSL/TLS Certificate Details in Safari

Viewing SSL/TLS Certificates in Safari is not that hard. Go through the below simple steps, and you will be able to figure it out in no time.

1. Open Safari and go to an SSL Enabled Website and click on the padlock, which is in the middle of the address bar.

How to view SSL/TLS Certificate Details in Chrome using Android Device

Viewing SSL/TLS Certificate information in Chrome using an Android device is quite similar to what we do on a desktop browser.

1. Go to an SSL enabled website and tap on the padlock in the address bar.
2. Once you tap on it, a window will pop up like this. On that, tap on “Details.”

How to view SSL/TLS Certificate Details in cPanel

It is quite easy to view SSL Certificate details in cPanel. It just takes a few clicks and you’re done. Follow the below steps:

1. Login to cPanel

OpenSSL – An Open Source SSL/TLS Tool

It contains an opensource SSL and TLS protocol implementation, having its core library written in the C programming language. Also, it’s licensed under an Apache-style license, making it completely free to get and is used for both commercial as well as non-commercial purposes, subjected with some of the conditions as per license.

Also, it does not distribute its code in binary form, but you can download it from third-party trusted websites like wiki.openssl.org. Here, you’ll be provided with an option of third-party binary distributions of OpenSSL to select and download based on your platform.

Below are some of the general-purpose commands, which you may find helpful while installing SSL.

openssl genrsa -out yourdomain.key 2048

Command for Checking Private Key

openssl rsa -in privateKey.key -check

Command for Generating CSR

If you already have a Private Key:

openssl req -new -key yourdomain.key -out yourdomain.csr

Once this above command executed, the following additional details will be asked as below:

Country Name: 2-digit country code of where your organization is legally existing.

State/Province: Full name of the state where your organization is located.

City: Full name of the city where your organization is located.

Organization Name: Organization’s legal name.

Organization Unit: Department name (Not Mandatory. Skip by pressing Enter.)

Common Name: Fully Qualified Name. For example, www.domain-name.com.

Email: The email address for processing certification. (Not Mandatory, can be skipped.)

If the Private Key is not generated:

Below command will generate both CSR as well as Private Key:

openssl req -new \

Country Name: 2-digit country code of where your organization is legally existing.

State/Province: Full name of the state where your organization is located.

City: Full name of the city where your organization is located.

Organization Name: Organization’s legal name.

Organization Unit: Department name (Not Mandatory. Skip by pressing Enter.)

Common Name: Fully Qualified Name. For example, www.domain-name.com.

OpenSSL Command for Checking CSR

openssl req -text -noout -verify -in CSR.csr

OpenSSL Command to Convert Key Files and Certificate

OpenSSL Commands to convert PEM:

Converting from PEM to DER

openssl x509 -outform der -in certificate.pem -out certificate.der

Converting from PEM to P7B

openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cert

Converting from PEM to PFX

openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt

OpenSSL commands for converting DER

Converting Certificate File from DER to PEM

openssl x509 -inform DER -in yourdomain.der -outform PEM -out yourdomain.crt

Converting Private Key File from DER to PEM

openssl rsa -inform DER -in yourdomain_key.der -outform PEM -out yourdomain.key

OpenSSL commands convert P7B File

Converting from P7B to PEM

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

Converting from P7B to PFX

openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer

openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer

OpenSSL commands for converting PKCS#12 (.pfx) file

Converting Certificate File from PFX to PEM

openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes

Converting Private Key File from PFX to PEM

openssl pkcs12 -in yourdomain.pfx -nocerts -out yourdomain.key -nodes

OpenSSL Command for Checking a Certificate

openssl x509 -in certificate.crt -text -noout

OpenSSL Command for Checking a PKCS#12 file (.pfx file)

openssl pkcs12 -info -in keyStore.p12

You can download the softcopy of this book at here – Download SSL E-Book Here