Skip to content

SSL Certificates

An SSL/TLS certificate is what turns http:// into https:// — the difference between a browser showing a padlock and one warning the visitor that the connection "is not secure." That is no longer optional today: browsers, search engines and compliance frameworks all treat missing HTTPS as a failure, not a technical detail.

What an SSL/TLS certificate is

Technically, "SSL" is the protocol's old name — what is actually in use today is TLS (Transport Layer Security), but the market keeps calling the certificate an "SSL certificate" out of habit. Both terms describe the same thing: a file signed by a Certificate Authority (CA) proving that a domain controls the matching private key, which enables:

  • Encryption — traffic between browser and server cannot be read by third parties on the network;
  • Authentication — the visitor is guaranteed to be talking to the correct domain, not an impostor;
  • Integrity — data cannot be altered in transit without the alteration being detected.

Without a valid certificate, modern browsers display explicit "not secure" warnings — which tanks conversion on any commercial site — and search engines penalize the ranking of pages without HTTPS.

The five certificate types

Not every certificate verifies the same thing. They split along two axes — what is validated and how many domains are covered:

Type What it verifies Coverage
Domain Validation (DV) Domain control only One domain (+ www)
Organization Validation (OV) Domain + the company's legal existence One domain (+ www)
Extended Validation (EV) Domain + company + extended verification One domain (+ www)
Wildcard Same as the chosen validation level Main domain + all subdomains
Multi-Domain (SAN/UCC) Same as the chosen validation level Several distinct domains, listed explicitly

DV, OV and EV are validation levels — they answer "how much the certificate confirms about who is behind the domain." Wildcard and Multi-Domain are coverage formats — they answer "how many hosts a single certificate protects." A Wildcard certificate, for instance, typically uses DV or OV validation underneath.

If you already know what you need, see the full certificate-choosing guide with the detailed comparison and a direct recommendation for anyone unsure where to start.

Real validity: why "5 years" is not one single certificate

The CA/Browser Forum — the body that defines the rules every browser-trusted Certificate Authority follows — has been reducing the maximum validity of any TLS certificate in stages:

In effect from Maximum validity
September 2020 398 days
March 15, 2026 (current) 200 days
March 15, 2027 100 days
March 15, 2029 47 days

This comes from Ballot SC-081v3, passed in April 2025 with support from Apple, Google, Microsoft and Mozilla — today, no CA issues a single certificate valid for 1 year, 2 years or 5 years: the current cap is 200 calendar days, and it will keep shrinking with every stage of the schedule.

What "2-year" or "5-year" plans actually sell is a subscription with automatic reissuance within the contracted term: you pay for the whole period up front, and the certificate is reissued every validity cycle (today, at most every 200 days — roughly twice a year, not once) with no manual action on your part and no additional charge. The benefit is commercial — the price per year drops the longer the contracted term — not technical. Never assume a "5-year" certificate stays valid without reissuance: if automatic reissuance fails for any reason, the old certificate expires within the cap in effect on its issuance date, currently 200 days.

Domain validation reuse is shrinking too

Alongside certificate validity, the CA/Browser Forum also cut the reuse period for domain validation (DCV) data: from 398 days down to just 10 days for domain validation (organization validation for OV/EV stays at 398 days for now). In practice, most reissuances can no longer reuse an old domain validation — DCV tends to repeat every cycle. That's why automating the DNS method matters more with every stage of this schedule.

Code Signing and S/MIME

Beyond certificates that protect a website, InteSys also issues two types that solve different problems:

  • Code Signing (standard and EV) — signs executables, drivers and scripts so operating systems do not flag them as untrusted;
  • Personal S/MIME — signs and encrypts email end to end, proving the sender's identity.

Neither one protects a website — if that is what you're looking for, start with the table above. Details on both are in the Code Signing & S/MIME guide.

How to get one from InteSys

Today, ordering is done by quote: you pick the certificate from the catalog, submit the request through the contact form, and our team handles issuance — including the domain validation (DCV) step — through to delivery ready for installation.

Not sure which certificate to pick?

The most commonly ordered certificates at InteSys are Positive SSL (one site) and Positive SSL Wildcard (site + subdomains) — a safe starting point for most cases. See the full choosing guide to compare every option.

See the full catalog and request a quote at InteSys SSL Certificates

Next Steps