Devops | Toolbox Guides & Articles

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

SSL / X.509 Certificate Inspector

Paste a PEM certificate or load a DER file to read every field and extension locally. Internal hostnames in SAN entries stay on your machine.

Open Certificate Inspector →

What a Certificate Actually Asserts

A TLS certificate makes one claim: this public key belongs to these names, and a certificate authority is willing to sign that statement until this date. Everything else — the fields, the extensions, the chain — exists to make that claim verifiable by a client that has never seen your server before.

X.509 is defined by RFC 5280 for the internet PKI profile, with additional rules imposed by the CA/Browser Forum Baseline Requirements, which browsers enforce. When the RFC and the Baseline Requirements disagree, browsers follow the Baseline Requirements — which is precisely why Common Name matching is dead in practice while still present in the RFC’s data model.

What you get from this guide: the ability to read a certificate dump line by line, diagnose the four errors that account for most TLS incidents, and plan renewal automation against the shortening lifetime schedule.

The Three-Part Structure

Certificate ::= SEQUENCE {
 tbsCertificate TBSCertificate, -- everything that is signed
 signatureAlgorithm AlgorithmIdentifier,
 signatureValue BIT STRING -- the CA's signature over tbsCertificate
}

The CA signs the DER encoding of tbsCertificate. Change one byte of a name, a date, or an extension and the signature no longer verifies — which is why certificates cannot be edited, only reissued.

Inside `tbsCertificate`

Field	Meaning	What to check
`version`	1, 2, or 3 (`v3` = value `2`)	Anything but v3 is obsolete
`serialNumber`	CA-unique identifier	Must be ≥ 64 bits of CSPRNG entropy per Baseline Requirements
`signature`	Algorithm the CA used	`sha256WithRSAEncryption` or `ecdsa-with-SHA256`; SHA-1 signatures are rejected
`issuer`	Distinguished Name of the CA	Must match the intermediate’s `subject` exactly
`validity`	`notBefore` / `notAfter`	Times are UTC; `UTCTime` before 2050, `GeneralizedTime` after
`subject`	Distinguished Name of the holder	Informational for TLS host matching
`subjectPublicKeyInfo`	Algorithm + public key	Same SPKI structure as a
`extensions`	v3 extension list	Where all the operational meaning lives

The v3 Extensions That Decide Everything

Extension	Critical?	Role
subjectAltName (SAN)	No	The list of names the certificate covers: `DNS`, `IP`, `email`, `URI`
basicConstraints	Yes	`CA:TRUE` marks a CA certificate; `pathLenConstraint` caps chain depth
keyUsage	Yes	`digitalSignature`, `keyEncipherment`, `keyCertSign` …
extendedKeyUsage (EKU)	Often	`serverAuth`, `clientAuth`, `codeSigning` — a `serverAuth`-only cert cannot authenticate a client
authorityInfoAccess (AIA)	No	URLs for the issuer certificate and the OCSP responder
cRLDistributionPoints	No	Where to fetch the CRL
subjectKeyIdentifier / authorityKeyIdentifier	No	Hints that let a verifier pick the right issuer quickly
signedCertificateTimestamp (SCT)	No	Certificate Transparency proofs; Chrome requires them for public trust

Common Name is not identity

CN=example.com inside the subject DN is a legacy artefact. RFC 6125 deprecated CN-based host matching, and the Baseline Requirements require every covered DNS name to be present in SAN. Modern browsers validate against SAN entries only.

X509v3 Subject Alternative Name:
 DNS:example.com, DNS:www.example.com, DNS:*.api.example.com

Wildcard rules that surprise people:

*.example.com matches api.example.com but not example.com itself, and not a.b.example.com. One label, one level.
The wildcard must be the leftmost label. api.*.example.com is invalid.
A certificate for both apex and subdomains needs both example.com and *.example.com in SAN.

How Chain Validation Works

A client performs path construction followed by path validation (RFC 5280 § 6):

Start at the leaf. Read its issuer DN.
Find a candidate issuer whose subject DN matches, from the certificates the server sent or from the local trust store; authorityKeyIdentifier disambiguates when several match.
Verify the signature on the child using the candidate’s public key.
Check the candidate is allowed to be a CA: basicConstraints must say CA:TRUE, keyUsage must include keyCertSign, and pathLenConstraint must not be exceeded.
Repeat until reaching a certificate present in the trust store.
Then validate the leaf’s own properties: current time inside the validity window, hostname against SAN, EKU includes serverAuth, and revocation status.

[ leaf: example.com ] --issued by--> [ intermediate CA ] --issued by--> [ root CA ]
 sent by server sent by server in OS/browser trust store

The server’s job: send the leaf and every intermediate, leaf first. Do not send the root. A client that already trusts the root ignores your copy; a client that does not trust it will not start trusting it because you attached it.

# Show the chain a server actually presents
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Verify a local chain offline
openssl verify -untrusted intermediate.pem leaf.pem

Revocation: OCSP, CRL, and What Browsers Really Do

Revocation is the weakest link in web PKI. Three mechanisms coexist:

Mechanism	How it works	Reality
CRL	Client downloads a signed list of revoked serials	Large files; poor latency; browsers largely stopped live checks
OCSP	Client queries the responder for one serial	Privacy leak (the CA learns browsing) and a soft-fail on timeout
OCSP stapling	The server fetches a signed OCSP response and attaches it in the handshake	The deployable answer; enable it
Pushed lists	Browser ships aggregated revocation data it compiled	What major browsers increasingly rely on in practice

The structural weakness is soft-fail: if a client cannot reach the responder, it proceeds rather than break the site — so an attacker who can block the OCSP query can also suppress a revocation. This is a large part of why the industry chose to shrink certificate lifetimes instead: a 47-day certificate limits the damage window without depending on revocation working at all.

The Shrinking Lifetime Schedule

CA/Browser Forum ballot SC-081v3, approved in April 2025, sets a phased reduction in the maximum validity of publicly trusted TLS certificates:

Effective date	Maximum validity
Before 15 March 2026	398 days
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

Many CAs issue at 199 days to stay clear of the boundary. Domain validation data reuse periods shrink on a parallel schedule.

Operational consequences to plan for now:

Automate with ACME. At 47 days, renewal must be a cron-grade process. Manual calendar reminders will fail.
Instrument expiry, don’t trust it. Alert at 30 days and 7 days remaining, measured from the live certificate the server presents — not from your issuance records.
Audit the non-web endpoints. Load balancers, mail gateways, API gateways, mutual-TLS clients, and appliances with hand-uploaded certificates are where 47-day renewal breaks first.
Keep intermediates fresh. A stale pinned intermediate bundle survives a 398-day cadence and fails under a 47-day one.

The Four Errors Worth Recognising Instantly

Symptom	Root cause	Fix
`NET::ERR_CERT_COMMON_NAME_INVALID`	Hostname absent from SAN	Reissue with the name in SAN; CN alone is ignored
`unable to get local issuer certificate`	Intermediate not served	Append the intermediate to the chain file, leaf first
`NET::ERR_CERT_DATE_INVALID`	Expired, or server clock wrong	Renew; also verify NTP on the server
`NET::ERR_CERT_AUTHORITY_INVALID`	Self-signed or private CA not trusted	Install the root in the client trust store, or use a public CA

A fast triage rule: if openssl verify -untrusted succeeds locally but browsers fail, the certificate is fine and the server chain configuration is wrong.

Step-by-Step: Auditing a Certificate with Toolbox

Obtain the certificate: export it from your CA dashboard, or capture it live with openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509.
Open the tool: visit the and paste the PEM block or load the DER file.
Read the SAN list first — this is what browsers match. Confirm every hostname you serve is present, including the apex if you serve it.
Check notAfter against the current lifetime cap. Under the 200-day regime, a certificate issued with a longer window is a red flag about the issuance path.
Confirm key and signature strength: RSA ≥ 2048 bits or an approved curve, and a SHA-256-or-better signature algorithm.
Verify the chain separately, since a single certificate cannot prove its own path: openssl verify -untrusted intermediate.pem leaf.pem.

Outcome: you can tell within a minute whether an incident is a naming problem, a chain problem, an expiry problem, or a trust-store problem — and you inspect internal hostnames without publishing them to a third-party service.

Related guides: · ·

FAQ

Frequently Asked Questions

Why do browsers ignore the Common Name in a certificate? ▼

RFC 6125 deprecated Common Name matching for host identity, and the CA/Browser Forum Baseline Requirements require every covered DNS name to appear in the Subject Alternative Name extension. Chrome, Firefox, and Safari match hostnames against SAN entries only, so a certificate carrying the hostname only in CN fails with a name mismatch.

What is the difference between a certificate chain and a certificate bundle? ▼

A chain is the ordered path from the leaf through intermediates to a root the client already trusts; a bundle is the file holding them. Servers must send the leaf plus all intermediates in order and should omit the root. Missing intermediates cause a site to work in one client and fail in another, because some clients can fetch the issuer via Authority Information Access while others cannot.

How long can a TLS certificate be valid in 2026? ▼

Under CA/Browser Forum ballot SC-081v3, the maximum validity for publicly trusted TLS certificates fell from 398 days to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and to 47 days on 15 March 2029. Many CAs issue at 199 days to avoid boundary rejections, which makes ACME automation mandatory rather than optional.

Can I inspect a certificate safely without uploading it anywhere? ▼

Yes. A server certificate holds only public data, but internal hostnames and staging names in SAN entries are useful reconnaissance for an attacker. A client-side inspector parses the ASN.1 DER structure in browser memory, so nothing is transmitted, logged, or retained elsewhere.

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

Sat, 05 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

Cron Schedule Builder

Build, parse, and validate cron schedules with instant human-readable English descriptions and live execution timeline preview.

Open Cron Builder & Schedule Tester →

What Is Cron and Why Does Syntax Precision Matter?

Derived from the Greek word Chronos (time), cron is the universal time-based job scheduler found in Unix-like operating systems, cloud task runners (AWS EventBridge, Google Cloud Scheduler), and backend background queues (Celery, BullMQ, Sidekiq).

A misconfigured cron expression in production can lead to severe consequences:

Database backup scripts running every minute instead of every night at midnight, causing CPU exhaustion.
Billing webhooks executing twice during a Daylight Saving Time autumn rollback.
Data retention cleanups failing to execute because of contradictory day-of-month and day-of-week constraints.

Understanding the underlying grammar of cron expressions enables engineers to write deterministic, resilient background job schedules.

The 5-Field UNIX Cron Anatomy

Standard POSIX / Vixie cron expressions are composed of five distinct fields separated by white space:

 ┌───────────── Minute (0 - 59)
 │ ┌───────────── Hour (0 - 23, 24-hour clock)
 │ │ ┌───────────── Day of the Month (1 - 31)
 │ │ │ ┌───────────── Month of the Year (1 - 12 or JAN - DEC)
 │ │ │ │ ┌───────────── Day of the Week (0 - 6 or SUN - SAT)
 │ │ │ │ │
 * * * * *

Detailed Field Range Specifications

Field Position	Field Name	Allowed Values	Allowed Special Characters
1	Minute	`0 - 59`	`*` `,` `-` `/`
2	Hour	`0 - 23`	`*` `,` `-` `/`
3	Day of Month	`1 - 31`	`*` `,` `-` `/`
4	Month	`1 - 12` or `JAN - DEC`	`*` `,` `-` `/`
5	Day of Week	`0 - 6` (0 = Sunday, 6 = Saturday)	`*` `,` `-` `/`

Note on Sunday representation: In many modern implementations (including Vixie Cron, crontab on Ubuntu, and macOS), both 0 and 7 are accepted as Sunday for usability.

Special Operators Explained

Cron expressions derive their expressive power from five core syntax operators:

1. Asterisk (`*`) — The Wildcard

Matches every valid unit within the field’s permissible range.

* * * * *: Runs at the beginning of every minute of every hour, day, and month.
0 * * * *: Runs at minute 0 of every hour (i.e. once every hour on the hour).

2. Comma (`,`) — Value Lists

Defines an explicit enumeration of discrete values.

0 9,12,18 * * *: Triggers at 9:00 AM, 12:00 PM, and 6:00 PM every day.
0 0 * * 1,3,5: Runs at midnight on Mondays, Wednesdays, and Fridays.

3. Hyphen (`-`) — Value Ranges

Specifies a continuous, inclusive interval between two bounds.

0 9-17 * * *: Runs at minute 0 of every hour between 9:00 AM and 5:00 PM inclusive.
0 0 1-7 * *: Runs at midnight on the first seven days of every month.

4. Slash (`/`) — Step Values

Specifies step increments through a range. When preceded by an asterisk (*/n), it means “every n units starting from the minimum bound”.

*/15 * * * *: Runs at minutes 0, 15, 30, and 45 of every hour.
0 0/2 * * *: Runs every 2 hours (00:00, 02:00, 04:00, 06:00, …).
10-50/10 * * * *: Runs between minutes 10 and 50 in 10-minute steps (10, 20, 30, 40, 50).

5-Field Standard vs 6-Field Extended (Quartz / AWS)

While POSIX systems use the 5-field format, several popular enterprise engines (Java Quartz Scheduler, AWS CloudWatch / EventBridge, Spring Framework @Scheduled) utilize 6-field or 7-field formats:

Architecture Dimension	5-Field UNIX (POSIX / crontab)	6-Field Quartz / AWS EventBridge
Seconds Precision	❌ No (Minute is lowest granularity)	✅ Yes (Field 1 is Seconds `0-59`)
Year Specification	❌ Not supported	✅ Supported as optional 7th field (`1970-2099`)
Question Mark (`?`) Operator	❌ Throws syntax error	✅ Mandatory when specifying Day of Month or Week
`L` (Last) and `W` (Weekday)	❌ Rarely supported	✅ Fully supported (`L` = last day, `15W` = nearest weekday)
Primary Platforms	Linux `crontab`, Node.js `node-cron`, Python `Celery`	AWS EventBridge, Spring Boot, Quartz Java, Kubernetes CronJobs

Example: Quartz / AWS Syntax

In AWS EventBridge, a schedule running at 10:15 AM every weekday requires 6 fields and the ? character:

cron(0 15 10 ? * MON-FRI *)

10 Common Production Cron Recipes

Here are production-tested recipes ready to deploy for common infrastructure patterns:

Operational Objective	Standard Cron Expression	English Meaning
Health Check Heartbeat	`/5 * * *`	Every 5 minutes
Hourly Log Rotation	`0 * * * *`	Once an hour on the hour (:00)
Nightly Database Backup	`0 2 * * *`	Every day at 02:00 AM
Weekday Business Hours Task	`0 9 * * 1-5`	Monday through Friday at 09:00 AM
Weekly Maintenance Window	`0 3 * * 0`	Every Sunday at 03:00 AM
Monthly Invoice Generation	`0 0 1 * *`	1st of every month at midnight (00:00)
Quarterly Audit Report	`0 0 1 1,4,7,10 *`	1st of Jan, Apr, Jul, Oct at midnight
Twice-Daily Cache Warmup	`0 6,18 * * *`	Every day at 06:00 AM and 06:00 PM
End of Month Reconciliation	`0 23 28-31 * *`	Nightly from 28th-31st (pair with bash check)
Yearly Archival	`0 0 1 1 *`	January 1st at midnight

Critical Pitfalls & Production Best Practices

1. The Daylight Saving Time (DST) Trap

When a server is configured to a local timezone observing Daylight Saving Time:

Spring Forward (+1 hr): At 2:00 AM, the clock jumps directly to 3:00 AM. Any job scheduled for 0 2 * * * is completely skipped.
Fall Back (-1 hr): At 2:00 AM, the clock rewinds to 1:00 AM. Any job scheduled between 1:00 AM and 2:00 AM runs twice.

Solution: Always set the system timezone of worker servers and container clusters to UTC (tzdata: Etc/UTC).

2. The “Thundering Herd” Problem

If 50 different microservices schedule heavy batch jobs at exactly 0 0 * * * (midnight), database IOPS and CPU utilization will spike dramatically.

Solution: Stagger cron schedules with jitter. Run service A at 17 2 * * *, service B at 34 2 * * *, and service C at 49 2 * * *.

3. Day of Month AND Day of Week Interaction

In POSIX cron, if you specify both:

0 0 15 * 1

The job does not execute only when the 15th happens to be a Monday. It executes whenever the day is the 15th OR whenever the day is a Monday.

Step-by-Step: Generating Cron Schedules with Toolbox

Open the Tool: Visit the .
Select Frequency: Use the interactive visual controls to choose between Minute, Hourly, Daily, Weekly, Monthly, or Custom intervals.
Inspect Real-Time Translation: The engine instantly renders a plain-English translation of your schedule (e.g. “At 02:30 AM on day 1 of the month”).
Preview Next 5 Execution Dates: Verify the exact upcoming UTC and local timestamps to ensure no scheduling surprises occur.
Copy Expression: Click Copy Expression to paste the POSIX-compliant string directly into your crontab, Dockerfile, or infrastructure code.

Interactive Workbench LIVE

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

Open Fullscreen ↗

Build, parse, and validate cron schedules with instant human-readable English descriptions and live execution timeline preview.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

What is the standard order of fields in a 5-field cron expression? ▼

The 5 standard UNIX cron fields from left to right are: 1. Minute (0-59), 2. Hour (0-23), 3. Day of the Month (1-31), 4. Month of the Year (1-12 or JAN-DEC), and 5. Day of the Week (0-6 or SUN-SAT, where 0 and 7 usually represent Sunday).

What is the difference between * and */5 in cron syntax? ▼

An asterisk (*) matches every possible value in that field (e.g. * in the minute field means run every minute). A step value with a slash (*/5) matches every nth interval starting from the field's minimum (e.g. */5 in the minute field triggers at minutes 0, 5, 10, 15, ..., 55).

How does Daylight Saving Time (DST) affect scheduled cron jobs? ▼

If your server timezone observes DST, schedules running during the transition hour can either be skipped entirely (when clocks spring forward by 1 hour) or execute twice (when clocks fall back by 1 hour). For mission-critical background jobs and batch billing, servers and cron schedulers should always be configured to UTC.

Can I specify both Day of Month and Day of Week simultaneously? ▼

In standard UNIX cron (Vixie Cron), specifying non-wildcard values in both the Day of Month and Day of Week fields creates an OR condition rather than an AND condition. The job triggers whenever EITHER condition matches. In Quartz/AWS cron, one of these fields must be set to '?' to avoid ambiguous scheduling.

Devops | Toolbox Guides & Articles

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

X.509 Certificate Anatomy: SAN, Chain Validation, and the 200-Day Lifetime Era

SSL / X.509 Certificate Inspector

What a Certificate Actually Asserts

The Three-Part Structure

Inside tbsCertificate

The v3 Extensions That Decide Everything

Common Name is not identity

How Chain Validation Works

Revocation: OCSP, CRL, and What Browsers Really Do

The Shrinking Lifetime Schedule

The Four Errors Worth Recognising Instantly

Step-by-Step: Auditing a Certificate with Toolbox

Frequently Asked Questions

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

Cron Schedule Builder

What Is Cron and Why Does Syntax Precision Matter?

The 5-Field UNIX Cron Anatomy

Detailed Field Range Specifications

Special Operators Explained

1. Asterisk (*) — The Wildcard

2. Comma (,) — Value Lists

3. Hyphen (-) — Value Ranges

4. Slash (/) — Step Values

5-Field Standard vs 6-Field Extended (Quartz / AWS)

Example: Quartz / AWS Syntax

10 Common Production Cron Recipes

Critical Pitfalls & Production Best Practices

1. The Daylight Saving Time (DST) Trap

2. The “Thundering Herd” Problem

3. Day of Month AND Day of Week Interaction

Step-by-Step: Generating Cron Schedules with Toolbox

Cron Syntax & Expression Architecture: The Complete Guide to Scheduling Jobs

Frequently Asked Questions

Inside `tbsCertificate`

1. Asterisk (`*`) — The Wildcard

2. Comma (`,`) — Value Lists

3. Hyphen (`-`) — Value Ranges

4. Slash (`/`) — Step Values