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.

🔐DigiCert ACME Certificate Automation with LEGO, Persistent DNS & Azure Key Vault🔐

🔐 DigiCert ACME Certificate Automation with LEGO: Enroll, Renew, Reissue & Duplicate Using Persistent DNS + Azure Key Vault

Enterprise implementation guide using LEGO v5.3.1, DigiCert ACME, Persistent DNS validation, Linux, Managed Identity and Azure Key Vault.

⏱️ Estimated reading time: 19 minutes

go-acme / LEGO

This article uses *.example.com as a security-sanitized example. Never publish real EAB HMAC values, API keys, private keys, PFX passwords, Azure tokens or internal identifiers.

📘 Before You Start — Terms You Should Know

If you are new to certificate automation, these terms will make the rest of the article much easier to follow.

Term	Simple meaning
CA	Certificate Authority. In this design, DigiCert is the public CA that issues the certificate.
ACME	Automatic Certificate Management Environment — a standard protocol used to automate certificate lifecycle operations.
LEGO	An open-source ACME client. LEGO talks to DigiCert using the ACME protocol.
ACME Directory	The DigiCert CertCentral configuration/endpoint that defines which product, organization, domains and permissions the ACME client can use.
EAB KID	External Account Binding identifier used to associate the ACME client with the DigiCert ACME account.
EAB HMAC	Secret used together with the EAB KID. Treat it like a password and store it securely.
CSR	Certificate Signing Request containing the certificate subject and requested DNS names.
DCV	Domain Control Validation — proof that the requester is authorized to obtain a certificate for the domain.
Persistent DNS	DigiCert domain validation using a persistent TXT record that can be reused while the validation remains valid.
SAN	Subject Alternative Name — DNS names included in the certificate.
Order ID	The identifier of an existing DigiCert certificate order. It is used for explicit renew, reissue and duplicate operations.
PFX	A package that can contain the certificate, private key and certificate chain for deployment.
Azure Key Vault	Azure service used here to securely store ACME secrets and the issued certificate.

🔄 Simple End-to-End Flow

This is the high-level flow before we go into the detailed architecture.

1. Validate Organization in DigiCert (OV/EV) | v 2. Validate Domain using Persistent DNS | v 3. Create ACME Directory in DigiCert CertCentral | v 4. Store ACME URL + EAB KID + EAB HMAC in Azure Key Vault | v 5. Linux VM reads secrets using Managed Identity | v 6. LEGO connects to DigiCert | v 7. Choose certificate lifecycle action New Certificate Existing DigiCert Order | | v v ENROLL RENEW / REISSUE / DUPLICATE No Order ID Existing Order ID \ / \ / +---------------+------------------+ | v 8. DigiCert verifies authorization / validation | v 9. DigiCert issues certificate | v 10. Validate certificate + private key | v 11. Create PFX | v 12. Import to Azure Key Vault | v 13. Deploy to application / server

ACME Clientgoacme/lego:v5.3.1

ℹ️ ACME client alternative: This implementation uses LEGO v5.3.1, but Certbot or another compatible ACME client can also be used with DigiCert if it supports the required DigiCert ACME lifecycle workflow.

Lifecycle?action=renew&orderId=<ORDER_ID>

ValidationDigiCert Persistent DNS

Secret StoreAzure Key Vault

Azure IdentityManaged Identity

DNS WritesNone by LEGO in this design

Index

1. DigiCert ACME Lifecycle Actions and Order ID Rule
2. End-to-End Architecture
3. DigiCert Service User and Approval Delegation
4. Persistent DNS Domain Validation
5. Create ACME Directory in DigiCert CertCentral
6. DigiCert API Key
7. Azure Key Vault and Secrets
8. Managed Identity and RBAC
9. Prepare Linux
10. Directory Layout
11. Lifecycle Pre-checks
12. Create Private Key and CSR
13. Verify CSR and Key Match
14. Load Secrets and Build Action URL
15. Prepare LEGO Account State
16. Run LEGO with Selected Action
17. Expected Successful Behavior
18. Validate Issued Certificate
19. Create PFX and Import to Key Vault
20. Export PFX for Deployment
21. Cleanup and Security Controls
22. Production Checklist
23. Official References

💡 How to read this article: If you are new to ACME, read the glossary, simple flow and Sections 1–5 first. If you already understand PKI/ACME, you can jump directly to the architecture, Key Vault, LEGO and implementation sections using the Index.

🔁 1. DigiCert ACME Lifecycle Actions and Order ID Rule

DigiCert CertCentral supports four important lifecycle actions for third-party ACME clients: enroll, renew, reissue, and duplicate.

⚠️ Important terminology: DigiCert uses the action name reissue — not issue — when replacing a certificate under an existing order.

Action	Order ID required?	Simple meaning	Example
Enroll	No	Create a brand-new DigiCert certificate order.	You need a new *.example.com certificate and there is no existing order to target.
Renew	Yes for an explicit targeted action	Renew the certificate coverage on an existing order.	The existing certificate/order is reaching its renewal lifecycle.
Reissue	Yes for an explicit targeted action	Issue a replacement certificate under an existing order.	You need a new certificate/private key while keeping the same commercial order.
Duplicate	Yes	Issue another certificate from an existing order.	The same order needs an additional certificate instance and the certificate profile allows duplicates.

⚠️ What Happens to the Existing Certificate After Each Action?

This is important during production migration because issuing a new certificate does not always mean the certificate already installed on the server immediately becomes invalid.

Action	What happens to the existing certificate?	Operational meaning
Enroll	A new, independent DigiCert order and certificate are created. Existing certificates are not automatically replaced or revoked by the new enrollment.	You can deploy the new certificate separately. Old certificates continue according to their own validity/revocation status.
Renew	The renewal issues a new certificate with new validity. The certificate already deployed does not become invalid merely because the new certificate was issued; it normally remains usable until its own expiration unless it is separately revoked.	This gives an overlap window to deploy and validate the renewed certificate before the older certificate expires.
Reissue	A new version of the certificate is issued on the same order. The previous certificate can remain valid, but some reissue changes can trigger revocation. DigiCert specifically warns that changing or removing SANs can cause the original certificate and related duplicates/reissues to be revoked within 72 hours.	Do not assume an unlimited overlap window after a reissue. Check DigiCert Certificate History / revocation warnings and deploy the replacement quickly when SAN changes are involved.
Duplicate	A separate certificate is issued from the existing order. DigiCert documents duplicate certificates as a way to obtain another certificate without revoking the original.	Original and duplicate certificates can coexist. Each certificate has its own serial number and deployment location.

⚠️ Important: Certificate issuance and certificate revocation are different lifecycle events. Always verify the status of the old certificate in DigiCert CertCentral/Trust Lifecycle Manager before removing it from production. Reissue is the main case where requested certificate changes can cause automatic revocation of previously issued certificates.

Example migration window Existing certificate on production server | | Renew / Duplicate / eligible Reissue v New certificate issued | +---- Old certificate may still be valid | v Deploy new certificate | v Validate application / TLS | v Remove old deployment when safe Exception: Reissue with SAN changes/removal | v DigiCert may place older certificates into revocation pending | v Replace them before DigiCert's revocation deadline

🔗 Complete DigiCert ACME URL Examples

# Base ACME Directory URL https://one.digicert.com/mpki/api/v1/acme/v2/directory # ENROLL - create a new order - no Order ID required https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=enroll # RENEW - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=renew&orderId=555123456 # REISSUE - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=reissue&orderId=555123456 # DUPLICATE - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=duplicate&orderId=555123456

CertCentral auto-detection: If action and orderId are omitted, CertCentral can auto-detect a matching ACME-issued order and apply its default lifecycle action. If no matching order is found, the request is treated as a new enrollment. For predictable automation, this guide recommends using an explicit action when you know the intended lifecycle operation.

⚠️ Safety rule: Never allow automation to silently change between enroll, renew, reissue, or duplicate. Renew/reissue/duplicate operate against existing certificate lifecycle state, and renewal can have commercial/funding impact.

↑ Back to Index

🏗️ 2. End-to-End Architecture

DigiCert CertCentral Console | |-- Automation > ACME Directory URLs > Add ACME Directory URL |-- Select Product |-- Select validated Organization for OV/EV |-- Select Service User / Owner |-- Configure Allowed SANs / validity / restrictions |-- Generate ACME URL + EAB KID + EAB HMAC | v Azure Key Vault |-- ACME base URL |-- EAB KID |-- EAB HMAC |-- DigiCert API key (optional pre-checks) |-- Existing Order ID (for targeted existing-order actions) | v Azure DevOps / Engineer | v Linux VM / Self-hosted Agent |-- System-Assigned Managed Identity |-- Docker + LEGO v5.3.1 | v Lifecycle Decision | |-- New order | --> ?action=enroll | Order ID NOT required | |-- Existing order --> ?action=renew&orderId=<ORDER_ID> --> ?action=reissue&orderId=<ORDER_ID> --> ?action=duplicate&orderId=<ORDER_ID> | v Validation Gate |-- Domain/DCV valid |-- OV/EV Organization validation valid | v DigiCert ACME Authorization |-- Persistent DNS already valid |-- LEGO performs no DNS write in this design | v Certificate issued | v PFX --> Azure Key Vault --> Deployment systems

⚙️ ACME Directory creation: Create the ACME Directory credentials in the DigiCert CertCentral console. For Enterprise/Partner-style accounts, DigiCert documents the path as Automation → ACME Directory URLs → Add ACME Directory URL. The generated ACME URL, KID, and HMAC are shown once, so store them securely.

The architecture separates identities: DigiCert certificate automation uses the Service User + ACME EAB credentials, while Azure access uses the Linux VM Managed Identity.

Communication	Authentication / identity used
Linux VM → Azure Key Vault	Azure System-Assigned Managed Identity
LEGO → DigiCert ACME	EAB KID + EAB HMAC
DigiCert automation ownership	DigiCert Service User
Optional DigiCert API pre-checks	DigiCert Services API key

↑ Back to Index

👤 3. DigiCert Service User and Order Approval Delegation

Create a dedicated non-human DigiCert Service User. Select the same Service User as the ACME Directory user/owner. Where required, Order Approval Delegation should be approved.

↑ Back to Index

🌐 4. Persistent DNS Domain Validation

The DNS team creates the DigiCert Persistent DNS validation TXT record in the authoritative zone. LEGO should not create, update or delete DNS records during the certificate operation.

🌍 Normal DNS Challenge vs Persistent DNS

Normal DNS-01 automation	Persistent DNS design used here
ACME client creates a temporary TXT challenge record, waits for validation, and later removes it.	DNS team creates DigiCert's persistent validation TXT record once. When DigiCert still shows the domain as Valid, LEGO does not need to modify DNS during the certificate operation.

Normal DNS Challenge LEGO --> Create temporary TXT --> DNS --> DigiCert validates --> TXT can be removed Persistent DNS Design DNS Team --> Create persistent TXT once --> DigiCert DCV Valid | v LEGO --> DigiCert | v "Authorization is already valid" | v No DNS modification

Record Type : TXT Record Name : _validation-persist FQDN : _validation-persist.example.com Record Value: digicert.com;accounturi=https://digicert.com/account/<PERSISTENT_ACCOUNT_URI> TTL : 300

dig TXT _validation-persist.example.com @8.8.8.8 +short dig TXT _validation-persist.example.com @1.1.1.1 +short

⚠️ Important: Public DNS visibility does not prove that DigiCert currently shows the domain as Valid. Confirm DCV status in DigiCert before the certificate operation.

✅ Expected LEGO message: Authorization is already valid; skipping the challenge.

DigiCert Persistent DNS is not the same as LEGO's --dns-persist option.

↑ Back to Index

⚙️ 5. Create the ACME Directory in DigiCert CertCentral

What is an ACME Directory? Think of it as the DigiCert configuration and ACME endpoint that tells LEGO which certificate product, validated organization, domains/SANs and restrictions it is allowed to use.

The ACME Directory must be created in the DigiCert CertCentral console. For Enterprise and Partner accounts, go to:

CertCentral --> Automation --> ACME Directory URLs --> Add ACME Directory URL

Configure the ACME credentials with the certificate settings that should apply to requests made through this directory.

Setting	Recommendation
Name	Use a clear automation-specific name.
Product	Select the exact DigiCert certificate product you intend to use.
Organization	For OV/EV, select the validated organization that should appear in the certificate.
User / Owner	Select the dedicated DigiCert Service User.
Allowed SANs	Restrict the directory to only the approved domains/SANs.
Validity / Coverage	Use your organization-approved DigiCert certificate settings.

🏢 Organization / CSR [O] note: For OV/EV certificates, the organization selected in CertCentral must be an active, validated organization. If your CSR contains an O = (Organization) value, keep that value consistent with the validated legal organization selected for the ACME credentials. Do not use a different organization name in the CSR. The organization itself is selected in CertCentral; it is not supplied through the orderId URL parameter.

DigiCert CertCentral Organization | v Example Organization Limited | v CSR Subject O = Example Organization Limited Order ID is a different concept: Order ID = identifies an existing DigiCert certificate order.

📋 New enrollment prerequisite: For a new OV/EV enrollment, make sure the intended organization validation is current and the certificate domains are validated/authorized before expecting immediate issuance. DigiCert states that new organizations must complete validation before ACME issuance can succeed.

After creating the ACME Directory, CertCentral displays the ACME Directory URL, EAB KID, and EAB HMAC. Store them immediately in Azure Key Vault. DigiCert displays these credentials only once.

↑ Back to Index

🔑 6. DigiCert API Key

A DigiCert Services API key is optional for LEGO issuance. It can be used for controlled pre-checks such as order details, product, expiry, domain validation and organization validation.

🔐 LEGO issuance uses: ACME Directory URL + EAB KID + EAB HMAC.

↑ Back to Index

🔐 7. Azure Key Vault and Secrets

Secret	Purpose
DIGICERT-ACME-URL-EXAMPLE-PROD	ACME base URL
DIGICERT-EAB-KID-EXAMPLE-PROD	EAB KID
DIGICERT-EAB-HMAC-EXAMPLE-PROD	EAB HMAC
DIGICERT-API-KEY-EXAMPLE-PROD	Optional API key
DIGICERT-ORDER-ID-EXAMPLE-PROD	Existing Order ID — needed only when explicitly targeting renew, reissue or duplicate

RG="<RESOURCE_GROUP>" LOCATION="centralindia" VAULT="<KEY_VAULT_NAME>" az keyvault create --name "$VAULT" --resource-group "$RG" --location "$LOCATION" --enable-rbac-authorization true

Never publish EAB HMAC, API keys, PFX passwords, private keys or Azure tokens.

↑ Back to Index

🛡️ 8. Managed Identity and RBAC

Role	Purpose
Key Vault Certificates Officer	Certificate import/manage
Key Vault Secrets User	Read ACME/EAB/API/order secrets

az login --identity --allow-no-subscriptions az keyvault secret show --vault-name "<KEY_VAULT_NAME>" --name DIGICERT-ACME-URL-EXAMPLE-PROD --query id -o tsv

↑ Back to Index

🐧 9. Prepare Linux

cat /etc/os-release openssl version docker --version az version systemctl is-active docker docker pull goacme/lego:v5.3.1 docker run --rm goacme/lego:v5.3.1 --version

Required path: outbound HTTPS TCP/443 to DigiCert and Azure Key Vault. No inbound listener is required when authorization is already valid through Persistent DNS.

↑ Back to Index

📁 10. Directory Layout and Permissions

sudo mkdir -p /datadisk/ssl-cert-auto/lego/prod/example-wildcard/{account-state,transaction-state,csr,output,logs,export} sudo chmod 700 /datadisk/ssl-cert-auto/lego/prod/example-wildcard/{account-state,transaction-state,csr,output,export}

↑ Back to Index

✅ 11. Pre-checks Before Enroll, Renew, Reissue, or Duplicate

1. Managed Identity login works.
2. Azure Key Vault access works.
3. DigiCert Service User is active.
4. Order Approval Delegation is approved where required.
5. The ACME Directory is created in DigiCert CertCentral and assigned to the intended Service User.
6. The certificate product in the ACME Directory matches the intended request.
7. For OV/EV, the selected organization is active and validation is current.
8. If the CSR contains O =, keep it consistent with the validated organization selected in CertCentral.
9. Persistent DNS/DCV for all requested domains is valid.
10. CN/SANs are allowed by the ACME Directory restrictions.
11. Enroll: no existing Order ID is required when explicitly using ?action=enroll.
12. Renew / Reissue / Duplicate: confirm the exact existing Order ID before building the explicit action URL.
13. For duplicate, confirm the certificate profile allows duplicates.
14. For renewal, confirm commercial/funding approval where applicable.

⚠️ Production rule: If domain validation or required OV/EV organization validation is not Valid, stop the automation. Do not bypass validation and do not give LEGO DNS write access for this Persistent DNS design.

↑ Back to Index

🧾 12. Create Private Key and CSR

[ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn req_extensions = req_ext [ dn ] C = IN ST = Maharashtra L = Mumbai O = Example Organization Limited CN = *.example.com [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = *.example.com DNS.2 = example.com

openssl genrsa -out example-wildcard.key 2048 chmod 600 example-wildcard.key openssl req -new -key example-wildcard.key -out example-wildcard.csr -config example-csr.conf

↑ Back to Index

🔎 13. Verify CSR and Key Match

openssl req -in example-wildcard.csr -noout -subject openssl req -in example-wildcard.csr -noout -text | grep -A2 "Subject Alternative Name" openssl pkey -in example-wildcard.key -pubout -outform DER | sha256sum openssl req -in example-wildcard.csr -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum

The two public-key hashes must match.

↑ Back to Index

🔗 14. Load Secrets and Build the Required ACME Action URL

Load the ACME base URL and EAB credentials from Azure Key Vault. Load an Order ID only for an operation that targets an existing order.

VAULT="<KEY_VAULT_NAME>" BASE_ACME_URL="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-ACME-URL-EXAMPLE-PROD --query value -o tsv)" export LEGO_EAB_KID="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-EAB-KID-EXAMPLE-PROD --query value -o tsv)" export LEGO_EAB_HMAC="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-EAB-HMAC-EXAMPLE-PROD --query value -o tsv)" # NEW ENROLLMENT - no Order ID export LEGO_SERVER="${BASE_ACME_URL}?action=enroll" # EXISTING ORDER examples - load Order ID first export ORDER_ID="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-ORDER-ID-EXAMPLE-PROD --query value -o tsv)" # Renewal export LEGO_SERVER="${BASE_ACME_URL}?action=renew&orderId=${ORDER_ID}" # Reissue export LEGO_SERVER="${BASE_ACME_URL}?action=reissue&orderId=${ORDER_ID}" # Duplicate export LEGO_SERVER="${BASE_ACME_URL}?action=duplicate&orderId=${ORDER_ID}"

💡 Operational recommendation: Make the action an explicit pipeline parameter with an allow-list such as enroll|renew|reissue|duplicate. Require an Order ID for renew/reissue/duplicate and reject an Order ID for a forced new enroll.

↑ Back to Index

🧩 15. Prepare LEGO Account State for the Certificate Transaction

BASE_STATE=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/account-state TRANSACTION_STATE=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state rm -rf "$TRANSACTION_STATE" mkdir -p "$TRANSACTION_STATE" chmod 700 "$TRANSACTION_STATE" # Reuse only the ACME account state when it already exists. if [ -d "$BASE_STATE/accounts" ]; then cp -a "$BASE_STATE/accounts" "$TRANSACTION_STATE/" fi

💡 Why use transaction-state? This article covers enroll, renew, reissue and duplicate, so the generic name avoids making every operation look like a renewal. Reuse the ACME accounts state when appropriate, but start the certificate transaction without carrying an old local certificates directory that could influence LEGO local renewal timing.

💡 About --renew-force: Use this LEGO flag only when you intentionally want LEGO to submit a renewal even when its local renewal timing says the certificate is not due yet. It does not select the DigiCert lifecycle action. DigiCert renewal must still be explicitly selected through LEGO_SERVER, for example ?action=renew&orderId=.... Do not add --renew-force to enroll, reissue or duplicate examples.

↑ Back to Index

🚀 16. Run LEGO with the Selected DigiCert Action

The DigiCert lifecycle behavior is determined by LEGO_SERVER. For renewal, the following example also uses LEGO --renew-force so LEGO does not skip the request because of its local renewal timing.

♻️ Renew Example — with --renew-force

# LEGO_SERVER must already contain: # https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=renew&orderId=<EXISTING_ORDER_ID> docker run --rm -v /datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state:/var/lib/lego:Z -v /datadisk/ssl-cert-auto/lego/prod/example-wildcard/csr:/csr:Z -e LEGO_SERVER -e LEGO_EAB_KID -e LEGO_EAB_HMAC goacme/lego:v5.3.1 run --path /var/lib/lego --accept-tos --email "certificate-automation@example.com" --eab --http --renew-force --csr /csr/example-wildcard.csr

⚠️ Important: --renew-force is a LEGO renewal-timing flag. It forces LEGO to renew even if the locally stored certificate is not yet due. It does not replace DigiCert's ?action=renew&orderId=... URL.

🔁 Enroll / Reissue / Duplicate

Do not use --renew-force merely to trigger enroll, reissue or duplicate. Select those DigiCert lifecycle actions through the ACME URL (LEGO_SERVER) and run LEGO without the renewal-force flag.

🌐 Why --http? LEGO requires a challenge solver to be selected. In this design DigiCert should already consider authorization valid through Persistent DNS, so the challenge is skipped. If a wildcard authorization is not already valid, stop and fix DCV rather than attempting HTTP-01 validation.

↑ Back to Index

✅ 17. Expected Successful Behavior with Persistent DNS

INFO Obtaining bundled SAN certificate given a CSR. INFO Authorization is already valid; skipping the challenge. INFO Validations succeeded; requesting certificates. INFO Server responded with a certificate.

The key design result: no per-operation DNS TXT write is required when DigiCert authorization remains valid through Persistent DNS.

↑ Back to Index

🔍 18. Validate the Issued Certificate

CERT=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state/certificates/_.example.com.crt openssl x509 -in "$CERT" -noout -subject -issuer -serial -dates -ext subjectAltName openssl x509 -in "$CERT" -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum openssl pkey -in /datadisk/ssl-cert-auto/lego/prod/example-wildcard/csr/example-wildcard.key -pubout -outform DER | sha256sum

↑ Back to Index

📦 19. Create PFX and Import the Certificate to Key Vault

PFX_PASSWORD="$(openssl rand -base64 32)" openssl pkcs12 -export -out example-wildcard-renewed.pfx -inkey example-wildcard.key -in _.example.com.crt -certfile _.example.com.issuer.crt -password pass:"$PFX_PASSWORD" az keyvault certificate import --vault-name "<KEY_VAULT_NAME>" --name EXAMPLE-WILDCARD-PROD --file example-wildcard-renewed.pfx --password "$PFX_PASSWORD" unset PFX_PASSWORD

↑ Back to Index

📤 20. Export PFX for Deployment

az keyvault secret download --vault-name "<KEY_VAULT_NAME>" --name EXAMPLE-WILDCARD-PROD --file EXAMPLE-WILDCARD-PROD.pfx --encoding base64 chmod 600 EXAMPLE-WILDCARD-PROD.pfx

⚠️ Temporary PEM risk: if repackaging with -nodes, the temporary PEM contains unencrypted private-key material. Delete it immediately.

↑ Back to Index

🧹 21. Cleanup, Logging and Security Controls

• Never echo EAB HMAC, API key, PFX password, private key or Azure token.
• Protect and retain reusable LEGO account state.
• Retain audit metadata: order ID, serial, thumbprint, validity dates and pipeline run ID.
• Use Key Vault RBAC at Key Vault resource scope.
• Pin and vulnerability-scan the LEGO image.
• Do not grant DNS write privileges for this Persistent DNS design.

unset LEGO_EAB_KID unset LEGO_EAB_HMAC unset LEGO_SERVER unset ORDER_ID unset BASE_ACME_URL

↑ Back to Index

☑️ 22. Production Checklist

• ✅ Linux host hardened and tools verified.
• ✅ LEGO pinned to goacme/lego:v5.3.1.
• ✅ System-assigned Managed Identity enabled.
• ✅ Key Vault Certificates Officer assigned at Key Vault scope.
• ✅ Key Vault Secrets User assigned at Key Vault scope.
• ✅ ACME URL, EAB KID and EAB HMAC stored in Key Vault.
• ✅ For explicit renew/reissue/duplicate, the approved existing Order ID is securely available (for example in Key Vault).
• ✅ Dedicated DigiCert Service User configured.
• ✅ Order Approval Delegation approved.
• ✅ ACME Directory owned by the Service User.
• ✅ Persistent DNS validation is Valid.
• ✅ Organization and domain validation are current.
• ✅ For renew/reissue/duplicate, the existing Order ID and product are confirmed.
• ✅ For enroll, organization/product/domain prerequisites are confirmed and no existing Order ID is required.
• ✅ CSR CN/SANs match approved scope.
• ✅ Explicit lifecycle action is selected: enroll, renew, reissue, or duplicate.
• ✅ Before deployment, confirm the existing certificate revocation/overlap impact for the selected lifecycle action—especially for reissues that change or remove SANs.
• ✅ Order ID is supplied for explicit renew/reissue/duplicate, and is not required for a forced new enroll.
• ✅ No DNS write occurs during a healthy certificate operation when Persistent DNS/DCV is already valid.
• ✅ Issued certificate and private key match.
• ✅ PFX imported into Azure Key Vault and validated.

🎯 What This Architecture Demonstrates

• DigiCert ACME can be driven through LEGO using a dedicated Service User and EAB credentials.
• An existing DigiCert order can be explicitly targeted for renew, reissue or duplicate.
• Persistent DNS can avoid per-operation DNS TXT creation while authorization remains valid.
• Azure Managed Identity removes the need to store Azure credentials on the Linux host.
• Azure Key Vault can centrally store ACME credentials/metadata and the issued certificate.

↑ Back to Index

📚 23. Official References

• DigiCert — Create and manage ACME credentials in CertCentral
• DigiCert — ACME automation actions and URL parameters (CertCentral)
• DigiCert — ACME automation actions
• LEGO — Obtain / renew certificate with a CSR
• LEGO Documentation
• Microsoft — Azure Key Vault RBAC guide
• Microsoft — Managed identities for Azure resources

🔐 Security note: All names and domains in this article are sanitized examples. Never publish production credentials, real EAB values, API keys or private keys.

Published on MiddlewareBox.com

Suggested labels: DigiCert, ACME, LEGO, SSL, TLS, Azure Key Vault, Managed Identity, Certificate Automation, Persistent DNS, DevOps

🏢 Enterprise Authentication & Identity Security Series

🔐 Authentication & Identity Security Series for Middleware, DevOps & Cloud Engineers

Welcome to the Authentication & Identity Security Series

This 10-part series is designed for Middleware Engineers, DevOps Engineers, Cloud Engineers, Security Engineers and Application Support Teams who want to understand modern authentication, authorization, API security, identity management, and Zero Trust architecture.

Whether you work with WebSphere, JBoss, Tomcat, Microsoft Entra ID, Azure, APIs, or enterprise applications, this series will help you understand authentication from traditional session-based applications to modern cloud-native identity platforms.

---

---

---

---

---

📚 Complete Authentication & Identity Security Roadmap

Part	Topic	Summary
Part 1	🔐 What is Authentication?	Authentication basics, Authorization, login flow, and modern authentication concepts.
Part 2	🆔 Sessions, Cookies & JSESSIONID	Learn how applications maintain user state using sessions, cookies, and JSESSIONID.
Part 3	⚖️ Stateful vs Stateless Applications	Understand traditional session-based applications versus stateless cloud-native applications.
Part 4	🎫 JWT & Token-Based Authentication	JWT structure, bearer tokens, access tokens, refresh tokens, and token-based security.
Part 5	📊 JWT vs Session vs Cookies Explained	Compare Sessions, Cookies, and JWT authentication mechanisms.
Part 6	🚪 API Authentication & API Gateway Security	API keys, OAuth2, JWT validation, API gateways, and enterprise API security.
Part 7	🔄 OAuth2, OIDC & SAML Explained	Enterprise identity protocols used in SSO and federation.
Part 8	☁️ SSO, MFA & Microsoft Entra ID	Single Sign-On, Multi-Factor Authentication, Conditional Access, and Entra ID.
Part 9	🟦 WebSphere LTPA, Sticky Sessions & Session Replication	Enterprise middleware authentication, clustering, session management, and high availability.
Part 10	🛡️ Zero Trust Security & Authentication Risks	Zero Trust, Zscaler, PAM, SIEM, phishing, token theft, and modern security controls.

---

---

---

---

📌 Key Technologies Covered

Category	Technologies / Concepts	Purpose
Authentication	Authentication, Authorization	User identity verification and access control
Session Management	Sessions, Cookies, JSESSIONID	Maintaining user state in web applications
Token Security	JWT, Access Tokens, Refresh Tokens	Stateless authentication and API security
Identity Protocols	OAuth2, OIDC, SAML	Enterprise identity federation and authentication
Identity Management	SSO, MFA, Microsoft Entra ID	Identity governance and access management
API Security	API Authentication, API Gateway	Protecting APIs and microservices
Middleware Security	WebSphere LTPA, Sticky Sessions, Session Replication	Middleware authentication and high availability
Cloud Security	Conditional Access, Risk-Based Authentication	Cloud-native security controls
Zero Trust	ZTNA, SASE, Zero Trust Architecture	Identity-driven security model
Security Platforms	Zscaler, CyberArk, BeyondTrust	Enterprise security and PAM solutions
Monitoring	SIEM, Microsoft Sentinel, Splunk, QRadar	Security monitoring and threat detection
Middleware Platforms	WebSphere, JBoss, Tomcat	Enterprise application hosting platforms

---

---

---

🚀 Start Learning

New to Authentication and Identity Security? Start with:

👉 Part 1 - What is Authentication?

---

Author: Pradeep V
Blog: MiddlewareBox.com

🍪 Sessions, Cookies & JSESSIONID Explained - Part 2

• Welcome to Part 2 of the Authentication & Identity Security series.
• This article explains how applications remember users after successful login.
• Designed for Middleware, DevOps, Cloud, and Application Support Engineers.
• Includes enterprise examples using WebSphere, Tomcat, JBoss, IBM HTTP Server, NGINX, and Load Balancers.

---

Table of Contents

• Introduction
• What is a Session?
• How WebSphere, JBoss, Tomcat & Docker Store Session Data
• What is a Cookie?
• What is JSESSIONID?
• How Session Management Works
• Enterprise Example: WebSphere Session Flow
• Sessions Through Load Balancers
• Session vs Cookie vs JSESSIONID
• Session Security Best Practices
• Common Session Issues
• Key Takeaways
• What’s Next?

---

Introduction

In Part 1, we learned that authentication verifies a user's identity. After authentication is successful, the next important question is: how does the application remember the same user during future requests?

This is where Sessions, Cookies, and JSESSIONID come into the picture. These components help enterprise applications maintain user identity after login without asking the user to authenticate again on every page.

Key Concept:
Authentication verifies the user once, while session management maintains the user's identity throughout the application journey.

---

What is a Session?

A session is a server-side mechanism used to store user-specific information after successful authentication.

When a user logs in, the application server creates a unique session for that user. The session may store information such as:

• User ID
• User role
• Login time
• Application permissions
• User preferences

The session remains active until one of the following events occurs:

• User logs out
• Session timeout occurs
• Application server restarts
• Session is invalidated by the application

Middleware View:
In WebSphere, JBoss, and Tomcat, sessions are usually stored in application server memory unless session persistence or replication is configured.

---

How Do WebSphere, JBoss, Tomcat & Docker Store Session Data?

By default, Java application servers store session data in JVM heap memory. The browser only stores the session identifier (JSESSIONID), while the actual user session data remains on the application server.

Platform	Default Session Storage	High Availability Options
IBM WebSphere	JVM Heap Memory	Memory-to-Memory Replication, Database Persistence
JBoss EAP / WildFly	JVM Heap Memory	Session Replication, Infinispan Cache
Apache Tomcat	JVM Heap Memory	Session Persistence, Redis, Session Replication
Docker Containers	Inside Application JVM/Process	Redis, Database, Sticky Sessions, External Session Store

Docker Session Storage

Browser
   │
JSESSIONID
   │
Docker Container
   │
Tomcat / JBoss / WebSphere Liberty
   │
JVM Heap Memory

Docker itself does not manage user sessions. Sessions are managed by the application running inside the container.

If a container is restarted, redeployed, or scaled down, in-memory sessions may be lost unless external session storage is configured.

Docker Best Practice:
Use Redis, database persistence, sticky sessions, or JWT-based authentication for better scalability and resilience.

---

What is a Cookie?

A cookie is a small piece of data stored in the user's browser. Applications use cookies to identify users across multiple HTTP requests.

HTTP is stateless by default. This means every request is independent. Without cookies or tokens, the server cannot easily identify whether two requests are coming from the same user.

After successful login, the server sends a cookie to the browser.

Set-Cookie: JSESSIONID=ABC123XYZ789

For every next request, the browser automatically sends this cookie back to the server.

Cookie: JSESSIONID=ABC123XYZ789

---

What is JSESSIONID?

JSESSIONID is the default session identifier used by Java-based application servers.

It is commonly seen in applications running on:

• IBM WebSphere Application Server
• WebSphere Liberty
• Apache Tomcat
• JBoss EAP
• WildFly

JSESSIONID does not usually store the full user data. It acts as a reference ID that helps the application server locate the correct server-side session.

JSESSIONID=ABC123XYZ789

Important:
The actual session data is normally stored on the server side. The browser usually stores only the session identifier.

---

How Session Management Works

User
 │
 ▼
Login Page
 │
 ▼
Authentication Successful
 │
 ▼
Application Server Creates Session
 │
 ▼
JSESSIONID Generated
 │
 ▼
Cookie Sent To Browser
 │
 ▼
Browser Sends Cookie With Every Request
 │
 ▼
Application Server Retrieves Session
 │
 ▼
User Continues Application Access

This process allows the application to remember the authenticated user until logout or session timeout.

---

Enterprise Example: WebSphere Session Flow

Architecture

User Browser
      │
      ▼
IBM HTTP Server
      │
      ▼
WebSphere Application Server
      │
      ▼
Enterprise Application

Session Flow

1. User accesses the application login page.
2. User enters username and password.
3. WebSphere authenticates the user using LDAP or Active Directory.
4. WebSphere creates a session in application server memory.
5. WebSphere generates a JSESSIONID.
6. Browser receives the JSESSIONID as a cookie.
7. Browser sends the same cookie in every future request.
8. WebSphere uses JSESSIONID to locate the user's session.

Example HTTP Response

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; HttpOnly; Secure

Example HTTP Request

GET /app/dashboard HTTP/1.1
Host: www.company.com
Cookie: JSESSIONID=ABC123XYZ789

---

Sessions Through Load Balancers

In enterprise environments, applications often run on multiple servers behind a load balancer.

User Browser
      │
      ▼
NGINX / IBM HTTP Server / F5 / Azure Load Balancer
      │
      ▼
 ┌───────────────┬───────────────┐
 │ WebSphere-01  │ WebSphere-02  │
 └───────────────┴───────────────┘

If a user logs in through WebSphere-01 but the next request goes to WebSphere-02, the session may not be available on WebSphere-02 unless session replication or sticky session is configured.

Common Solutions

• Sticky Session: Route the same user to the same backend server.
• Session Replication: Copy session data across cluster members.
• External Session Store: Store sessions in Redis, database, or distributed cache.

Production Tip:
For stateful Java applications, session affinity is commonly configured at IBM HTTP Server, NGINX, F5, or application server plugin level.

---

Session vs Cookie vs JSESSIONID

Component	Purpose	Stored In	Example
Session	Stores user-specific data	Application Server	User ID, role, login time
Cookie	Stores small client-side data	Browser	JSESSIONID cookie
JSESSIONID	Identifies the server-side session	Browser cookie or URL	ABC123XYZ789

---

Session Security Best Practices

Session security is very important because attackers may try to steal or misuse session identifiers.

• Use Secure flag so cookies are sent only over HTTPS.
• Use HttpOnly flag to reduce JavaScript-based cookie theft.
• Use SameSite attribute to reduce CSRF risk.
• Regenerate session ID after successful login.
• Configure proper session timeout.
• Invalidate session during logout.
• Avoid exposing JSESSIONID in URLs.

Recommended Cookie Example

Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/; Secure; HttpOnly; SameSite=Lax

---

Common Session Issues

Middleware and DevOps teams commonly troubleshoot session-related issues in production environments.

Issue	Possible Cause
User logged out unexpectedly	Session timeout or server restart
Session lost after login	Cookie not stored or wrong cookie path
Intermittent logout in cluster	Sticky session or replication issue
JSESSIONID not visible	Application not creating session
Cookie not sent over HTTPS	Secure flag or domain/path mismatch
Login loop	SSO, cookie, or reverse proxy issue

---

Key Takeaways

• Authentication verifies identity.
• Sessions maintain user identity after login.
• Cookies store identifiers in the browser.
• JSESSIONID is the default session identifier for Java applications.
• Session affinity and replication are important in clustered environments.
• Cookie security flags such as Secure, HttpOnly, and SameSite improve session security.
• Session management is critical for WebSphere, JBoss, Tomcat, and enterprise applications.

---

What’s Next?

Next Article:
Part 3 – Stateful vs Stateless Applications

In the next article, we will understand the difference between stateful and stateless applications and why this concept is important for scaling enterprise applications, APIs, and cloud workloads.

---

Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com

---

🌐 WebSphere LTPA, Sticky Sessions & Session Replication Explained - Part 9

Welcome to Part 9 of the Authentication & Identity Security Series. This article explains LTPA (Lightweight Third-Party Authentication), JSESSIONID (Java Session Identifier), Sticky Sessions, Session Replication, and session handling in WebSphere, Tomcat, JBoss and Docker environments.

---

Table of Contents

• What is LTPA?
• How WebSphere Authentication Works
• LTPA vs JSESSIONID
• What are Sticky Sessions?
• Sticky Sessions vs Session Replication
• Session Replication in WebSphere
• Session Handling in Tomcat
• Session Handling in JBoss
• Docker Session Challenges
• Common Production Issues
• Interview Questions
• Best Practices

---

Common Terms Used in This Article

Abbreviation	Full Form
LTPA	Lightweight Third-Party Authentication
JSESSIONID	Java Session Identifier
IHS	IBM HTTP Server
WAS	WebSphere Application Server
JVM	Java Virtual Machine
HA	High Availability
DR	Disaster Recovery
SSL	Secure Sockets Layer

---

What is LTPA (Lightweight Third-Party Authentication)?

LTPA (Lightweight Third-Party Authentication) is IBM's authentication token mechanism used by WebSphere Application Server to provide authentication and Single Sign-On across applications.

User Login
    │
    ▼
WebSphere Authentication
    │
    ▼
LTPA Token Generated
    │
    ▼
Browser Stores LTPA Cookie
    │
    ▼
Future Requests Use LTPA Token

LTPA is mainly used for Authentication and Single Sign-On.

---

How WebSphere Authentication Works

User Browser
      │
      ▼
IBM HTTP Server (IHS)
      │
      ▼
WebSphere Application Server
      │
      ▼
LDAP / Microsoft Entra ID / AD
      │
      ▼
Authentication Success

After successful authentication, WebSphere generates an LTPA token and session information.

---

LTPA vs JSESSIONID

Feature	LTPA	JSESSIONID
Purpose	Authentication	Session Tracking
Used For	SSO	User Session
Generated After	Login	Session Creation
WebSphere Specific	Yes	No

LTPA identifies who the user is, while JSESSIONID identifies the user's application session.

---

What are Sticky Sessions?

Sticky Session (Session Affinity) ensures that a user continues to connect to the same application server node.

Load Balancer
      │
      ├── JVM1  ← User Always Routed Here
      │
      └── JVM2

Advantages

• Simple configuration
• Better performance
• No replication overhead

Disadvantages

• If JVM crashes, user session may be lost
• Not ideal for HA environments

---

Sticky Sessions vs Session Replication

Feature	Sticky Session	Session Replication
Performance	High	Medium
Failover Support	Limited	Excellent
Complexity	Low	High
HA Support	Partial	Strong

---

Session Replication in WebSphere

Memory-to-Memory Replication

JVM1
 ↔
JVM2

Database Session Persistence

JVM1
 │
 ▼
Session Database
 │
 ▼
JVM2

If JVM1 fails, JVM2 can continue serving requests using replicated session data.

---

Session Handling in Apache Tomcat

Browser
   │
JSESSIONID
   │
Tomcat JVM

Tomcat supports clustering using DeltaManager and BackupManager. External session stores such as Redis are commonly used.

---

Session Handling in JBoss EAP

Browser
   │
JSESSIONID
   │
JBoss Cluster

JBoss commonly uses Infinispan for distributed session replication.

---

Docker Session Challenges

User
 │
 ▼
Docker Container
 │
 ▼
Tomcat / JBoss / Liberty

If a container restarts, in-memory sessions can be lost.

Recommended Solutions

• JWT (JSON Web Token)
• Redis Session Store
• Database Session Store
• External Session Cache

---

Common Production Issues

Issue	Cause
Random Logout	Session Timeout
SSO Failure	LTPA Key Mismatch
Session Lost After Restart	In-Memory Session Storage
User Routed To Wrong Node	Load Balancer Affinity Issue
Session Replication Failure	Cluster Misconfiguration

---

Interview Question

What is the difference between LTPA and JSESSIONID?

LTPA (Lightweight Third-Party Authentication) is used for authentication and Single Sign-On, whereas JSESSIONID (Java Session Identifier) is used for session tracking and maintaining user state.

---

Best Practices

• Use sticky sessions only when failover is not critical.
• Enable session replication for HA applications.
• Synchronize LTPA keys across WebSphere cells.
• Use Redis or database-backed sessions in containers.
• Monitor session count and JVM memory usage.
• Configure proper session timeout values.
• Test failover regularly.

---

Key Takeaways

• LTPA provides WebSphere authentication and SSO.
• JSESSIONID tracks user sessions.
• Sticky sessions improve performance.
• Session replication improves availability.
• Docker requires external session management for HA.

---

What's Next?

Part 10 – Zero Trust Security & Authentication Risks

---

Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog: MiddlewareBox.com