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

📌WebSphere Outbound SSL & SNI – Troubleshooting Guide

• ERROR : javax.net.ssl.SSLHandshakeException: No name matching found.
• This guide helps you diagnose and fix WebSphere outbound HTTPS failures when the target requires SNI.
• You'll get exact OpenSSL checks, JVM flags, and a support matrix.

---

WebSphere Outbound SSL & SNI – Troubleshooting Guide

📑 Table of Contents

• What is SNI?
• Why SNI matters in WebSphere
• Common error patterns
• Confirming an SNI issue (OpenSSL)
• SNI support matrix (WebSphere/Java)
• How to enable SNI in WebSphere
• Best practices checklist
• FAQ (quick answers)

---

🔎 What is SNI?

• Server Name Indication (SNI) is a TLS extension
• Client includes the target hostname in the ClientHello message
• Allows servers to present the correct certificate when multiple virtual hosts share the same IP address

Without SNI you often receive a default certificate → CN/SAN mismatch → hostname validation fails even if the trust chain is fine.

🎯 Why SNI matters in WebSphere

• Outbound calls from WebSphere to cloud APIs, SaaS, and WAF/CDN fronted apps often terminate on shared VIPs
• Older or non-default Java settings may not send SNI (Server Name Indication).
• Without SNI, the remote server sends a default certificate.
• Your client fails with hostname mismatch error.

---

🚨 Common error patterns

javax.net.ssl.SSLHandshakeException: No name matching <api.company.com> found
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
PKIX path building failed: unable to find valid certification path to requested target
CWPKI0022E: SSL HANDSHAKE FAILURE
GSK_ERROR_BAD_CERT

---

🧪 Confirming an SNI issue (OpenSSL)

Compare results with and without SNI from the WebSphere host:

# Baseline ( May still send SNI implicitly)
openssl s_client -connect api.company.com:443 -showcerts

# Force SNI (ClientHello includes hostname)
openssl s_client -connect api.company.com:443 -servername api.company.com -showcerts

💬 Interpretation

If CN/SAN only matches when -servername is used, the endpoint requires SNI and your client must send it.

---

⚙️ How to enable SNI in WebSphere

Add this JVM system property to the server's Generic JVM Arguments:

-Djsse.enableSNIExtension=true

Console path: Servers → Server Types → WebSphere application servers → <server> → Java and Process Management → Process Definition → Java Virtual Machine → Generic JVM Arguments

Save, synchronize nodes, restart the JVM.

---

Optional: align TLS baseline

-Dhttps.protocols=TLSv1.2

---

🧭 Best practices checklist

• Verify CN/SAN with openssl s_client -servername before go-live or on UAT
• Standardize JVM args across environments; document SNI-dependent endpoints.
• Keep Java 8+; enforce TLS1.2+ to match common provider baselines.

---

❓ FAQ

Question	Answer
What is SNI and why does it matter?	SNI makes the server present the right certificate on shared IPs. Without it, you'll likely hit hostname mismatch in WebSphere even if trust is correct.
How do I enable SNI?	Add -Djsse.enableSNIExtension=true to Generic JVM Arguments, then save, sync, and restart.
Which versions support SNI?	WAS 8.5.5.x (Java 8) and WAS 9.x (Java 8/11) support SNI; WAS 7.x doesn't; WAS 8.0.x is partial/inconsistent.
How do I confirm an SNI issue?	Compare openssl s_client with/without -servername. If only the SNI run shows the correct CN/SAN, you need SNI.

🎯Shell Scripting for Beginners – Part 10: Middleware Health Monitoring Project (Mixed Example).

• This is our final, beginner-friendly project 🎯 — where we'll combine everything you've learned: variables, if-else, loops, functions, logging, and cron automation.
• Let's create a simple Middleware Health Monitoring script that checks Tomcat, Jenkins, Docker, MySQL, and SSL expiry.

---

📑 Table of Contents

• 1️⃣ Overview
• 2️⃣ Full Simple Script
• 3️⃣ Example Output
• 4️⃣ Automate the Script

---

1️⃣ Overview

This script uses:

• Variables – store names, logs, and domains.
• Functions – reusable checks for each service.
• If-Else – to decide if a service needs restart.
• For loop – to check multiple Docker containers.
• While loop – to retry connection.
• Logs – write output to a file.

---

2️⃣ Full Middleware Health Monitoring Script

#!/bin/bash
# MiddlewareBox - Simple Health Monitor

LOG="/var/log/middleware_health.log"
domain="middlewarebox.com"
echo "===== Middleware Health Check =====" >> $LOG
date >> $LOG

# --- Function to check Tomcat ---
check_tomcat() {
  echo "Checking Tomcat..."
  if pgrep -f "org.apache.catalina.startup.Bootstrap" > /dev/null; then
     echo "✅ Tomcat is running" | tee -a $LOG
  else
     echo "🚨 Tomcat is down, restarting..." | tee -a $LOG
     /opt/tomcat/bin/startup.sh
     echo "✅ Tomcat restarted" | tee -a $LOG
  fi
}

# --- Function to check Jenkins ---
check_jenkins() {
  echo "Checking Jenkins..."
  if systemctl is-active --quiet jenkins; then
     echo "✅ Jenkins is active" | tee -a $LOG
  else
     echo "🚨 Jenkins not running, restarting..." | tee -a $LOG
     systemctl restart jenkins
     echo "✅ Jenkins restarted" | tee -a $LOG
  fi
}

# --- Function to check MySQL ---
check_db() {
  echo "Checking MySQL..."
  if mysql -u root -pSecret -e "show databases;" > /dev/null 2>&1; then
     echo "✅ MySQL connection successful" | tee -a $LOG
  else
     echo "🚨 MySQL connection failed" | tee -a $LOG
     echo "Retrying in 5 seconds..."
     sleep 5
     mysql -u root -pSecret -e "show databases;" && echo "✅ MySQL reconnected" | tee -a $LOG
  fi
}

# --- Check Docker Containers using FOR Loop ---
check_docker() {
  echo "Checking Docker containers..."
  for c in nginx webapp db
  do
    status=$(docker inspect -f '{{.State.Status}}' $c 2>/dev/null)
    if [ "$status" != "running" ]; then
      echo "🚨 Container $c is $status, restarting..." | tee -a $LOG
      docker start $c
    else
      echo "✅ Container $c is running" | tee -a $LOG
    fi
  done
}

# --- Check SSL certificate expiry ---
check_ssl() {
  echo "Checking SSL expiry..."
  expiry=$(echo | openssl s_client -servername $domain -connect $domain:443 2>/dev/null | openssl x509 -noout -dates | grep notAfter | cut -d= -f2)
  days_left=$(( ($(date -d "$expiry" +%s) - $(date +%s)) / 86400 ))
  if [ $days_left -le 15 ]; then
    echo "⚠️ SSL expires in $days_left days!" | tee -a $LOG
  else
    echo "✅ SSL valid for $days_left days" | tee -a $LOG
  fi
}

# --- MAIN EXECUTION FLOW ---
check_tomcat
check_jenkins
check_db
check_docker
check_ssl

echo "✅ Health check completed successfully!" | tee -a $LOG
echo "========================================" >> $LOG

💬 Example Output:

✅ Tomcat is running
✅ Jenkins is active
✅ MySQL connection successful
✅ Container nginx is running
✅ SSL valid for 70 days
✅ Health check completed successfully!

---

3️⃣ Automate the Script

# Run every 30 minutes
*/30 * * * * /opt/scripts/middleware_health.sh >> /var/log/health_cron.log 2>&1

# Run automatically on system reboot
@reboot /opt/scripts/middleware_health.sh >> /var/log/boot_health.log 2>&1

💬 Output (Cron log):

[BOOT] Health check executed
✅ All services healthy

---

🏁 Summary

• ✅ Combined all major shell scripting concepts.
• ✅ Checks Tomcat, Jenkins, Docker, MySQL, and SSL in one file.
• ✅ Uses if, for, functions, and basic while retry logic.
• ✅ Can run manually or via cron / reboot automation.

← Previous: Part 9 – Scheduling & Automation Next: Part 11 – Log Management & Rotation →

TLS / SSL Certificate Lifetimes Reduced to 47 Days.

SSL Certificate Validation till 47 Days.

• The CA/Browser Forum has finalized a proposal that will change the TLS certificate landscape forever. 

• Starting in 2026 and fully enforced by 2029, public TLS / SSL certificates will have a maximum lifetime of just 47 days. 

• This major change will significantly impact how Middleware and Infrastructure teams manage web server security, certificate renewal processes, and application availability.

TLS / SSL Certificate Validity Reduction Timeline

Effective Date	Max Certificate Validity	Domain Validation Reuse
Until Mar 15, 2026	398 days	398 days
Mar 15, 2026	200 days	200 days
Mar 15, 2027	100 days	100 days
Mar 15, 2029	47 days	10 days

🕒 Effective Date

The date on which the new TLS certificate rules take effect. 

Starting from that date, the updated validity and validation rules must be followed.

📅 Max Certificate Validity

This is the maximum number of days a TLS certificate will remain valid. 

After this period, the certificate must be renewed or replaced.

🌐 Domain Validation Reuse

This is the number of days you can reuse domain validation (proving you own the domain). 

After this, you’ll need to re-validate the domain again for new certificates.

Impact on Middleware and Infrastructure Teams (OnPrem / Cloud)

• Shorter certificate lifetimes mean Middleware and Infrastructure engineers must shift from traditional, manual certificate management to more automated, robust, and monitored systems. 
• The focus must be on securing critical web frontends, load balancers, and backend integrations that rely on TLS encryption.

Web Server and Certificate Management Summary:-

Web Server	Certificate Format	Automation Support	Middleware Challenge
Apache HTTP Server	.crt, .key (PEM)	Yes (Certbot)	Reload needed post-renewal
NGINX	.crt, .key (PEM)	Yes (Certbot + plugins)	Restart/reload required on renewal
IBM HTTP Server (IHS)	.kdb, .sth (CMS format)	Manual or scripted	No ACME support, import via gskcapicmd required

SSL Certificate Automation means,  ACME (Automatic Certificate Management Environment).

 

It is a protocol developed by the Internet Security Research Group (ISRG) — the same organization behind Let’s Encrypt.

ACME is designed to automate the entire lifecycle of TLS/SSL certificates, including:

• Issuing new certificates.

• Renewing certificates before they expire.

• Validating domain ownership.

• Downloading and installing certificates.

Conclusion:-

• By 2029, TLS certificates will expire in just 47 days.
• Automate certificate issuance and renewal using ACME ( Using Certbot)
• Use monitoring tools to avoid expiry. (Using Openssl command from bash / .bat script to trigger alert)

Reference Link :

• https://www.thesslstore.com

• https://www.digicert.com

• https://www.cyberark.com/what-is/acme-protocol/