Digital Certificates — SAN, Wildcard, DV, OV, EV and SNI
In this post, we will look at different TLS/SSL certificates — DV, OV, EV, SAN, Wildcard, SNI & Virtual hosting.
Please review the links below for previous posts in this Digital Certificate series.
Digital Certificate series — Part 1
This four-part series will discuss various topics related to digital certificates. I have divided the content into four…
Digital Certificate series — Part 2
In the previous post, I talked about Digital Certificates, Certifying Authority, PKI models, Chain of Trust, and Root…
Explained — Digital Certificate — Part 3
So far, I have covered the certificate basics in Part 1 & Part 2 of the four-part series about digital certificates.
Predominantly, there are three types of SSL certificates
- Domain Validation (DV)
- Organizational Validation (OV)
- Extended Validation (EV)
These certificates have different validation requirements from the Certifying Authority (CA), with DV requiring the most basic checks, OV requiring additional inspections, and EV requiring the most stringent assessments.
Let’s look at each of these certificates in more detail.
- For Domain Validation (DV) certificates, CA needs minimum verification (email-based authentication may suffice) that the requester owns the domain. CA can verify the ownership¹⁵ of the domain by sending the email to the WHOIS registration email address.
- For Organizational Validation (OV) Certificates, CA requires the requester to verify both domain ownership and organization validation like proof of physical presence, telephone verification, etc.
- For Extended Validation (EV) Certificates, CA requires the requester to complete multiple verification checks, including domain ownership, verification of the company physical address, financial reviews, phone calls, etc. EV certificates require more stringent checks to protect customers’ medical, financial, and personal data against thefts and breaches and thus provide regulatory compliance for HIPAA, PCI DSS, GDPR, etc.
How to distinguish EV certificates from standard certificates?
Earlier, Chrome and Firefox used a green padlock sign along with the organization name and country name (where the organization is incorporated) to distinguish EV certificates¹ ².
But now, Chrome and Firefox have phased out the green padlock with a grey lock symbol. So just by looking at the lock symbol, it is hard to say whether the site has an extended validation or a domain validated certificate.
Can we still visually inspect and determine if a website is secured using an EV certificate?
Yes, we can. It needs a few more clicks or some understanding of certificate Object Identifiers (OIDs).
For e.g., In Chrome, you can click on the grey lock icon followed by clicking on “connection is secure”, and if the website has an EV certificate, the organization details should be visible in the pop-up window.
The example below shows the PayPal⁴ website’s EV certificate with the company name and country of incorporation (US).
The other method is more technical and requires checking certificate OIDs.
Per Wikipedia³, for an EV certificate, the subject field should contain at least the following OIDs
- OID 22.214.171.124.1.3126.96.36.199.3 — identifies the country where the organization is incorporated
- OID 188.8.131.52 — identifies organization is private/public/etc.
The subject field can contain other OIDs like the state where the organization is incorporated, etc.
The snapshot below shows the OID details for PayPal.com⁴ and HDFC.com¹⁶.
PRO TIP — SSL clients validate the server name against the server’s certificate. The certificate’s subject name should match the FQDN (fully qualified domain name) of the server the client is communicating with. If the domain name does not match the FQDN of the server, the browser will reject the certificate.
So, should we get a separate certificate for each subdomain if we have multiple subdomains?
No, and it would be impractical to have a different certificate for each subdomain. SAN and Wildcard certificates alleviate this issue.
SAN (Subject Alternative Names) certificates
SAN allows the listing of all of the subdomains as extensions under the “Subject Alternate Name” field in a single certificate. This saves us from needing a different certificate for each website.
SAN certificates are also known as Multi-Domain certificates and UCC Certificates.
- Multi-Domain certificates¹⁴ — one certificate can help secure multiple domains.
2. UCC (Unified Communications Certificates) — a single certificate can be used to secure Microsoft Exchange and Communications servers, etc.
Below we can see typical examples of the domain and subdomains that can be secured using SAN/Multi-Domain/UCC certificates
The figure below shows the SAN certificate for digicert.com⁶.
In the case of Wildcard certificates, the certificate is issued for the base domain prefixed with the wildcard. Because of the wildcard, the certificate is valid for all subdomains under the base domain.
The figure below shows a wildcard certificate⁷.
The websites can use wildcard certificates to secure websites with different subdomains like payments.example.com, login.example.com, mail.example.com, download.example.com, anything.example.com, etc.
PRO TIP — The *.example.com wildcard certificate can only secure subdomains under the base domain “example”. It cannot secure websites like mail.blog.example.com (mail is the subdomain of the “blog”) or payments.example.org (org is another TLD similar to com), etc.
The snapshot below shows a wildcard certificate from google.com.
You can have a combination of SAN & Wildcard SSL certificate called Multi-Domain Wildcard SSL certificate⁸, e.g., you need to buy only one SAN certificate and can add many wildcard sites under the SAN field, e.g.
- *. blog.domain.com
Let's change gears here and lightly introduce the topic of SNI and shared virtual hosting.
For a more detailed description of this subtopic, please visit the post below.
SNI and Virtual hosting
In the early days of HTTP, dedicated physical servers were used to host single websites. Virtualization replaced the…
Shared virtual hosting means that a single webserver hosts multiple domain names on the same IP and the same port number. This hosting method is very common nowadays. But in the early days, shared hosting created problems with SSL as the webserver did not know which website certificate to present to an incoming client request.
Before the SNI extension was added to the TLS protocol, the client did not have a formal way to tell the server which HOST it wants to connect to. Hence, the server could not present the “right” certificate to the client. The client and server were first engaged in a TCP handshake followed by an SSL(TLS) handshake and then the client issued a formal HTTP GET request to the server — telling the server the actual HOST it wanted to communicate.
This issue was resolved when the SNI extension was added to the SSL/TLS protocol. At a high level, SNI serves the same purpose as the HOST field in the HTTP GET header BUT during the SSL/TLS handshake
I hope you find this article helpful and stay tuned for my next post.
Happy Learning 😎