The abbreviation SSL stands for Secure Sockets Layer. It is commonly used to refer to either the SSL protocol or an SSL certificate. In this article, we will focus on both terms and examine them in detail.
The SSL protocol is a widely used cryptographic protocol that is able to secure communication between two or more devices on the Internet. Most often, SSL is used to protect the data transmitted between a server and a client. The protection takes the form of authentication for each participant and encryption for all messages sent back and forth. Thanks to these protections, third parties are unable to eavesdrop on the communication or alter it in any meaningful way.
To gain the security benefits of the SSL protocol, the server must have a valid SSL certificate installed. The SSL certificate plays an instrumental role in the client-server negotiations for a secure connection. As such, servers that lack an SSL certificate would not be able to use the SSL protocol. We will provide an in-depth walkthrough of how SSL secures a client-server connection a bit later in the article.
SSL certificates are digital certificates that are based on the X.509 certificate standard. Each SSL certificate is stored as a regular file that lives on the server. Every client that connects to the server would download a copy of the SSL certificate as it is used in the negotiation of a secure communication channel. More specifically, the SSL certificate contains the public cryptographic key, the identity of the website that is hosted by the server, and some other details that are used to establish an encrypted connection.
The great thing about the Secure Sockets Layer protocol is that it operates directly on top of the Transmission Control Protocol (TCP), which, in turn, is part of the Transport Layer of the TCP/IP suite. This allows the SSL protocol to act as a protective shield for all layers above the Transport Layer. Moreover, these higher layers do not need to alter their operation in any way in order to benefit from the protection afforded by SSL.
While the most popular use of SSL is to secure websites, SSL can also be used to increase the protection in various other Internet hosting services. Below, we will list some of the more notable ones:
- As we have mentioned above, SSL is mainly used in web hosting to secure the traffic between a website and its visitors. Thanks to SSL, the protected site can start using HTTPS instead of HTTP, thus increasing the level of security it offers.
- In addition to web hosting, SSL can also be used in email hosting so you can send encrypted email messages.
- Lastly, SSL is also a popular choice in file hosting. When an FTP server is equipped with an SSL certificate, it will start accepting FTPS connections in addition to regular FTP ones.
There are three perks that are commonly associated with having a connection that is secured with SSL. Depending on the type of client-server interactions that take place, you will benefit from at least one of the following:
- Encryption. SSL uses symmetric cryptography which ensures that all transmitted data is encrypted and can only be decrypted by the receiving end. Third parties will not be able to make sense of the encrypted data.
- Authentication. SSL can be used to prove that the communicating parties are who they say they are. In most client-server interactions, only the server would undergo identity verification.
- Integrity. SSL enforces message integrity checks using a Message Authentication Code (MAC). Thanks to these integrity checks, any message that has been corrupted or altered while en route will be detected as such and the communicating parties will be alerted of the incident.
The Secure Sockets Layer protocol has been around for a while. Its 1.0 iteration was developed in the early 1990s by Netscape, but it was never publicly released due to serious security concerns. In 1995, SSL 2.0 was officially launched, but it too suffered from holes in its security.
As a result, the protocol was rewritten from scratch and a year later, in 1996, SSL 3.0 was released through RFC 6101. SSL 3.0 improved upon its predecessor by adding support for SHA-1-based ciphers as well as support for certificate authentication. About two decades later, in June 2015, SSL 3.0 was deprecated by RFC 7568.
So, why are we still talking about SSL if it was deprecated way back in 2015?
The reason is that a new cryptographic protocol called Transport Layer Security (TLS) has taken its place. TLS has its roots in SSL and both protocols serve the exact same function. Due to these facts, the name SSL has stuck around even after the deprecation of the SSL protocol.
Nowadays, when you go to buy an SSL certificate, you will be buying a TLS certificate instead. We will go over some of the differences between SSL and TLS a bit later in this article.
To learn even more about Secure Sockets Layer, how it works, how a secure connection is negotiated, and how to install an SSL certificate on your website, continue reading or jump to the section that interests you.
- What Is the Purpose of SSL?
- How Can I Tell if a Website Is Using SSL?
- How Does SSL Work?
- Why Is There an Expiry Date on My SSL Certificate?
- What Is the Difference Between SSL and TLS?
- How Can I View a Website’s SSL Certificate?
- What Types of SSL Certificates Are There?
- Who Issues SSL Certificates?
- Why Do People Trust SSL Certificates?
- What Are the Parts of an SSL Certificate?
- How Do I Install an SSL Certificate?
- What Added Security Can SSL Bring to My Website?
- Does My Website Require an SSL Certificate?
- Can I Edit My SSL Certificate After It Has Been Issued?
- Do I Need a Private IP Address to Use an SSL Certificate?
- Conclusion
What Is the Purpose of SSL?
Back when the Internet was first created, nobody expected it to become this popular. People at the time thought that it would remain a niche technology used by a handful of individuals, universities, companies, and governments. As a result, all of the initial communications protocols – HTTP, FTP, SMTP – were created with little to no regard when it came to network security.
These original protocols are still around today and if you try to use them for any sensitive task, your personal information would be at risk. All of these protocols send information using plaintext which is human-readable text that is not protected in any way. So, a third party can potentially insert themselves in the middle of your communication stream and gain access to the transmitted data. This type of intrusion is often referred to as a man-in-the-middle attack and it has the potential to compromise any entered text, including your passwords, bank information, and other sensitive data.
Fortunately, as the Internet gained popularity, the need for better protection became increasingly apparent. As a result, cryptographic protocols such as Secure Sockets Layer were created to secure the communication between a client and a server.
Nowadays, all reputable clients – from web browsers to email applications, to file transfer solutions – support the SSL cryptographic protocol. But in order to benefit from the added SSL security, the server they connect to must also support the Secure Sockets Layer and must have a valid SSL certificate installed.
SSL is most popular for securing our interactions on the World Wide Web. When a web server supports SSL and has an SSL certificate, it can serve webpages using the HTTPS protocol. HTTPS stands for “_HTTP Secure_”, so it offers all features that are found in HTTP but add an extra security layer.
When a web browser and a web server communicate using HTTPS, their entire communication is encrypted. This means that only the client and the server will know what is said. If an outside entity tries to read the communication that is encrypted with SSL, all they will see is a jumbled mess of characters.
In addition to encryption, SSL enables another important security measure – authentication. Thanks to authentication, the client can be sure that it is communicating with the genuine server and not an impostor that is trying to trick the client into disclosing sensitive information. These types of fake sites are often referred to as phishing websites.
To protect you from such attacks, the client you are using will check the domain name declared on the SSL certificate and compare it with the actual domain name it is visiting. If there is any discrepancy, the client-server connection will likely be terminated or at the very least you will be notified that there is something wrong.
Lastly, SSL can also ensure that the data that is exchanged has not been tampered with. This type of protection is called integrity protection. Each snippet of data is encrypted and is represented by a number called a checksum. The checksum is transmitted along with the snippet of data. That way, the client and the server can compare the data snippet with its checksum as they receive them in order to make sure that the data has not changed while en route.
When combined, these SSL security features can provide you with peace of mind that your information is protected. Even if a hacker tries to eavesdrop on your encrypted traffic, all they would learn is the IP address and the port of the server that you are connecting to and roughly how much data is sent back and forth. If the hacker makes an attempt to tamper with the data, the client and the server will know about it and will be able to take action to remedy the situation.
Here at AwardSpace, we are proud to say that all of our premium plans come with full SSL support. So, if you buy one of our paid shared hosting plans, a semi-dedicated server, or a Virtual Private Server instance, your website will benefit from the security features we have just outlined.
How Can I Tell if a Website Is Using SSL?
In order to benefit from the security features that SSL provides, the website you are visiting must be using an SSL certificate. There are a few ways to tell whether the site you are on is protected or not. We will go over the most notable visual cues below.
Before we talk about ways to recognize a website that uses SSL encryption, we will show you how to spot a site that doesn’t use SSL. Fortunately, modern web browsers make this task very easy since they place a Not Secure label in the address bar:
If you do not see a Not Secure label on the website you are visiting, chances are that it is protected. So, let us examine a few details that will confirm whether SSL encryption is present or not.
First, look at the beginning of the website URL. Does it begin with http:// or https://? If you see https://, then you are protected. And if you are curious to learn what the difference is between HTTP and HTTPS, you can read our dedicated article on the subject.
Another telltale sign of a secure connection is a locked padlock icon placed somewhere around the browser’s address bar. If you see this padlock, then your connection is encrypted and any transmitted data will remain private.
These signs of a secure connection are referred to as EV indicators. Some web browsers may even present additional EV indicators such as a green address bar on certain SSL certificate types or placing the name of the company that operates the website right next to the URL.
If you are the inquisitive type, you can get even more information about the SSL certificate that a certain website is using. To get this additional info, simply click on the padlock icon in your web browser’s address bar:
How Does SSL Work?
As we have previously noted, the SSL certificate is instrumental in establishing a secure connection between a client and a server through the SSL protocol. Below, we will take a closer look at what comprises the SSL certificate followed by the SSL protocol.
SSL certificates are based on a digital document standard called X.509. SSL uses an X.509 digital certificate to bind the identity of the website and/or company to a pair of cryptographic keys. When bound, the keys would uniquely represent the specific website/organization and cannot be mistaken for any other entity.
The keys themselves come in pairs – one public and one private. As their names imply, the public key is distributed freely through the SSL certificate itself and everyone can access it. The private key, on the other hand, does not leave the possession of the entity that owns the SSL certificate.
While the public and private keys function separately, they are also inextricably linked. Everyone who accesses the public key can use it to encrypt information, so it is protected. This protected information can then be decrypted using only the private key. You can think of the relationship between the public and the private key as a safe and its key/passcode – the SSL’s public key acts as the safe where you can securely store data and the SSL’s private key is the only thing that can unlock that data.
There is one other property that makes the relationship between the public and the private key special. If the SSL owner signs a digital document such as a webpage using their private key, everyone who has the public key can verify that the webpage has indeed been signed by the corresponding private key.
You could say that the public and private keys of an SSL certificate are entangled. In other words, one part of the key pair will always be able to verify the identity and validity of the other. If you are familiar with quantum physics, the public-private key relationship is similar to the quantum entanglement phenomenon that is found there.
So how is this relationship formed? Since the public and private keys are both just very large numbers, a complex mathematical formula is used to link the two numbers together. The thing that makes the formula special is that it is nearly impossible to guess or to reverse engineer it using brute force.
When it comes to the SSL protocol, it can be divided into two sub-protocols: the Handshake protocol and the Record protocol. The Handshake protocol handles the initial setup of a secure connection, while the Record protocol maintains the secure connection throughout the client-server session. We will examine both sub-protocols in detail, beginning with the Handshake protocol.
The Handshake protocol also referred to simply as an SSL handshake, is an asymmetric cryptography process that takes place before any meaningful data is exchanged between the client and the server. The SSL handshake has two primary tasks. The first is to authenticate the server and optionally the client so they trust each other. The second task is the generation of a special session key. This session key will be used to encrypt all transmitted data after the handshake has concluded.
Overall, the SSL handshake can be summarized as a 7-step process. We will outline it below:
- At the very start of the client-server interaction, the client initiates the SSL handshake by asking the server to identify itself.
- The server responds by sending a copy of its SSL certificate to the client. The SSL certificate includes not only information about the website, but also the public key.
- The client then proceeds to check the provided SSL certificate. It must be valid, unrevoked, issued by a known certificate authority that the client trusts and the common name listed on the certificate must match the domain name that the client is connecting to.
- If all checks pass successfully, the client generates what is called a session key. The session key is similar to the public/private keys in that it is a long number that is hard to guess.
- Once the session key is generated, the client encrypts it using the public key from the SSL certificate and then sends the encrypted session key to the server.
- The server proceeds to decrypt the session key using its private key. Once the decryption has succeeded, it sends the client an acknowledgment message that has been encrypted using the session key through symmetric cryptography.
- At this point, the SSL handshake has been performed. The client and the server will continue using the session key and symmetric cryptography to encrypt the messages they exchange with each other until the current session ends.
If you are looking for a deep dive into how exactly the SSL handshake works, jump to this section in our article.
While the above steps may seem lengthy, the fact is that the entire process is near-instant. What is more, everything happens behind the scenes without any direct involvement from the user. Should something go wrong during the SSL handshake, the connection will likely be terminated and the user will be notified.
You might have noticed that earlier we outlined two different cryptography approaches – symmetric and asymmetric. You may be curious why the SSL handshake employs both approaches and not just one.
The reason for this is that while asymmetric cryptography is more secure, it uses two cryptographic keys (a public key and a private key) and is also much more resource-intensive. In fact, if asymmetric cryptography was used throughout the whole session, you would consume a considerable amount of bandwidth and you may notice your computer becoming more sluggish.
Symmetric cryptography, while not as secure as asymmetric cryptography, is much more efficient when it comes to system and network resources. So, a balance is struck where the SSL handshake happens while using asymmetric cryptography. Once the handshake is finalized, both the server and the client are in possession of the session key which is then used to encrypt traffic using symmetric cryptography.
The approach of using the stronger cryptography only during the handshake is a good compromise since it adds an extra layer of protection while having a minimal negative impact on performance. As an added measure, the session key is discarded after every session by default, forcing the client and the server to perform a new SSL handshake and negotiate another session key.
Once the SSL handshake has concluded, the Handshake protocol has done its job and it is time for the Record protocol to take over. The Record protocol uses the session key established in the handshake to encrypt the data sent between the client and the server. What is more, the Record protocol must isolate each secure connection to the server, so the traffic from two separate clients never gets mixed.
Overall, a connection that uses SSL encryption offers many worthwhile benefits. Chief among them, of course, is the ability to send and receive encrypted messages. Even if a third party is eavesdropping on your communication, they would not be able to decipher the information that is transmitted.
Another great benefit that comes with using Secure Sockets Layer is the fact that the client has a high degree of confidence in the identity of the server. Thanks to the authentication step in the SSL handshake, it is established that the website is genuine and is not a phishing attempt.
Lastly, when a connection is secured with SSL, every message arrives along with a corresponding digital certificate signature. This allows the client and the server to verify the message integrity. In effect, this enables the communicating parties to detect whether an outside source has tried to manipulate or alter the message.
A good example of how SSL can be used to secure a client-server connection is HTTPS. HTTPS is initiated through an SSL handshake from the very moment the web browser attempts to connect to the webserver. This ensures that all data transmitted going forward will be protected.
The protection afforded by SSL encompasses all three security measures that we have discussed earlier:
- it allows the server to authenticate itself, proving it is not a phishing website.
- it allows encryption of all data that is transmitted both from the client and the server using the negotiated session key.
- it allows the client and the server to confirm that the messages they receive have not been tampered with.
In addition to the above security measures, SSL also upgrades the connection protocol from HTTP to HTTPS. This includes a change in the port that is used. HTTP defaults to Port 80 while HTTPS utilizes Port 443. If you are interested in learning the differences between HTTP and HTTPS, you can read our article on the subject.
What Is an SSL Handshake?
The SSL Handshake is a process by which a client and a server negotiate a secure connection. During a handshake, it is common to negotiate the use of a particular cipher suite as well as the keys that will be used to encrypt the transmitted data.
There are two general handshake types: a one-way SSL handshake and a mutual SSL handshake. The difference between the two is that in a one-way handshake only one of the communicating parties (usually the server) has an SSL certificate installed. In contrast, with a mutual SSL handshake, both parties will have a valid SSL certificate.
In this particular section, we will explore the one-way SSL handshake as it is the more popular handshake model, especially in client-server connections. To make the example more practical, we will describe how a web browser and a web server perform an SSL handshake in order to initiate the HTTPS protocol.
It all starts with the client making initial contact with the server using a ClientHello message. With this message, the web browser signals that it wishes to create a secure connection. In addition, the client sends the SSL and TLS versions it supports as well as a list of supported ciphers and hash functions.
When the server receives the ClientHello message, it will compare the supported SSL/TLS versions by the client against its own supported versions and it will select the best and most secure option available. Then, it will repeat the same process and select the most secure cipher and hashing function that is supported by both parties.
Once the server has selected an SSL/TLS version, a cipher, and a hashing function, it will acknowledge the client’s request with a ServerHello response.
After the ServerHello message has been sent, the server will also provide the client with a copy of its SSL certificate. The SSL certificate is important because it contains the server’s public cryptographic key, information about the website that the server is hosting, the identity of the root Certificate Authority (CA), and optionally any intermediate Certificate Authorities that may have been used to issue the SSL.
The client receives the SSL certificate and proceeds to verify the authenticity of the server. It does so by comparing the Certificate Authority on the SSL against the trusted Root CA located in the client’s key store.
In addition, the web browser will check the Common Name field on the SSL certificate and make sure that it matches the domain name it is currently visiting.
At this time, the client will generate what is known as a session key or a premaster key. This session key will be used in the remainder of the session to encrypt the traffic that is exchanged. If the client disconnects from the server for any reason and then tries to reconnect, a new SSL handshake will take place and a new session key will be negotiated.
There are two main ways of creating a session key:
- the web browser can generate a random number and encrypt it using the server’s public encryption key that is part of its SSL certificate.
- the two parties can use a Diffie–Hellman key exchange to create the session key.
The Diffie–Hellman key exchange has two special variants, the Ephemeral Diffie–Hellman (TLS_DHE) and the Ephemeral Elliptic-Curve Diffie–Hellman (TLS_ECDHE), that can provide forward secrecy.
Forward secrecy is a property of some cryptographic systems that protect past communication in case the server’s private key is compromised. In other words, If the server’s private cryptographic key is hacked, but the secure exchange uses forward secrecy, the attacker will be able to view all future communication, but they will not have access to the past exchanges that have taken place.
The client will choose the most secure cryptography method available and use it to craft the session key. The encrypted session key is then sent to the server along with a ClientKeyExchange message.
Once the server receives the encrypted session key, it will attempt to decrypt it. If the session key was encrypted using the SSL’s public key, then the server will use the corresponding private key to carry out the decryption. On the other hand, if the Diffie–Hellman key exchange was used for encryption, then the server will use it to retrieve the session key.
At this point, both the client and the server are in possession of the session key and all other parameters that will be used to secure the communication going forward. So, each party sends the ChangeCipherSpec record which instructs the other party to start using the newly negotiated encryption measures. The ChangeCipherSpec record is also accompanied by a Finished message.
At this point, the SSL handshake is complete. The web browser and the server will continue exchanging information that has been encrypted using the session key. And if any of the above steps had failed for whatever reason, the secure connection would have been terminated.
Lastly, we should note that operations that involve an SSL certificate’s public key are costly in terms of processing power. So, some servers have opted to support resumed sessions in order to avoid going through the entire handshake process with repeat clients.
If the server supports resumed sessions, it would send a session ID or a session ticket as part of its ServerHello message. The client would then combine this session ID with the server’s IP address and TCP port and store it for future use. Should the client ever wish to re-connect to the same server, it can supply the enhanced session ID to the server within its ClientHello message.
The benefits of resumed sessions extend beyond speeding up the SSL handshake process. They are also instrumental in enabling the single sign-on feature that some companies offer. Moreover, some protocols such as FTPS heavily rely on resumed sessions and would not exist without this functionality.
Why Is There an Expiry Date on My SSL Certificate?
You may have noticed that all SSL certificates come with an expiration date. But why is that?
It all has to do with security.
While it may be convenient to be able to buy an SSL for, let’s say, 10 years, install it on your server and never have to think about it again, such a set-and-forget mentality is horrible from a security standpoint. That’s because when an SSL is issued, it utilizes the most recent version of SSL/TLS that is available at the time. However, when a new version of SSL/TLS rolls around, your SSL certificate would still be using the old version that will likely be vulnerable to attacks.
So, if you were to buy a 10-year SSL certificate, by year five or six it will do little to deter criminals. What is more, web browsers will stop trusting the security afforded by your SSL and actively start warning visitors to stay away from your website.
Of course, you can always go to your SSL vendor and ask them to re-issue the SSL certificate using the newest version of SSL/TLS that is available, however not all website owners would do that. Therefore, the lifespan of all SSL certificates is kept short on purpose in order to ensure that all SSL certificates in the wild are using more or less the latest version of SSL/TLS.
How Can I Check a Website’s SSL Expiration Date?
You can easily check the expiration date of an SSL certificate in a few ways. If you have purchased the SSL certificate from us, then you can log into your Control Panel, go to the My Certificates section, and review the expiration date for the SSL certificate that you are interested in.
If you have purchased your SSL certificate from a different provider, or if you wish to know the SSL expiration date of an arbitrary website, then you need to use your web browser’s tools to inspect the SSL certificate. The steps you need to follow are generally the same, however, different browsers usually opt to use slightly different wording for their option names.
- In most cases, you would need to click on the little padlock icon near the browser’s address bar.
- That should open a popup window containing some basic SSL information, such as the issuing Certificate Authority and the Common Name that is part of the SSL. Some web browsers may even display the expiration date right on this page.
- If you do not see the expiration date, there is usually a button that will allow you to see additional information on the SSL certificate. Click that button.
- You will be taken to a new popup window with much more information on the SSL. There, you will find the SSL’s expiration date.
What Is the Difference Between SSL and TLS?
As you may recall from earlier, the last version of SSL, SSL 3.0, was deprecated way back in 2015. So, a good question is: “Why are we still talking about SSL if it was taken out of commission in 2015?” The reason is that a new protocol, called Transport Layer Security (TLS), has taken over. In the next few paragraphs, we will explore how TLS relates to SSL and how the two protocols differ.
TLS was developed by the Internet Engineering Task Force (IETF) in 1999. It was based on SSL 3.0 and its goal was to bring improvements while retaining all of the existing functionality. The main reason for the new name was the fact that SSL was developed by Netscape while the Internet Engineering Task Force was the developer behind TLS.
The differences between SSL 3.0 and TLS 1.0 were not dramatic, however, they were significant enough to break interoperability. In other words, a client that only supports SSL 3.0 and a server that only supports TLS 1.0 would not be able to talk to each other.
Since TLS 1.0 was not a drastic departure from SSL 3.0, people saw TLS as a continuation of SSL, rather than a competitor. So, in reality, TLS is simply the newest version of SSL.
The SSL label managed to stick around over the years, mainly because the two technologies were very similar and served the same purpose. As such, SSL vendors did not see the need to fully abandon the SSL label since it was well known among consumers. Nowadays, it is common to refer to the encryption provided by SSL and TLS as SSL/TLS encryption.
Since SSL and TLS both have the same roots, they are both based on the X.509 digital certificate standard. This allows them to potentially store information that goes beyond just the public key and information about the certificate owner.
Over the years, TLS has seen several iterations as well. TLS 1.0 was followed by versions 1.1, 1.2, and the most recent as of this article, 1.3. In March 2020 TLS 1.0 and 1.1 were officially deprecated, leaving TLS 1.2 and 1.3 as the only officially supported versions of TLS.
To learn even more about TLS and how it differs from SSL, you can read our article on the differences between SSL and TLS.
How Can I View a Website’s SSL Certificate?
Modern web browsers make it extremely easy to view a website’s SSL certificate. To view an SSL certificate, navigate to an SSL-protected webpage. Once there, click on the padlock icon near the browser’s URL bar.
A popup window will appear showing you some basic SSL certificate details. If you require additional details, explore the popup window for a button that says More Information or something similar.
What Is an SSL Checker and Why Is It Useful?
An SSL Checker is a specialized type of website that has the purpose of providing you with as much information as possible about the SSL/TLS certificate that is installed on a particular server.
The amount of information varies from one SSL checker to the next. If you are completely new to SSL checkers, the Qualys SSL Labs checker is a good starting place. On average, an SSL checker should provide you with most of the following:
- the domain name the SSL is issued for
- the entity the SSL is issued to
- the SSL public key
- the webserver type
- the web browsers that will trust the SSL
- the issuing Certificate Authority
- the Certificate Authority’s digital signature
- the SSL issue date
- the SSL expiration date
- the SSL serial number
- any associated subdomains
You can learn more about what an SSL checker is and how it can be used in our dedicated article on the subject.
What Types of SSL Certificates Are There?
SSL certificates can be classified either by the number of domains/subdomains a single SSL is issued for or by the level of authentication and validation that is carried out. We will explore both of these categories in the next few paragraphs.
By default, an SSL certificate is valid for a single hostname only, but that doesn’t always have to be the case. There are some SSL certificates that can cover multiple hostnames at the same time.
The SSL certificates that cover only one hostname are known as single-domain SSL certificates while those that cover multiple hostnames can either be multidomain or wildcard. Below, we will provide a bit more information on each type:
- Single-domain SSL certificates are the most common and affordable SSL certificate type. A single-domain SSL will cover only the domain name itself. For example, if you purchase a single-domain SSL for the domain
my-website.com, then onlymy-website.comandwww.my-website.comwill be protected by the SSL. - Wildcard SSL certificates offer the protection found in the single-domain SSL certificates but you can add any subdomain name that was created out of the original domain. So, if you purchase a wildcard SSL certificate for
my-website.com, it will protect not onlymy-website.comandwww.my-website.com, but also all subdomains that you create, such asblog.my-website.com,shop.my-website.com,my-project.my-website.com, etc. - Multi-domain SSL certificates are the least common SSL type. They allow you to secure more than one domain name at a time. So, a multi-domain SSL can cover
my-website.comandanother-website.comat the same time. These multi-domain SSL certificates are also referred to as Unified Communications Certificates and are most often used by companies to secure their presence across different top-level domains. For example, a common use for a multi-domain SSL certificate is to securecompany-site.com,company-site.us, andcompany-site.co.ukat the same time.
Here at AwardSpace, we are proud to offer not only single-domain SSL certificates but also wildcard SSL certificates as well. So, if you wish to secure your website using an SSL certificate that will be trusted by your visitors, you should purchase an SSL certificate from us.
When it comes to identity validation, there are three SSL certificate categories. The Domain Validation only ensures that the person applying for the SSL certificate has control over the domain name. The other two validation options, Organization Validation and Extended Validation perform more comprehensive background checks. Below, we will examine each validation type in greater detail:
- Domain Validation is offered by all SSL certificates that are sold and it is the most basic form of identity validation. As its name implies, domain validation only validates the domain name for which the SSL certificate is issued. It does so by requiring the applicant to place a special record in the domain’s DNS, thus proving that they have full control over the domain. Domain validation is usually performed in an automated fashion and can take just a handful of minutes to complete. As a result, it is also the most affordable type of identity validation that is available.
- Organization Validation (OV) comes with all perks found in Domain Validation but takes the verification process further by having the SSL issuer contact the applicant directly. The goal here is to establish proof that the applicant is a registered business or organization that is legally accountable. Individuals cannot apply for Organization Validation_ certificates.
- Extended Validation (EV) is the most comprehensive validation type currently available. It comes with all perks found in the Domain Validation and Organization Validation options, but also includes a full comprehensive background check into the organization or company applying for the SSL certificate. Due to these additional checks, the Extended Validation takes the longest time to complete and is the most expensive option of the three. Like Organization Validation, only companies and organizations can apply for this SSL validation type.
Who Issues SSL Certificates?
Every SSL certificate is issued by a Certificate Authority (CA). What’s interesting here is that the ability to create an SSL certificate is not exclusive to a limited number of Certificate Authorities. In fact, every person can install an application on their computer, such as OpenSSL, that will allow them to manually create and sign SSL certificates which effectively turns them into a Certificate Authority.
So, if everyone can create SSL certificates themselves, why would they pay a Certificate Authority to issue them? The answer is that the CA will have a good reputation and the SSL that they issue will be trusted across the web. In contrast, self-signed SSL certificates have an unknown origin and are not implicitly trusted.
In the following two sections, we will explore the two types of SSL certificates and whether you should use an SSL certificate that is signed by a known Certificate Authority or you should go ahead and create a self-signed SSL certificate.
How Does a Certificate Authority Issue an SSL Certificate?
A Certificate Authority (CA) is a third-party organization that is widely trusted and has the task of issuing SSL certificates. Every SSL certificate that the CA issues is signed using its private key. This allows others to verify that the SSL comes from a legitimate source. Most Certificate Authorities charge a fee when issuing SSL certificates.
Normally, you need to go through several steps in order to obtain an SSL certificate through a Certificate Authority. We will outline these steps below:
- You begin the process by creating a pair of cryptographic keys – one public and one private. Ideally, you will perform this task on the same machine that will eventually house the SSL certificate.
- Next, a Certificate Signing Request (CSR) is generated. The CSR contains the public key that you just created along with the domain name that you wish to secure. If you are applying for an SSL certificate with Organization Validation or Extended Validation, the CSR will also contain the details of your company or organization.
- The Certificate Signing Request is then sent to the Certificate Authority. The CA proceeds to validate all entered information and carries out all necessary background and validity checks. Once all verifications have been completed, the CA generates a new SSL certificate. It then signs the certificate using its private key.
- The SSL certificate is now ready to be downloaded onto the server. While some Certificate Authorities will only provide you with the SSL certificate itself, others may include one or more Intermediate Certificates that aim to establish trust across a greater number of clients.
- Lastly, your SSL certificate is ready to be installed onto the server.
Quite a lengthy process, right? Fortunately, we have worked hard to streamline the SSL buying experience as much as possible. If you decide to purchase an SSL certificate from us, you will not have to perform any of the steps above. Instead, all that you would need to do is to provide us with the necessary verification information like your domain name, company name, etc (depending on the SSL certificate that you have chosen) and we will take care of the rest!
You can preview what our SSL buying process is like by reviewing our article on how to get an SSL certificate.
What Is a Self-Signed SSL Certificate?
Buying an SSL certificate from a Certificate Authority is not the only way in which you can obtain an SSL. Your other alternative is to create the SSL certificate yourself, effectively becoming your own Certificate Authority.
These types of homemade SSL certificates are called self-signed SSL certificates. Self-signed SSL certificates get their name from the fact that the entity that requests the SSL certificate is the same as the entity that approves and signs it.
You can create a self-signed SSL certificate by following the exact same steps that we have outlined in our section on how a Certificate Authority creates an SSL certificate. There are just two major differences – there is no third-party Certificate Authority involved and you are using your own private key to sign the SSL certificate.
Self-signed SSL certificates are completely secure from a technical standpoint. They are able to offer the same level of SSL encryption and security as an SSL that has been signed by a known Certificate Authority.
The only area where self-signed SSL certificates are lacking is when it comes to public trust. Since everyone can create self-signed SSL certificates, including hackers and other individuals with malicious intent, these certificates are inherently not trusted.
The main reason why you cannot trust self-signed SSL certificates is the fact that no Certificate Authority has vouched for the authenticity and safety of the individual or organization behind the SSL certificate. When an SSL is issued by a known Certificate Authority, this establishes a chain of trust that clients can follow.
A chain of trust is created when clients like web browsers are able to recognize and trust a given Certificate Authority. When this CA issues SSL certificates, these certificates are also trusted by extension. We explore the chain of trust in greater detail a bit later in this article.
How Can I Create a Self-Signed SSL Certificate?
Creating a self-signed SSL certificate is easy thanks to tools such as OpenSSL. With a utility like OpenSSL, you can create a fully-formed SSL certificate by issuing a single command and simply providing your domain name and company/organization details.
OpenSSL is a command-line utility and as such, it has no graphical user interface. To create an SSL certificate using OpenSSL, you need to issue the following command:
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout private.key -out certificate.crt
If you wish to learn what the various parameters in the above command mean, or to learn more about OpenSSL in general, you can check our article on what OpenSSL is.
Why Do People Trust SSL Certificates?
Earlier in this article, we discussed how there are two types of SSL certificates when it comes to trustworthiness – self-signed SSL certificates and SSL certificates that are issued by a Certificate Authority. The self-signed certificates are commonly considered to be untrustworthy while SSLs issued by a CA are trusted. Why is that?
The answer is that the Certificate Authority is a known organization that has a good reputation and is trusted by the public. When such a CA signs your SSL certificate, they vouch for the authenticity of your SSL and your website as a whole. This transference of trustworthiness is known as a chain of trust.
At the base of the chain of trust, you will find a handful of SSL certificates that are called Root Certificates. There are very few Root Certificates in existence and every company that operates a Root Certificate, called a Root Certificate Authority, must adhere to strict guidelines and security policies. Moreover, Root CAs regularly undergo audits to ensure that security measures are in place to protect the Root Certificate from misuse.
The public keys of these Root Certificates are then bundled into all major operating systems and some web browsers. Companies like Microsoft, Apple, Google, and Mozilla maintain lists of trusted Root Certificates. These lists are often referred to as Trusted Root CA stores and they come preloaded with your operating system and some web browsers like Firefox.
The Trusted Root CA stores form the basis of the Public-Key Infrastructure (PKI) around SSL certificates. Technically speaking, each Root Certificate is a self-signed SSL certificate.
Since the Root Certificates are incredibly valuable, they are not used to sign consumer-grade SSL certificates. Instead, the Root CAs use their Root Certificates to sign the SSL certificates of SSL vendors who are often referred to as Intermediate Certificate Authorities.
The goal here is to insulate the Root CA from signing unknown SSLs. That’s why intermediates are used. If something goes wrong and an Intermediate CA signs a bad SSL, the certificate belonging to the Intermediate Authority can be revoked without causing irreparable damage to the Root CA. So, when you go and purchase an SSL certificate, you are interacting with an Intermediate Certificate Authority.
When a client, such as your web browser, encounters an SSL certificate that is part of an SSL chain, it will check each link in the SSL chain until it finds an SSL certificate that it trusts implicitly. If a trusted SSL is not found, the browser will display a security warning before loading the website.
As an example, let’s assume that you are the owner of the domain my-website.com and you wish to secure it with an SSL. You would need to purchase an SSL certificate from a trusted SSL vendor, such as AwardSpace. During the SSL issuing process, you will be asked for proof that you own the domain my-website.com. Once the requested proof is provided, which is usually just a custom record on the domain’s DNS, the SSL is issued and installed on your server.
Then, whenever a visitor comes to your website, their browser will check the SSL and trace its origin back to a trusted Root CA. The Root CA, by extension, will vouch that your website matches the common name that is stated on the SSL. As a result, the visitor’s web browser will have a high degree of confidence that your website is genuine and not a phishing attack.
What Are the Parts of an SSL Certificate?
Every SSL certificate consists of three main parts: a public key, a private key, and some additional information about the SSL. In this section, we will take a brief look at each of these parts.
The public key is stored within the SSL certificate itself and is publicly distributed. Every visitor who connects to your website using HTTPS will download a copy of your public key. The primary purpose of the public key is to allow clients to encrypt information that only the server can decrypt.
The private key is kept private and is not publicly distributed. The private key is used to decrypt information that was encrypted using the public key. Also, documents (such as webpages) that have been encrypted using the private key carry a specific signature that can be identified using the corresponding public key.
The public and private keys together form a cryptographic key pair.
In addition to the two keys, each SSL certificate holds additional data. At the very least, every SSL must specify the domain name, often referred to as the Common Name, that the SSL is issued for. If the SSL uses Organization Validation or Extended Validation, then this last SSL part will also hold the company name, the country and address of the organization, and other similar information. SSL certificates are able to hold such data since they are based on the X.509 digital document standard.
Lastly, when you buy an SSL certificate, you will likely also receive an Intermediate SSL Certificate. The purpose of the Intermediate SSL certificate is to establish a chain of trust between your SSL and the Root Certificate Authority that is trusted by your clients.
How Do I Install an SSL Certificate?
The exact steps to install an SSL certificate can vary greatly from one server to the next. The server operating system, the server software application, and any installed user management consoles all play a role in determining what steps need to be followed to install an SSL certificate.
Here at AwardSpace, we try to make the SSL installation process as seamless as possible. As such, we have a special section in our Control Panel called the SSL Manager where you can quickly and easily upload your SSL certificate. For additional information, read our article on how to install an SSL certificate, or alternatively you may review all features of the SSL Manager.
While the SSL Manager is a great tool for setting up SSL encryption for each of your websites, we didn’t stop there. If you decide to purchase an SSL certificate from us, our Sales Team will handle the entire installation process for you. All that you need to do is to choose which domain name you wish to protect using SSL.
SSL security is considered an advanced hosting feature and as such, it is not available on all of our hosting plans. To be able to install an SSL certificate on your hosting account, you need to be using one of our premium shared hosting plans, a semi-dedicated server, or a Virtual Private Server. At this time, you will not be able to protect your website with SSL encryption if you are using our free website hosting package.
What Added Security Can SSL Bring to My Website?
The security provided by SSL is a great addition to any site, however, it will not make your web pages completely invulnerable to attacks. In this section, we will look at what SSL can and cannot do when it comes to website security.
To start, we’ll look at the security benefits that can be gained from an SSL. Without a doubt, one of the biggest advantages is SSL encryption. If your website has an SSL installed, then the information that is exchanged between the web server and your visitors will be encrypted. This makes it very difficult for hackers to eavesdrop and read what is communicated.
In a similar vein, encryption also guards against man-in-the-middle attacks where a third party may try to position themselves between your server and your site visitors. Since these types of attacks are not possible with SSL encryption, you can rest easy knowing that a third party will not interfere and alter the communication that occurs between your site and your visitors.
SSL security brings another great protection – identity verification. This makes it impossible for an impostor to upload a phishing website with a valid SSL certificate. Phishing websites can still be created, but they will never have your SSL certificate.
This pretty much sums up all of the security benefits that can be gained from an SSL certificate. Now, we will look at the things an SSL cannot protect you from.
The most important security aspect that is not covered by an SSL certificate is the coding on your site. If there is a bug and hackers exploit it, they may be able to take full control of your website. As a result, they may inject malicious code, deface your web pages, or bring down your online presence outright. To protect against this, we recommend always keeping your website software up-to-date.
Another thing an SSL will not be able to guard against is a weak password. If you use an easy-to-guess password to log into your website, hackers may be able to crack it, use your credentials to log in, and take full control over your website.
We wholeheartedly recommend supplanting your SSL security with additional protective measures. You can read our article on how to protect a website for some suggestions which you may be able to implement.
How Can I Secure My Website Using SSL?
It is important to note that simply installing an SSL certificate on the server that is hosting your website will not automatically enable SSL encryption. In most cases, you would also need to set up some redirection rules to force your visitors to use an HTTPS connection. Otherwise, whenever someone visits your website, they will continue using HTTP and will not benefit from the available SSL security.
You can read our article on the differences between HTTP and HTTPS for more information on the two protocols. Also, we recommend going through our article on how to set up an HTTPS redirection.
Does My Website Require an SSL Certificate?
Having an SSL certificate on your website has two main benefits: it increases your visitors’ confidence and it also protects the data that is transmitted. As such, an SSL certificate is recommended for all websites, however, there are some cases where SSL encryption is essential.
The most common scenario where a website must have an SSL certificate is when the visitors are expected to disclose sensitive personal information such as their names, email, password, addresses, phone numbers, etc. If you do not have an SSL certificate, most web browsers will show a Not Secure warning which will deter users from disclosing sensitive information on your website.
The lack of SSL encryption can also have disastrous effects if you run an online store. Most consumers nowadays are savvy enough to know that they should not enter their credit card numbers into websites that do not have the little green padlock icon in the address bar. So, if you leave your online store without SSL security, you will hardly see any sales.
That said, even if you do not sell anything online but simply have a company website where customers can learn about your products and services, it is still highly recommended to have an SSL certificate. If a business does not use SSL, it will raise a red flag with most visitors. The lack of SSL signals that the business is either brand new and cannot yet afford an SSL certificate or the company website has been abandoned for years and nobody has bothered to install an SSL certificate on it. Both of these scenarios will reflect poorly on your business, so getting an SSL certificate is essential nowadays.
A Secure Sockets Layer certificate is also useful even if you do not run a publicly accessible website. SSL can be used to secure other types of servers such as FTP, database, and mail servers. Some larger organizations may even opt to secure their internal portals with SSL.
Overall, SSL has become table stakes when it comes to having a reputable website. Competition on the Internet is growing by the day, so as a website owner, you should take every step that has the potential to increase visitor trust and keep visitors on your website. And to top it all off, search engines like Google have started rewarding websites that use SSL with a higher ranking in search results.
Can I Edit My SSL Certificate After It Has Been Issued?
No, it is not possible to edit your SSL certificate after it has been issued. If you wish to alter your domain name or your company info, you would need to purchase a new SSL certificate and go through the verification process one more time.
That said, it is possible for most SSL providers to re-issue the SSL certificate that you have already purchased. This is useful in case the SSL gets accidentally deleted from your server and you do not have a backup copy.
Do I Need a Private IP Address to Use an SSL Certificate?
Back in the day, it was necessary for every SSL-enabled website to have its own private IP address. Fortunately, this is no longer the case, especially since the IPv4 address pool has been exhausted and spare IPv4 addresses are very hard to come by. The technology that allows multiple SSL-enabled websites to share a single IP address is called Server Name Indication (SNI). With that in mind, here at AwardSpace we still offer Private IP addresses for sale as they allow your SSL-enabled websites to be more independent.
Conclusion
SSL, or Secure Sockets Layer, is a cryptographic protocol that is capable of protecting your website using a combination of symmetric and asymmetric cryptography. Thanks to SSL, your website will enjoy increased protection, encryption of all communication with clients, increased user trust, better search rankings, and several other perks.
While the SSL label is alive and well, the actual SSL protocol has been gone for a few years now and is no longer supported by any major modern browser. Instead, a new protocol called Transport Layer Security (TLS) has taken over. TLS builds on the foundation laid out by SSL and takes security further by implementing new measures and protections to ensure a safer web.
