Different Types of Certificates You Can Get Today

Today, trusted Certificate Authorities (CAs) like DigiCert, Sectigo, and GlobalSign offer several types of certificates categorized by their validation level (how much they vet you) and their functional scope (what they secure).

Validation Level

Domain Validated (DV) – CA confirms you control the domain (via email or DNS). Issued in minutes.  They are best used for blogs, personal sites, internal testing.  It is considered Basic Trust level.

Benefits of a DV SSL certificate:

• Validates control of a domain.
• Enables HTTPS and visible trust indicators in browsers, reassuring visitors that their connection is encrypted.
• Issues within minutes.
• Cost-effective solution for smaller websites, offering encryption without the need for complex business validation.

Organization Validated (OV) – CA verifies domain control + legal existence of the business. Usually issued in 1–3 days. Best fit for this validation level are  business websites ,login pages. It is considered a High Trust level.

Benefits of an OV SSL certificate:

• Validates both domain ownership and the organization’s business identity.
• Displays HTTPS and trust indicators in major browsers.
• Shows verified organization details in the certificate information, allowing users to confirm who operates the website.
• Issued within 1–3 business days once documentation is reviewed, balancing stronger validation with quick turnaround time.

Extended Validation (EV) – Rigorous vetting of physical location, legal status, and identity.  Best fit for these are  E-commerce, banks, and major brands.

Benefits of an EV SSL certificate:

• Validates domain ownership and verifies the legal identity of the organization.
• Displays HTTPS and trust indicators in browsers.
• Authenticates the legitimacy of an organization, adding an additional level of trust.
• Verifies the applicant has the right to request an EV SSL and is in good standing with the organization.
• Displays verified organization details within the certificate information, which users can inspect to confirm legitimacy.
• Offers the strongest protection against phishing attacks, making it difficult for malicious actors to impersonate the site.
• Issues in 1-5 days after all required documents are received.

Domain Coverage

One thing to note, when you hear “sub-domain“, the first thing one thinks of it as a “sub-domain” as in a web server that is in the US and you have an FQDN of  www.US.infosecmonkey.com, (the US has always been considered a sub-domain) however in the world of certificates, a subdomain is a prefix added to your main domain name (the “root” or “apex” domain) to organize or navigate to different sections of your website.  This could be mail., www., ftp.  The confusion, at least for some, is when you look at DNS (Domain Name System) ; as an example a zone file in Bind, considers a sub-domain as service.infosecmonkey.com.  In this example, you could have a www at the service.infosecmonkey.com level and you could also have a www at the infosecmonkey.com level.

Single-Domain –  Secures one Fully Qualified Domain Name (FQDN) like www.infosecmonkey.com.
Wildcard – Secures a base domain and unlimited subdomains (e.g., *.infosecmonkey.com covers mail., blog., and shop.).
Multi-Domain (SAN/UCC) – Secures multiple distinct domains on one certificate (e.g., infosecmonkey.com, mybrand.net, and dev.site.org).

A Multi-Domain Certificate, often referred to as a SAN (Subject Alternative Name) or UCC (Unified Communications Certificate), allows you to secure multiple, distinct domain names under a single SSL certificate.  These are usually sold with a base number of SANs and then additional SANs are on a per SAN base.  Normally, they are cheaper than buying separate Single-Domain certificates.

Key Rules to Remember with wildcard

Levels Matter – A wildcard for *.infosecmonkey.com secures blog.infosecmonkey.com, but it usually will not secure a second-level subdomain like test.dev.infosecmonkey.com.

Cost vs. Management – While Wildcards are more expensive than single-domain certs, they simplify management because you only have one expiration date to track for all your subdomains.

Trusted Certificate Authorities (CAs) 2026

DigiCert – https://www.digicert.com

Sectigo (formerly Comodo CA) – https://sectigo.com

GlobalSign – https://www.globalsign.com

Let’s Encrypt – https://letsencrypt.org

Entrust – https://www.entrust.com

GoDaddy – https://www.godaddy.com/web-security/ssl-certificate

SSL.com –  https://www.ssl.com

Network Solutions – https://www.networksolutions.com/security/ssl-certificates

Google Trust Services – https://pki.goog

Amazon Trust Services – https://www.amazontrust.com

*Amazon Trust Services used to be only for AWS devices and required a load-balancers, as of June 2025, this changed and now they do not requie a load-balancer and can be exported.

Process for Obtaining a Trusted Certificate

1. Create a Certificate Signing Request (CSR)

You package your Public Key along with identifying information about your organization (domain name, company name, location) into a file called a CSR.  For a wildcard certificate, the portal you are purchasing from can generate a CSR for you.

Note: Think of the CSR as your “application form.” It contains everything the authority needs to know to build your certificate.

2. Submit the CSR to a Certificate Authority (CA)

You send your CSR to a Certificate Authority (like DigiCert, Let’s Encrypt, or Sectigo). These are the “notaries” of the internet that browsers already trust.

3. Domain and Identity Validation

The CA doesn’t just take your word for it. They must verify you actually own the domain or represent the organization. This happens in levels as described above in the validation level section.

4. Issuance and Signing

Once the CA is satisfied, they take your public key and info, wrap it in a digital “envelope,” and sign it with their own private key. This signature is what makes the certificate  “trusted”

Because browsers (Chrome, Safari, etc.) already have the CA’s public key saved, they can verify the CA’s signature instantly.

5. Installation

The CA sends you the signed certificate (often a .crt or .pem file). You install this on your web server alongside your original Private Key.

Certificate File Formats

Navigating certificate formats can feel like wandering through a soup of acronyms. The “format” usually refers to how the data (the keys and certificates) is encoded and whether multiple items are bundled into a single file.  Most formats fall into two categories: Base64 ASCII (text-based, readable in Notepad) and Binary (not human-readable).

PEM (Privacy Enhanced Mail)
This is the most common format you’ll encounter, especially on Linux/Apache/Nginx servers.

Extension: .pem, .crt, .cer, .key

Encoding: Base64 ASCII. It starts with —–BEGIN CERTIFICATE—–

Contents: Can store public certificates, private keys, and intermediate CA chains.

When to use it: Almost any time you are working with web servers like Nginx or Apache.

PKCS#12 (Public Key Cryptography Standards #12)
Also known as PFX. This is a “suitcase” format that stores the server certificate, any intermediate certificates, and the private key all in one encrypted file.

Extension: .pfx, .p12

Encoding: Binary.

When to use it: Mandatory for Windows/IIS servers and often used to import certificates into Java KeyStores or personal browsers for client authentication. Because it contains the private key, it is almost always password-protected.

DER (Distinguished Encoding Rules)
This is the “raw” version of a certificate. If you take a PEM file and strip away the “BEGIN/END” headers and convert the Base64 back to binary, you get DER.

Extension: .der, .cer

Encoding: Binary.

When to use it: Mostly used in Java platforms or specialized legacy hardware. It typically only holds one certificate and no private key.

PKCS#7 / P7B
Unlike PKCS#12, this format cannot contain a private key. It is strictly used to bundle the public certificate and the “Chain of Trust” (intermediate certificates).

Extension: .p7b, .p7c

Encoding: Base64 ASCII. It starts with —–BEGIN PKCS7—–.

When to use it: Used often in Windows and Java Tomcat to export a bundle of certificates to prove the path back to a Root CA.

If you need to convert a certificate to a different format, you can do that with OpenSSL.  I wrote an article on that a while ago.

 

Hope this helps