While Netscape originally invented SSL in the mid-90s, it didn’t become compulsory for every website to install an SSL/TLS certificate until the Summer of 2018 when Google began marking unencrypted sites “Not Secure.”
While Google – with its search engine, Chrome browser, and Android OS – can redefine the internet unilaterally, it was not alone on this mandate. Apple, Microsoft, Mozilla and the other major stakeholders in the tech industry have all made a concerted decision to mandate SSL/TLS certificates and HTTPS.
The reason for that is simple: without SSL/TLS and the ability to connect securely via HTTPS, all communication between websites and their visitors would be exchanged in plaintext and easily readable by a third party.
The only downside to this recent push for universal encryption is that it’s forced an influx of new customers into an unfamiliar market, one that does very little to make itself less confusing to the average website or business owner.
This article will serve as a comprehensive guide to all things SSL/TLS, we’ll lay the foundation by going over basic concepts like encryption, HTTPS and the nature of internet connections.
Hopefully, by the end, you’ll feel confident about selecting, purchasing, and implementing a TLS certificate, and remember if you have any questions that you can leave them in the comments below.
Let’s begin by discussing the concept that resides at the heart of all of this: encryption.
Encryption, in its most straightforward iteration, is little more than the scrambling of data – using a predetermined cipher or key – so that it is rendered unreadable by anyone except another party with the same private key.
Throughout history, private key encryption has been the most common model used. In private key encryption, both parties must possess or at least exchange a private key that can be used to both encrypt and decrypt information.
Early on, most of the ciphers underpinning these cryptosystems were primitive, relying on simple substitutions or replacing common words with characters. But over time the ciphers became more influenced by mathematics and grew in complexity.
For example, in the mid-1600s in France, King Louis XIV’s cryptographer created a cipher that was so well-designed that it wasn’t broken until 250 years later and only then partially. To this day there are hundreds of years’ worth of records in the French archives that may never be deciphered.
But whereas historically encryption has been a means for being covert or clandestine, the advent of the internet has taken the concept more mainstream. The internet is ubiquitous, and it handles a range of critical functions. Every day billions of people use it to access and send sensitive information, manage their finances, transact with businesses—you name it.
The problem is that the internet wasn’t wholly designed to scale to what it has become. Early on, in the days when academia and the US government were first developing networking protocols, the internet was only seen as a mechanism for the free exchange of information between the government and academic institutions. At that point, commercial activity was illegal online. eCommerce wasn’t a word that had even been invented yet. And web site was more of a geographical notion.
So, when HTTP or the Hypertext Transfer Protocol was first introduced in 1991, the fact that the connections it formed exchanged data in plaintext wasn’t a disqualifying problem.
Things are much different today. The information being exchanged online isn’t academic research or freely available information, it’s personally identifiable information and sensitive data that can cost people money or even, in some regions, their lives. This called for a more secure approach.
The answer was encryption.
One problem that has historically plagued even the best cryptosystems continues to persist to this day.
What we discussed earlier, and what has traditionally been the standard for encryption, is private key encryption. This is also called symmetric encryption, or two-way encryption—with private keys handling both the encryption and decryption functions needed to communicate.
For private key encryption to work the private key must be transferred between parties, or both parties need to possess their own copy. Either way, private key security was critical to the integrity of the cryptosystem and, as you can no doubt surmise, key exchange is a problem as old as encryption itself.
Then, in the 1970s – technically two different times, an entire ocean apart – a new form of encryption was conceptualized and brought to life: public key encryption.
Whereas private key encryption is a two-way function, symmetric, with the private key capable of both encrypting and decrypting data, public key encryption is asymmetric; one way. Rather than a single private key, there is a public-private key pair. The public key handles encryption and is, as the name implies, publicly available while the private key, which handles decryption, is kept secret by its owner. Using the public key, one can encrypt a piece of data and send it to the key’s owner, where only they will be able to decrypt it.
Great, but how is that useful?
Well, one-way encryption isn’t ideal for encrypting internet connections, it’s kind of difficult to communicate when one party can only encrypt, and the other can only decrypt. No, to encrypt an internet connection, you would need to use symmetric, private key encryption.
But how do you exchange keys? Especially online?
Public key encryption.
And that, distilled down to its very essence, is what SSL/TLS is all about: secure key exchange.
This is where we’ll tie all these concepts together. If you want your communication with a website to be private, then you need to connect to it securely. If you want to connect securely with that website, then you need to exchange symmetric private keys so you can use them to communicate. SSL/TLS (and PKI in general) is just a fancy mechanism for creating and exchanging that session key.
Using SSL/TLS, you can authenticate the server or organization you’re about to connect with and ensure that you securely exchange the private keys you’ll use to encrypt your communication with the intended party.
Unfortunately, SSL/TLS and PKI have a lot of terminology and moving parts that can easily confuse people, but those belie the fact that when you strip away all the math and the technical jargon, this is just an elegant modern technological solution to an age-old problem: key exchange.
Before we go any further, let’s go over a couple of other key terms. We already introduced HTTP, hypertext transfer protocol, which has been the backbone of the internet for decades. But as we discussed, the internet evolved into something much different than it was when HTTP was first published in 1991.
A more secure protocol was needed. Thus, HTTPS.
HTTPS, which is sometimes referred to as HTTP over TLS, uses encryption to render the data being exchanged during a connection unreadable to anyone but the intended party. This is especially important when you consider the nature of a modern internet connection.
Whereas in the early days of the internet a connection was reasonably direct, now connections are routed through dozens of devices on their way to their final destination. If you’ve ever wanted a practical demonstration of this, open the command prompt on your OS and enter the command “tracert geekflare.com.”
What you’ll see is the path that your connection traveled en route to its destination. Up to 30 jumps. That means that your data passes through each one of those devices before it reaches whatever website or application you’re connecting to. And if anyone has a packet sniffer or some listener installed on any one of those devices, they can steal any data transmitted and even manipulate the connection in some cases.
This is called a man-in-the-middle (MITM) attack.
If you want to learn about MITM attack, then check out this online course.
There is lot more surface area to cover with modern internet connections than the vast majority of people realize, which is why having the data encrypted during transmission is critical. You have no idea who could be listening, or how trivially easy it is to do.
An HTTP connection is made via port 80. For our purposes, you can think of ports as constructs that indicate a network service or protocol. A standard website being served via HTTP uses port 80. HTTPS typically uses port 443. When a website installs a certificate, it can redirect its HTTP pages to HTTPS ones, and users’ browsers will attempt to connect securely via port 443, pending authentication.
Unfortunately, the terms SSL/TLS, HTTPS, PKI and encryption all get tossed around a lot, sometimes even used interchangeably, so to clear up any lingering confusion, here’s a quick guide:
SSL/TLS works in conjunction to enable HTTPS connections. And PKI refers to the whole thing when you zoom out.
Got it? Don’t worry, you will.
Now that we’ve laid the foundation let’s zoom out and look at the architecture employed by the trust model at the heart of SSL/TLS.
When you arrive at a website, the first thing your browser does is verifies the authenticity of the SSL/TLS certificate that the site presents it with. We’ll get to what happens after that authentication takes place in a couple of sections, but we’re going to start by discussing the trust model that makes all this possible.
So, we’ll begin by posing the question: how does my computer know whether to trust a given SSL/TLS certificate?
To answer that, we’ll need to discuss PKI and the various elements that make it work. We’ll start with Certificate Authorities and Root programs.
A Certificate Authority is an organization that complies with a set of predetermined standards in return for the ability to issue trusted digital certificates.
There are dozens of CAs, both free and commercial, that can issue trusted certificates.
They all must abide by a set of standards that has been debated and legislated through the CA/Browser Forum, which acts as the regulatory body for the TLS industry. These standards outline things like:
These guidelines have been set forth by the browsers, in conjunction with the CAs. The browsers play a unique role in the TLS ecosystem.
Nobody can get anywhere on the internet without their web browser. As such, it’s the browser that will be receiving and validating the digital TLS certificate and then exchanging keys with the server. So, given their paramount role, they bear considerable influence.
And it’s important to keep in mind that browsers have been designed to be as skeptical as possible. To trust nothing. This is the best way to keep their users safe. So, if a browser is going to trust a digital certificate – which can potentially be misused to the detriment of the user – it needs certain assurances that whoever issued this certificate did their due diligence.
This is the role and responsibility of the Certificate Authorities. And the browsers don’t abide mistakes, either. There is a literal graveyard of former CAs that have run afoul of the browsers and been put out to pasture.
When a Certificate Authority has demonstrated its compliance with the CAB Forum baseline requirements and has passed all the requisite audits and reviews, it can petition the various root programs to have its Root certificates added.
A root program – the major ones are run by Apple, Microsoft, Google, and Mozilla – is the apparatus that oversees and facilitates root stores (sometimes called trust stores), which are collections of Root CA certificates that reside on a user’s system. Once again, these roots are incredibly valuable and incredibly dangerous – they can issue trusted digital certificates, after all – so security is of the utmost concern.
That’s why CAs almost never issue directly from the Root CA certificates themselves. Instead, they spin up intermediate root certificates and use those to issue end user or leaf certificates. They can also hand those roots off to Sub-CAs, which are Certificate Authorities that don’t have their dedicated roots but can still issue cross-signed certificates off their intermediates.
So, let’s put this all together. When a website wants to have a TLS certificate issued, it generates something called a Certificate Signing Request (CSR) on the server it’s hosted on. Contained in this request are all the details the website wants to be included on the certificate. As you’ll see in a bit, the amount of information can vary from complete business details to a simple server identity, but once the CSR is completed, it’s sent along to the Certificate Authority for issuance.
Before issuing the certificate, the CA will have to do its CA/Browser Forum-mandated due diligence and validate that the information contained in the CSR is accurate. Once that’s been verified, it signs the certificate with its private key and sends it back to the website owner for installation.
After the TLS certificate has been installed, anytime someone visits the site the server hosting it will present the user’s browser with the certificate. The browser is going to look at the digital signature on the certificate, the one that was made by the trusted certificate authority, which vouches for the fact that all information contained in the certificate is accurate.
This is where the term certificate chaining comes into play.
The browser is going to read the digital signature and move up a link on the chain—next, it will check the digital signature on the intermediate certificate whose private key was used to sign the leaf certificate. It’s going to continue following signatures until either the certificate chain ends at one of the trusted roots in its root store, or until the chain terminates without reaching a root, in which case a browser error will appear, and the connection will fail.
This is why you can’t issue and self-sign your certificates.
The browsers will only trust SSL/TLS certificates that they can chain back to their root store (meaning that they were issued by a trusted entity). Certificate Authorities are required to abide by specific standards to maintain their trustworthiness, and even then the browsers are loath to trust them.
Browsers have no such assurances about self-signed certificates, which is why they should only be deployed on internal networks, behind firewalls, and in test environments.
Before we look at SSL/TLS in motion, let’s talk about certificates and the various iterations that are available. TLS certificates are what facilitate the TLS protocol and help dictate the terms of the encrypted HTTPS connections that a website makes.
Earlier we mentioned that installing a TLS certificate allows you to configure your website to make HTTPS connections via port 443. It also acts as a sort of name badge for the site or server you’re interacting with. Going back to the idea that at its heart, SSL/TLS and PKI are all exquisite forms of secure key exchange, the SSL/TLS certificate helps notify the browser of who it’s sending the session key to—who the party at the other end of the connection is.
And when you break down the various iterations of SSL/TLS certificates, that’s a pertinent thing to keep in mind. Certificates vary regarding functionality and validation level. Or to put it another way, they vary based on:
Answering those two questions will give you a pretty clear indication of what type of certificate you need.
There are three different levels of validation available with SSL/TLS certificates, and they vary based on how much identity information your website wants to assert.
Domain Validation SSL certificates are by far the most popular owing to their price and the speed with which they can be issued. A DV SSL/TLS certificates require a simple domain control check, that can be accomplished several different ways, but as soon as it is the certificate can be issued. You can also get some 30-day and 90-day versions of these for free, which has undoubtedly added to their market share.
The downside is that DV SSL certificates assert minimal identity. And given that almost half of all phishing websites now have a DV SSL certificate installed on them, they don’t necessarily buy you much in the way of trust.
Organization Validation SSL certificates are the original type of SSL/TLS certificate. They’re also the only kind of SSL certificate that can secure an IP address following a 2016 decision by the CAB Forum to invalidate all intranet SSL certificates. Organization Validation requires a light business vetting and can typically be issued within a day or two—sometimes faster. OV SSL certificates assert some organizational information, but an internet user would need to click the padlock icon and look for it. Nowadays you see a lot of OV SSL certificates deployed on large enterprise and corporate networks, for connections made behind firewalls for instance.
Because neither DV nor OV SSL certificates assert sufficient identity to satisfy most browsers they receive neutral treatment.
Extended Validation SSL certificates are by far the most controversial, as some in the tech community feel more needs to be done to strengthen the validation they depend on. But, EV SSL asserts maximum identity. To complete extended validation, the Certificate Authority puts the organization through a rigorous vetting process that can take upwards of a week in some cases.
But the benefit is undeniable: because it asserts sufficient identity a website with an EV SSL certificate receives unique browser treatment, including having its name showcased in the browser’s address bar.
There is no other way to accomplish this, and you can’t fake one—the EV address bar is one of the most potent visual indicators we have today.
The other way that SSL/TLS certificates vary is regarding functionality. Websites have evolved quite a bit since the early days of the internet with various companies deploying sites in different ways. Some have multiple domains for different company verticals; others use sub-domains for multiple functions and web applications. Some use both.
No matter what the context is, there’s an SSL/TLS certificate that can help to secure it.
The primary website and the standard SSL certificate are just a single domain. Most modern SSL/TLS certificates will secure both the WWW and non-WWW versions of that domain, but it’s limited to a single domain. You can compare the SSL certificates here.
Multi-Domain certificates or Unified Communication Certificates (in the case of Microsoft Exchange and Office Communications servers) also exist to give organizations the ability to encrypt multiple domains with a single certificate. This can be an attractive option as it saves money and it makes managing the certificates (expirations/renewals) a lot simpler.
Multi-Domain and UCC certificates use SAN, the Subject Alternative Name field in the CSR, to add additional domains to the certificate. Most CAs allow up to 250 different SANs on a single certificate. And most Multi-Domain certificates come with 2-4 complimentary SANs with the rest available for purchase as needed.
Wildcard SSL certificates are an extremely useful certificate type because they can encrypt an unlimited number of sub-domains at the same level of the URL. For instance, if you have a website that uses sub-domains like:
You can encrypt them all with the same Wildcard certificate by using an asterisk in the FQDN field of your CSR: *.website.com
Now any sub-domain, even ones you haven’t added yet, can be secured with that certificate.
There are two downsides to Wildcard certificates though. The first is that by using the same public key across some endpoints, you’re more vulnerable to certain exploits like Bleichenbacher attacks.
The other is that there is no EV Wildcard option. Owing to the open-ended nature of Wildcard functionality, the browsers are not OK with delegating them that level of trust. If you want the EV Address Bar on your sub-domains, you’ll have to encrypt them individually or use an EV Multi-Domain certificate.
A relatively new addition to the SSL/TLS ecosystem, the Multi-Domain Wildcard can encrypt up to 250 different domains, but it can also use an asterisk in the SANs fields, which also allows you to encrypt 250 different domains AND all their accompanying first-level sub-domains.
Another use-case for the Multi-Domain Wildcard is as a multi-level Wildcard, where it can encrypt sub-domains at multiple levels of the URL (a standard Wildcard can only encrypt them on one level).
Because of the Wildcard functionality, Multi-Domain Wildcards are not available in EV, either.
Now that we’ve covered all the significant concepts that makeup SSL/TLS and PKI, let’s put it all together and see it in motion.
Let’s start all the way at the beginning with a website purchasing an SSL/TLS certificate from a CA or reseller. Following the purchase, the organizational contact that is handling the certificate acquisition creates a Certificate Signing Request on the server where the certificate will be installed (the server that hosts the website).
Along with the CSR, the server will also generate a public/private key pair and save the private key locally. When the CA receives the CSR and the Public Key, it performs the requisite validation steps to ensure that any information contained in the certificate is accurate. Generally, for business authentication certificates (not DV) this involves looking up an organization’s registration information and public records in government databases.
Once validation has been completed, the CA uses one of the private keys from one of its issuing certificates, typically an intermediate root, and signs the certificate before returning it to the site owner.
Now the website owner can take the newly issued SSL/TLS certificate, install it on their server and configure the website to make HTTPS connections on port 443 (using 301 redirects to send traffic from the pre-existing HTTP pages to their new HTTPS counterparts).
Now that the SSL/TLS certificate is installed, and the website has been configured for HTTPS, let’s look at how it will facilitate encrypted connections with the site’s visitors.
Upon arriving at the website, the server will present the SSL/TLS certificate to the user’s browser. The user’s browser then performs a series of checks.
First, it’s going to authenticate the certificate by viewing its digital signature and following the certificate chain. It will also make sure the certificate hasn’t expired and check Certificate Transparency (CT) logs and Certificate Revocation Lists (CRLs). Provided the chain leads back to one of the roots in the system’s trust store, and that it’s valid, the browser will trust the certificate.
Now it’s handshake time.
The SSL/TLS handshake is the series of steps where the client (user) and the server (website) negotiate the parameters of their secure connection, generate and then exchange symmetric session keys.
First, they’re going to decide on a cipher suite. A cipher suite is the group of algorithms and ciphers that will be used for the connection. The SSL/TLS certificate provides a list of cipher suites that the server supports. Generally, a cipher suite includes a public key encryption algorithm, a key generation algorithm, a message authentication algorithm and a symmetric or bulk encryption algorithm—though that has been refined in TLS 1.3.
Upon being presented with the list of supported ciphers, the client will pick an agreeable one and communicate it to the server. From there, the client will generate a symmetric session key, encrypt it using the public key and then send it along to the server, who possesses the private key needed to decrypt the session key.
Once both parties have a copy of the session key, communication can commence.
And that’s SSL/TLS.
You can see how all the concepts we went through earlier interact with one another to create a sophisticated yet elegant system for securing internet connections. We use public key cryptography to exchange the session keys securely we’ll be communicating with. The certificates that assert server or organizational identity can be trusted because of the infrastructure we have in place between the various CAs, browsers and root programs.
And communication occurs as a result of symmetric, private key encryption that is descendent from the classic cryptosystems of antiquity.
There are a lot of moving parts, but when you slow down and understand them all individually, it’s a lot easier to see how it all works together.
Before you go, let’s finish with a few SSL/TLS-related moves you can make post-installation/configuration to get the most from your investment.
Simply having a certificate installed and having your website configured correctly does not mean your website is safe. TLS is just one component of a broader, holistic cyber defense strategy. But an important component, nonetheless. Let’s cover a few things that you can do to ensure that you’re getting the most out of the implementation.
Doubling back to the conversation we had earlier about Cipher Suites, part of configuring your server is deciding what cipher suites and SSL/TLS versions to support. It’s imperative that you disable support for older SSL/TLS versions as well as specific algorithms to prevent vulnerability to several known exploits.
SSL 2.0 and SSL 3.0 are both over 20 years old. Best practice was to deprecate support for them years ago, but to this day around 7% of the Alexa top 100,000 still allow them. This is dangerous because it exposes you to SSL stripping and downgrade attacks like POODLE.
TLS 1.0 and TLS 1.1 are on borrowed time, too.
The major tech companies, Apple, Microsoft, Google, and Mozilla, made a joint announcement this Fall that they will deprecate support for TLS 1.0 and 1.1 at the start of 2020.
The protocol versions are susceptible to vulnerabilities like the POODLE, FREAK, BEAST, and CRIME (these are all acronyms). TLS 1.2 has been out for ten years and should be the standard. TLS 1.3 was finalized last Summer and adoption has been moving at a steady pace since.
Additionally, there are specific algorithms that should not be used, either. DES, for instance, can be broken in a matter of hours. RC4 is more vulnerable than once believed and has already been outlawed by the Payment Card Industry’s Data Security Standards. And finally, given news of recent exploits, it’s not advisable to use RSA for key exchange anymore.
In the past, websites have sometimes only migrated the web pages that collect information to HTTPS, while serving the rest of the site via HTTP. This is a bad practice.
In addition to the fact that Google will mark those pages “Not Secure,” you’re also potentially exposing your site’s visitors to risk by having their browsers jump back and forth between encrypted pages and HTTP ones.
You should be configuring your entire website for HTTPS. This is called Always-on SSL. After all, it’s not like you’re paying by the page, your SSL/TLS certificate can encrypt your entire site. So make it so.
One of the most significant risks posed by digital certificates, in general, is mis-issuance. If a party other than you get issued an SSL/TLS certificate for YOUR website, they can effectively impersonate you and cause all kinds of problems.
CAA records help mitigate this risk by restricting what Certificate Authorities can issue digital certificates for your website. Certificate Authorities are required by the CA/Browser Forum to check CAA records before issuing any certificate. If the CA doesn’t have the authorization to issue for that site, it can’t. Doing so would be considered a miss-issuance and garner the wrath of the browser community.
Adding a CAA record is relatively easy, it’s a simple DNS record that can be added through the interface of most hosting platforms. You can restrict the CAs that may issue for your domain, as well as whether Wildcard certificates may be issued for it, too.
HTTP Strict Transport Security, or HSTS, is an HTTP header that forces browsers only to make HTTPS connections with a given site. This way, even if the web user tries to go to the HTTP version of the page, they will only end up visiting the HTTPS version. That’s important because it shuts the window on several known exploits, like downgrade attacks and cookie hijacking.
Unfortunately, a tiny attack vector remains with HSTS, which is why you should add your website to the preload list. Typically, when a visitor arrives at your website, their browser will download the HTTP header and then abide it for however long the policy has been set to last. But on that very first visit, before the header has been received, there is still a tiny opening for an attacker.
The HSTS preload list of record is run by Google and some variation thereof used by all major browsers. Those browsers know only to connect via HTTPS to any website that’s on the list—even if it’s never visited there before. It may take a week or two for your site to appear on the list owing to the fact that updates to the list are pushed out in conjunction with the browsers’ release schedules.
You can refer to the following implementation guide.
What is an X.509 certificate?
X.509 refers to the type of digital certificate that is used with SSL/TLS and other types of PKI. X.509 is a public key encryption standard. Occasionally you’ll see companies use X.509 certificate in place of ‘digital certificate’ or ‘PKI certificate.’
Why do SSL/TLS certificates expire?
There are two reasons for this.
The first is that the internet is continually changing, websites come, and websites go. And given how sensitive the browsers are about trusting these certificates in the first place they want to know that the websites presenting the certificates are undergoing regular validations. It’s not that different from how you occasionally have to check in to update the information on your driver’s license.
The other reason is more technical. It’s harder to proliferate updates and technical changes when certificates don’t expire for 3-5 years. Whereas, if certificates expire every 24 months the longest any certificate could be out of date is two years. In 2017, maximum validity was reduced from three years to two. It will likely be shortened to 12 months shortly.
How do you renew an SSL/TLS certificate?
Renewal can be a bit of a misnomer because you are replacing the old certificate with a newly issued one. Doing this regularly allows you to stay up-to-date with new advancements with encryption technology and ensures your validation information stays up to date. CAs can only re-use the validation information that was initially supplied for so long before the baseline requirements compel them to re-validate it.
When you’re renewing, you can either keep the same certificate type you had before, or you can go with something new, you can even change CAs. The big thing is how much time you have remaining on the expiring certificate—you can carry over up to three months. As long as you renew before the certificate expires you can carry over any remaining time and re-use any validation information that hasn’t timed out since your last validation. If you let it expire, you start from scratch.
What is HTTPS Inspection?
A lot of larger companies with bigger networks like to have visibility over their traffic. In that regard, HTTPS is a double-edged sword. It protects people’s privacy, but it can also help cybercriminals hide, too. A lot of organizations will decrypt their HTTPS traffic at an edge device or a middlebox and then either send it along in plaintext behind their firewall or re-encrypt it and send it on its way. When you don’t re-encrypt the traffic, it’s called SSL Termination. When you do re-encrypt, that’s called SSL bridging.
What is SSL offloading?
SSL offloading is another enterprise practice. At scale, performing thousands of handshakes and then encrypting and decrypting all that data can tax a network’s resources. So, a lot of larger networks will offload the SSL functions to another device so that the application server can focus on its core tasks. This is sometimes referred to as load balancing.
Why did my CA send me an intermediate certificate?
Remember earlier when we discussed root programs?
Very OS has a root store that it uses to make PKI trust judgments. But CAs don’t issue end-user certificates off those roots for fear of what would happen if one ever had to be revoked. Instead, they spin up intermediate roots and issue off those. The problem is those intermediate roots don’t reside in a system’s trust store.
So, if the website doesn’t present the intermediate certificate along with the leaf SSL/TLS certificate, many browsers won’t be able to complete the certificate chain and will issue a warning. Some browsers do cache intermediate certificates, but it’s still considered best practice to install any intermediates along with your leaf certificate.
What documentation do I need for an Extended Validation SSL certificate?
In most cases, the Certificate Authority performing the extended validation will first attempt to access the information through publicly available “government authority” resources.
However, in some locations, this might not be possible. There are a few things that can assist in expediting the validation though. While the number of validation checks a Professional Opinion Letter can satisfy has been reduced recently, having an attorney or accountant in good standing sign one can still help considerably.
Additionally, you can provide a government-issued business credential or “Proof of Right” document that gives your organization the right to do business under the listed name. Some examples of these documents are:
I hope this gives you an idea about SSL/TLS. If you are interested in learning more, then I would recommend taking this online course.
This post was contributed by Patrick Nohe, editor of Hashed Out by The SSL Store, a blog covering cybersecurity news and trends.
