SSL/TLS Terminology Made Simple — Certificates, PKI, DigiCert & SSL Tools

SSL/TLS Terminology and Certificate Types

A simple guide to TLS, certificate types and DigiCert domain validation using TXT, Persistent TXT, CNAME, email, HTTP and ACME—with practical examples.

⏱️ Estimated reading time: 15 minutes

✅ Checked with DigiCert: 30 August 2026

A digital certificate is like an online identity card. It can identify a website, person, device, company, software publisher or brand logo. This article explains the main terms without unnecessary PKI complexity.

Remember this: not every digital certificate is an SSL/TLS certificate. TLS protects network connections. Other certificates are used for software, documents, email, users, devices and brand logos.

📌 Contents

1. SSL, TLS and HTTPS
2. Main certificate types
3. DV, OV and EV
4. Single, wildcard and SAN
5. Important certificate terms
6. How domain validation works
7. Lifecycle and automation
8. CRL and OCSP
9. Common operational terms
10. Useful OpenSSL commands
11. SSLShopper knowledge base and tools

🔐 1. SSL, TLS and HTTPS

• SSL is the old security protocol. People still say “SSL certificate,” but modern systems use TLS.
• TLS is the current protocol that protects data moving between systems.
• HTTPS means website traffic is travelling through TLS encryption.

TLS mainly provides four things:

🔐 Encryption

Someone capturing the traffic should not be able to read passwords, payment details or application data.

🪪 Identity

The certificate helps the client confirm that it connected to the correct server name.

🧾 Integrity

TLS detects if data is changed while it travels across the network.

🤝 Trust

The certificate connects back to a trusted Certificate Authority such as DigiCert.

DigiCert reference: What are SSL, TLS and HTTPS?

🪪 2. Main types of digital certificates

The correct certificate depends on what you want to protect or prove.

Certificate type	What it does	Simple example
TLS/SSL certificate	Encrypts network traffic and identifies a website, API or server.	Protecting https://api.example.com
Client certificate	Identifies a user, device or application connecting to a service.	Authenticating an API client with mutual TLS
Code signing certificate	Proves who published software and shows whether the code was changed after signing.	Signing an application, driver, script or firmware package
Document signing certificate	Signs a document and helps prove who signed it and whether it was changed.	Digitally signing a PDF contract
S/MIME certificate	Digitally signs email and can encrypt the email content.	Protecting sensitive business email
Verified Mark Certificate (VMC)	Allows a verified trademarked logo to appear beside the sender in supported email inboxes.	Showing a bank’s verified logo in customer email
Common Mark Certificate (CMC)	Provides a similar email-logo use case for eligible marks protected through prior use rather than a registered trademark.	Showing an established company logo through BIMI

🏢 Example: one company may use several certificate types

Company requirement	Certificate to use	Example
Protect a public website or API	TLS/SSL certificate	Install a TLS certificate for api.example.com.
Allow only an approved application to call an API	Client certificate	The API validates the certificate presented by the payment application through mTLS.
Publish a Windows application	Code signing certificate	Sign ExampleBankSetup.exe so users can confirm the publisher and file integrity.
Send an official PDF statement	Document signing certificate	Digitally sign Annual-Statement.pdf so later changes can be detected.
Send confidential business email	S/MIME certificate	Sign and encrypt email sent from finance@example.com.
Show the company logo beside authenticated marketing email	VMC or CMC	Use VMC for an eligible registered trademark, or CMC for an eligible mark established through prior use.

VMC in simple language: VMC is a brand-identity certificate for email. It works with DMARC email protection and a BIMI DNS record. It does not replace a TLS certificate, and it does not encrypt your website.

DigiCert references: Specialized certificate types and Verified Mark Certificate.

🏢 3. DV, OV and EV TLS certificates

DV, OV and EV describe how much identity checking the Certificate Authority performs. They do not describe how many domains the certificate covers.

Type	What is checked	Common use
DV — Domain Validated	Control of the domain	Blogs, personal sites and services that do not need a verified company name
OV — Organization Validated	Domain control plus the legal organization	Company websites, enterprise applications and APIs
EV — Extended Validation	Domain, organization and additional high-assurance checks	Financial, regulated or highly brand-sensitive public services

🔎 Examples: how DV, OV and EV differ

Validation level	Example request	What the certificate proves
DV example	An engineer requests a certificate for demo.example.com and proves domain control with DNS TXT.	The requester controls the domain. DigiCert does not place a verified legal company identity in the certificate.
OV example	Example Financial Services Ltd requests a certificate for api.example.com. DigiCert validates the domain and the legal organization.	The domain is controlled by the requester and the organization identity has been verified.
EV example	A regulated financial company requests a certificate for secure.example.com. DigiCert performs the EV organization checks and requires approval from a verified contact.	The domain and organization passed the more detailed EV identity and approval process.

Important: EV does not automatically use stronger encryption than DV. Encryption strength depends on the TLS version, cipher, algorithm, key size and server configuration.

DigiCert reference: TLS certificate products and validation.

🌐 4. Single-domain, wildcard and multi-domain certificates

This category answers a different question: which names will the certificate cover? Validation level and hostname coverage are separate decisions.

Coverage	Example	What it covers
Single-domain	api.example.com	One exact hostname
Wildcard	*.example.com	First-level names such as api.example.com and mail.example.com
Multi-domain / SAN	example.com, example.net, login.example.org	Every hostname listed in the Subject Alternative Name field

A wildcard such as *.example.com normally does not cover the root name example.com or a deeper name such as api.dev.example.com. Add those names separately if required.

Wildcard risk: copying the same wildcard private key to many servers creates a large security impact if one server is compromised. Use controlled key storage and limit where the key is deployed.

DigiCert reference: Multi-domain SAN certificates.

🧩 5. Important certificate terms

Term	Simple meaning
CSR	Certificate Signing Request. It contains the public key and requested certificate names and is sent to the CA.
CN	Common Name. The main name shown in the certificate subject.
SAN	Subject Alternative Name. The list modern clients use to check which hostnames the certificate covers.
Private key	The secret part of the key pair. Never send it to the CA or expose it in email, tickets or pipeline logs.
Public key	The shareable part placed in the CSR and certificate.
Certificate chain	The server certificate plus intermediate CA certificates that connect it to a trusted root CA.
ACME	A standard protocol used by tools such as LEGO and Certbot to automate certificate requests and renewals.

📁 Common certificate file formats

• PEM — text format commonly used on Linux, Apache, Nginx and containers.
• PFX/P12 — normally contains the certificate, private key and chain; common on Windows, IIS and Azure.
• P7B — contains certificates and the chain, but not the private key.
• JKS — Java keystore format used by some Java middleware.

DigiCert reference: How certificate chains work.

✅ 6. How Domain Control Validation works

Domain Control Validation (DCV) is how DigiCert checks that you control a domain before issuing a TLS certificate. DV, OV and EV certificates all require domain validation. OV and EV also require organization checks.

🔄 The normal validation flow

1. Request or prevalidate the domain. Example: add example.com in DigiCert CertCentral.
2. Select a DCV method. Example: choose DNS TXT, Persistent DNS TXT, CNAME, email or HTTP.
3. Receive the proof. Example: DigiCert provides a random token, persistent URI, email approval link or validation file.
4. Publish or approve the proof. Example: add the supplied value to public DNS without changing it.
5. Let DigiCert check it. Wait for DNS propagation, then select the relevant check option in CertCentral or let automatic polling run.
6. Issue the certificate. When every requested domain—and the organization for OV/EV—is valid, DigiCert can issue the certificate.

Examples below are for learning only. The token values are fake. Always copy the exact current value shown in your CertCentral order or by your ACME client.

🧾 1. Standard DNS TXT validation

DigiCert gives you a random token. Add it as a TXT record on the exact domain being validated.

DNS field	Example for example.com
Type	TXT
Name / Host	@ or blank, depending on the DNS provider
Value	sample-digicert-random-token-8f21

For api.example.com, the host is normally api or the complete hostname, depending on the DNS provider. DigiCert’s random token expires after 30 days. The TXT record may be removed after validation succeeds.

♻️ 2. Persistent DNS TXT validation

Instead of creating a new random TXT record every time, place a DigiCert persistent URI in DNS and leave it there.

DNS field	Example for example.com
Type	TXT
Name / Host	_validation-persist Full name: _validation-persist.example.com
Value	digicert.com; accounturi=https://digicert.com/account/sample-persistent-id

• Account URI: the same public value can be used for domains in the CertCentral account. This is easier to manage.
• Unique URI: a different value is used for one domain. This avoids publicly linking several company domains through one shared value.
• Do not delete the record: DigiCert can check the same record again without asking the DNS team to publish a new token.

🧪 Persistent TXT example from start to finish

1. CertCentral displays the persistent URI digicert.com; accounturi=https://digicert.com/account/sample-persistent-id.
2. The DNS team creates _validation-persist.example.com as a TXT record and pastes that exact URI as its value.
3. The engineer checks it with dig TXT _validation-persist.example.com +short.
4. In CertCentral, the engineer selects Check TXT, or waits for automatic polling.
5. DigiCert finds the URI and validates example.com.
6. The DNS team leaves the record in place, allowing DigiCert to check the same proof again later without a new DNS change.

Record lifetime and validation lifetime are different. The persistent record and URI can stay in DNS. DigiCert’s current Persistent DNS TXT instructions state a nine-day validation reuse period; after that, DigiCert can recheck the same unchanged record. No new DNS value is required as long as the record remains correct.

🔗 3. DNS CNAME validation

Create a CNAME record that points to the DigiCert validation host.

DNS field	Example for example.com
Type	CNAME
Name / Host	_dnsauth Full name: _dnsauth.example.com
Target	_bs4fk5mhaqwf3902xevxvx.dcv.digicert.com

The random CNAME value expires after 30 days. The record can be removed after validation. Use the current _dnsauth format shown by DigiCert, not older internet examples that put the random value in the record name.

🧪 CNAME example from start to finish

1. CertCentral provides the token _bs4fk5mhaqwf3902xevxvx.
2. The DNS team creates _dnsauth.example.com as a CNAME.
3. The target is set to _bs4fk5mhaqwf3902xevxvx.dcv.digicert.com.
4. The engineer checks it with dig CNAME _dnsauth.example.com +short.
5. In CertCentral, the engineer selects Check CNAME, or waits for automatic polling.
6. After DigiCert validates the domain, the temporary CNAME record can be removed.

📧 4. Email validation

DigiCert sends an approval email. A recipient opens the link and approves control of the domain.

Email method	Example
Constructed address	admin@example.com, administrator@example.com, webmaster@example.com, hostmaster@example.com or postmaster@example.com. The domain needs a working MX record and the selected mailbox must be monitored.
DNS TXT contact	_validation-contactemail.example.com TXT "pki-team@example.com"
DNS CAA contact	example.com CAA 0 contactemail "pki-team@example.com"

WHOIS-based validation email is no longer supported by DigiCert. Use one of the approved methods above.

🌍 5. HTTP Practical Demonstration

Place a DigiCert token in a public file on the exact hostname being validated.

URL:
http://app.example.com/.well-known/pki-validation/fileauth.txt

File content:
sample-digicert-random-token-8f21

Port 80 must be publicly reachable. Validating app.example.com does not also validate example.com or www.example.com. HTTP validation is not supported for wildcard names.

🤖 6. ACME HTTP-01 validation

An ACME client such as LEGO or Certbot temporarily places a challenge file on the web server.

http://app.example.com/.well-known/acme-challenge/sample-token

This is suitable for automated non-wildcard certificates when port 80 is reachable. It does not support *.example.com.

🤖 7. ACME DNS-01 validation

The ACME client creates a temporary DNS TXT record:

DNS field	Example
Type	TXT
Name / Host	_acme-challenge.example.com
Value	sample-acme-challenge-value-4ab9

DNS-01 is the only DigiCert ACME challenge that supports wildcard validation. For full automation, the ACME client needs permission to create and remove TXT records through the DNS provider’s API. Without DNS write access, someone must update the record manually for each dynamic challenge.

Persistent TXT and ACME DNS-01 are not interchangeable: Persistent validation uses _validation-persist.example.com. ACME DNS-01 uses _acme-challenge.example.com. An existing Persistent TXT record does not itself answer a new DNS-01 challenge.

🧭 Which method should you choose?

Your situation	Practical choice
DNS team can make one change but repeated changes are difficult	Persistent DNS TXT
Simple manual validation	Standard DNS TXT
You prefer DNS delegation to a DigiCert validation target	DNS CNAME
A standard administrative mailbox is actively monitored	Email validation
You control a public web server on port 80	HTTP Practical Demonstration
Automated non-wildcard certificate and port 80 is available	ACME HTTP-01
Automated wildcard certificate and DNS API write access is allowed	ACME DNS-01

🔍 Check that the proof is publicly visible

dig TXT example.com +short
dig TXT _validation-persist.example.com +short
dig CNAME _dnsauth.example.com +short
dig TXT _acme-challenge.example.com +short
curl http://app.example.com/.well-known/pki-validation/fileauth.txt

DigiCert references: Supported DCV methods, DNS TXT, Persistent DNS TXT, DNS CNAME, and ACME challenges.

🔄 7. Certificate lifecycle and automation

• Issue: create a new certificate.
• Renew: continue coverage when the current order or certificate is approaching expiry.
• Reissue: create a replacement certificate on the same order, often with a new key or changed names.
• Revoke: permanently invalidate a certificate before it expires.
• Expire: the certificate reaches its “Not After” date and clients stop trusting it.

Current DigiCert public TLS limit: since 24 February 2026, newly issued public DV, OV and EV TLS certificates have a maximum validity of 199 days. A one-year commercial plan does not mean one 365-day certificate. Plan for automated inventory, renewal, deployment and validation.

A safe certificate lifecycle is: inventory → request → validate → issue → deploy → test → monitor → renew or revoke. Issuance is not the end of certificate management.

DigiCert reference: DigiCert plans and certificate validity.

🚫 8. CRL and OCSP — How certificate revocation is checked

A certificate can become unsafe before its expiry date. For example, its private key may be compromised or the Certificate Authority may need to revoke it. CRL and OCSP are two common ways systems can check whether a certificate has been revoked.

📋 CRL — Certificate Revocation List

A CRL is a list published by the Certificate Authority containing certificates that have been revoked.

Think of it like a blacklist. A client can download the list and check whether the certificate serial number appears in it.

🌐 OCSP — Online Certificate Status Protocol

OCSP lets a client ask an online CA responder about the status of one particular certificate.

Think of it like asking: “Is this certificate still valid, or has it been revoked?”

📋 Simple CRL flow

Certificate Authority (CA)
        |
        v
Publishes CRL
        |
        v
Client / Server downloads the list
        |
        v
Checks certificate serial number
        |
        +-- Found in CRL  → REVOKED
        +-- Not in CRL    → Not listed as revoked

🌐 Simple OCSP flow

Client / Browser
        |
        |  "What is the status of certificate ABC123?"
        v
OCSP Responder
        |
        +-- GOOD
        +-- REVOKED
        +-- UNKNOWN

Item	CRL	OCSP
Full form	Certificate Revocation List	Online Certificate Status Protocol
How it works	Downloads a list of revoked certificates	Checks the status of one certificate with an online responder
Simple analogy	Download the blacklist	Ask the CA about one certificate
Typical result	Certificate serial number is listed or not listed	GOOD, REVOKED or UNKNOWN

Expired and revoked are different. Expired means the certificate naturally reached its Not After date. Revoked means the CA intentionally invalidated it before expiry.

Easy way to remember: CRL = download the blacklist. OCSP = ask the CA about one certificate.

⚙️ 9. Common operational terms

One-way TLS

The client validates the server certificate. Normal public HTTPS uses this model.

Mutual TLS (mTLS)

The server and client both present certificates and authenticate each other.

TLS termination

A load balancer, gateway or proxy decrypts TLS before forwarding the request.

TLS passthrough

The front-end forwards encrypted traffic. The backend performs the TLS handshake.

SNI

Server Name Indication tells the server which hostname the client wants, allowing several certificates on one IP address.

Binding

The connection between a certificate and a hostname, IP address or port such as IIS port 443.

🛠️ 10. Useful OpenSSL verification commands

🔍 Inspect a certificate

openssl x509 -in server.crt -noout \
  -subject -issuer -dates -serial -fingerprint -sha256

🌐 Display the SAN list

openssl x509 -in server.crt -noout -ext subjectAltName

🔗 Check a live HTTPS endpoint and certificate chain

openssl s_client \
  -connect app.example.com:443 \
  -servername app.example.com \
  -showcerts </dev/null

🔑 Confirm that the certificate and private key match

openssl pkey -in server.key -pubout -outform PEM | sha256sum
openssl x509 -in server.crt -pubkey -noout | sha256sum

The two hashes must be the same.

🚨 Never print private keys, PFX passwords, ACME credentials or Key Vault secrets in command output or pipeline logs.

🧰 11. SSLShopper knowledge base and practical SSL/TLS tools

For day-to-day SSL/TLS learning and troubleshooting, SSLShopper is a useful independent resource. It combines an SSL knowledge base, FAQs and practical browser-based tools that can help engineers quickly inspect common certificate problems.

💡 How to use it: use official CA documentation such as DigiCert for CA-specific validation rules, certificate policies and validity changes. Use SSLShopper as a convenient learning and troubleshooting companion.

🔧 Useful SSLShopper tools

Tool	What it helps you check	Practical use
🔍 SSL Checker	Checks whether a public website certificate is installed correctly, trusted, within validity, using the correct hostname and serving the required intermediate chain.	After deploying or renewing a certificate, check the public hostname for common installation problems.
📝 CSR Decoder	Decodes a Certificate Signing Request so you can review the subject and public-key information before sending the CSR to a CA.	Validate a CSR before submitting a production certificate request.
📜 Certificate Decoder	Displays information stored inside a PEM certificate.	Quickly inspect certificate details when troubleshooting an unfamiliar certificate file.
🔑 Certificate Key Matcher	Checks whether a certificate matches a private key, or whether a CSR matches a certificate.	Useful when several CSRs, certificates and keys exist—but perform private-key checks locally for enterprise systems.
🔄 SSL Converter	Helps convert between common certificate formats such as PEM, DER, P7B and PFX.	Useful for understanding platform format requirements; perform conversions containing private keys locally with OpenSSL.
📚 SSL FAQ / Knowledge Base	Covers SSL/TLS basics, CSR creation, certificate installation, common errors, moving certificates between platforms, OpenSSL and Java keytool topics.	Helpful reference for junior engineers and for quick troubleshooting reminders.

🛡️ Enterprise recommendation: prefer local checks for secrets

Online tools are excellent for public certificate information and learning, but private keys are different. A production private key should remain on the trusted server, HSM, Key Vault or approved secure platform.

# Decode a CSR locally
openssl req -in server.csr -noout -text

# Decode a certificate locally
openssl x509 -in server.crt -noout -text

# Compare certificate and private-key public keys locally
openssl pkey -in server.key -pubout -outform PEM | sha256sum
openssl x509 -in server.crt -pubkey -noout | sha256sum

# Inspect a PFX locally
openssl pkcs12 -info -in server.pfx -noout

🚨 Do not upload production private keys, PFX/P12 files, PFX passwords, ACME credentials, Key Vault secrets or other enterprise secrets to public troubleshooting websites. Use local OpenSSL commands or an approved internal security tool whenever secret key material is involved.

✅ Good workflow: Learn → Generate locally → Decode/verify → Request → Deploy → Check the public endpoint → Monitor expiry. SSLShopper is particularly useful in the learn, decode and public-endpoint checking stages.

External troubleshooting resource: SSLShopper SSL Certificate Tools and SSLShopper SSL FAQ and SSL Labs.