From us: With this article, we begin a new series of publications on our website: HEXSSL Insight. These will be extensive articles containing our expertise supported by numerous examples from our own experience. We hope that the information contained in these articles will help you better understand all aspects related to broadly defined online security.

Every secure HTTPS session begins with one fundamental question: can I trust the website I am connecting to?
The answer doesn’t depend solely on encryption – the key factor is who has verified the identity of the server.
This mechanism forms the core of the PKI (Public Key Infrastructure), which builds and maintains the global SSL/TLS trust chain.

In practice, a browser trusts websites not because a server has a certificate, but because that certificate has been signed by a Certification Authority (CA) included in its trusted store.
If the browser or operating system knows and trusts a particular root CA, and that root has directly or indirectly confirmed the authenticity of the server’s certificate, the connection is considered secure.

This mechanism guarantees three things:

1. Authentication – the website is truly who it claims to be.
2. Integrity – the data has not been altered during transmission.
3. Confidentiality – the data is encrypted and unreadable to third parties.

Only after these conditions are met does the browser display the padlock symbol 🔒.
It’s important to remember that encryption alone (HTTPS) without trust does not mean security — a server can use a self-signed certificate that no trusted entity has verified.

Trust architecture – the foundation of the PKI system.

Public Key Infrastructure is a distributed system of entities, rules, and cryptographic mechanisms that enable mutual identity verification.
Its structure can be presented in three layers:

• Root CA – a top-level, self-signed certificate that serves as the source of trust.
• Intermediate CA – subordinate authorities that issue end-entity certificates on behalf of the root.
• End-Entity (Leaf) – final certificates installed on web servers, mail systems, or applications.

Each certificate in the chain contains a digital signature — a hash of its contents encrypted with the issuer’s private key.
The browser verifies this signature using the public key from the parent certificate.
This process continues until the root is reached — the self-signed certificate stored locally in the system or browser.

How does the trust chain form?

1. The Root CA issues an intermediate certificate (Intermediate CA).
2. The Intermediate CA signs the end-entity certificate (e.g., for the domain hexssl.pl).
3. The server presents both its certificate and the intermediate chain to the browser.
4. The browser connects all the links, matching them to a trusted root in its local store.

If any link in the chain is invalid (e.g., missing intermediate or incorrect signature), the connection will be rejected.

Why a hierarchical model?

The hierarchical PKI structure ensures both control and resilience.
Root CAs are physically isolated, often stored in specialized HSM modules and only activated when issuing new intermediates.
This minimizes the risk of root key compromise.
If an intermediate CA is compromised, the root can revoke it without disrupting the entire ecosystem.

Key certificate parameters.

Each certificate includes fields such as:

• Subject CN/SAN – the identity of the domain or organization.
• Issuer – the issuing authority (parent certificate).
• Serial Number – a unique identifier.
• Signature Algorithm – the signature algorithm (e.g., sha256RSA).
• Validity – the validity period.
• Key Usage/Extended Key Usage – permitted uses (server, client, code signing, etc.).

Administrators can view these fields locally:

openssl x509 -in cert.pem -noout -text

This allows easy inspection of the Issuer, algorithm, validity period, and signature chain.

Root CA – the heart of the trust system.

The Root CA is the top of the PKI hierarchy — the “source of truth” from which everything begins.
It is a self-signed certificate that has no superior issuer.
Its public key is embedded in the operating system or browser as part of the trusted certificate store.

Root CA lifecycle.

Root CAs typically have long lifespans — 20 to 30 years.
During this time, they issue several generations of intermediates.
Their private keys are kept in isolated HSM modules, with physical access tightly controlled.
Because of the immense trust they hold, root CAs are rarely activated — often only once a year or two, during a formal ceremony to issue a new Intermediate CA.

Root Store programs.

Every major ecosystem maintains its own root program:

• Mozilla Root Program (Firefox, Thunderbird).
• Microsoft Trusted Root Program (Windows).
• Apple Root Store.
• Google Root Program (Chrome / Android).

A Root CA must meet strict requirements (operational security, WebTrust audit, CA/B Forum compliance) to be accepted.

Example: USERTrust RSA Root CA vs R46/E46.

In 2024–2025, many certificate providers (including Sectigo) began migrating from the historical USERTrust RSA Root CA to the new R46/E46 roots featuring longer keys and SHA-384 signatures.
For administrators, this means the old chain may be replaced by a new one, and outdated devices may experience validation errors.

To check which root your certificate uses:

openssl s_client -connect example.com:443 -showcerts

or use the HEXSSL SSL Checker tool, which automatically identifies the chain and its root anchor.

Intermediate CA – the layer of delegated trust.

The Intermediate CA acts as a bridge between the root and the end-entity certificates.
These authorities are the ones that actually sign certificates for websites, APIs, or mail servers.
This setup allows the root CA to remain offline, while the infrastructure can flexibly issue and renew certificates.

Why are intermediate authorities essential?

1. Security: limiting the root key’s usage reduces the risk of compromise.
2. Scalability: intermediates can be distributed geographically and by purpose (e.g., DV, OV, EV).
3. Control and auditability: every intermediate CA operates under its own CPS (Certification Practice Statement) and bears responsibility for the certificates it issues.

Common mistakes related to Intermediate CA.

The most frequent deployment error is the absence of a complete intermediate chain on the server.
As a result, the browser cannot build a full trust path and displays the error “incomplete chain”.

Correct configuration for Nginx:

ssl_certificate     /etc/ssl/certs/fullchain.pem;  
ssl_certificate_key /etc/ssl/private/domain.key;  

The fullchain.pem file must contain the domain certificate first, followed by all intermediates up to (but excluding) the root certificate.

In Apache, the equivalent configuration is:

SSLCertificateFile /etc/ssl/certs/domain.crt  
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt  
SSLCertificateKeyFile /etc/ssl/private/domain.key  

Missing intermediate certificates can be instantly diagnosed using the HEXSSL SSL Checker, which analyzes the structure and correctness of the certificate chain.

Short lifespan of intermediates.

Intermediate certificates usually have a validity period of 3–7 years, which allows rotation and the introduction of new algorithms.
When an intermediate expires, the root CA issues a new one — a transparent process for end users but critical for maintaining trust continuity.

How browsers and systems verify the trust chain.

When a user enters a website address and an HTTPS connection is established, the browser doesn’t simply check whether a certificate is present.
It performs a series of detailed checks to confirm that:

1. the certificate is cryptographically valid,
2. the chain of trust is complete,
3. the certificate is currently valid,
4. the domain (SNI) matches the CN/SAN fields,
5. and the certificate has not been revoked.

Certificate validation stages

The validation process can be divided into several key steps:

1. Server certificate retrieval – during the TLS handshake, the client receives the server certificate and, if configured correctly, the intermediate chain as well.
2. Chain construction – the browser or TLS library attempts to link each certificate to its issuer until it reaches a known root CA from its trust store.
3. Signature verification – each certificate’s digital signature is checked using the public key of the issuer.
4. Validity check – ensures the certificate is neither expired nor not yet valid.
5. Hostname verification (CN/SAN) – ensures the hostname matches one of the entries in the Subject Alternative Name field.
6. Revocation check (OCSP/CRL) – verifies that the certificate has not been revoked.
7. Policy and extension validation – checks fields such as Extended Key Usage, Key Usage, and path length constraints.

Validation using OpenSSL.

Administrators can manually perform certificate validation using:

openssl verify -CAfile chain.pem cert.pem  

or directly from the server:

openssl s_client -connect example.com:443 -showcerts -verify 5  

The -verify parameter defines the validation depth (how many links the chain contains).
The output displays the full path to the root CA and the status of each link.
If you encounter unable to get local issuer certificate or self-signed certificate in chain, it indicates that the server isn’t sending the full intermediate chain.

Differences in implementation.

Each ecosystem uses its own validation logic:

• Chrome/Chromium – uses the cert_verify_proc engine with dynamic chain building.
• Firefox – relies on the NSS library and Mozilla’s root store.
• OpenSSL/cURL – depends on the local ca-bundle.crt file.
• Java/Tomcat – uses the cacerts keystore.

Because of this, a configuration that works in one environment might fail in another.
We recommend testing deployments across multiple browsers and operating systems.

OCSP, CRL and Certificate Revocation Mechanisms

Trust validation is not limited to signatures and validity dates.
A certificate that was issued correctly can become invalid at any moment — for example, if its private key is compromised or it was issued in error.
For this reason, **revocation mechanisms** exist to verify whether a certificate has been revoked before its expiry date.

CRL – Certificate Revocation List

A CRL is the oldest and simplest revocation method.
The issuing CA periodically publishes a list of serial numbers for certificates that have been revoked.
Each certificate includes a CRL Distribution Points field containing the HTTP or LDAP URL where the list can be downloaded.

Checking a CRL locally:

openssl crl -in crl.pem -noout -text  

or

openssl verify -crl_check -CAfile ca.crt cert.pem  

Drawbacks of CRL:

• Files may be large – sometimes tens of MB.
• Browsers rarely fetch them in real time.
• Update delays can reach hours or days.

In practice, CRLs are being replaced by OCSP.

—

OCSP – Online Certificate Status Protocol

OCSP allows real-time validation of a certificate’s status.
Instead of downloading an entire list, the client queries the CA’s OCSP responder with the certificate’s serial number and receives a signed reply: good, revoked, or unknown.

Example query using OpenSSL:

openssl ocsp -issuer intermediate.pem -cert cert.pem -url http://ocsp.sectigo.com  

OCSP Stapling

To improve performance and avoid external network calls, a web server can attach the latest OCSP response directly to the TLS handshake — this is known as **OCSP stapling**.
The browser no longer needs to contact the CA’s OCSP server; it simply verifies the stapled, signed status.

Nginx example:

ssl_stapling on;  
ssl_stapling_verify on;  
ssl_trusted_certificate /etc/ssl/certs/ca-bundle.crt;  
resolver 8.8.8.8;  

It is also advisable to enable the **OCSP Must-Staple** extension, which requires a stapled response for every TLS session.
If the stapled response is missing, the browser will show an error.

Modern alternatives

• CRLite (Mozilla) – distributes compressed revocation data using Bloom filters, updated together with Firefox releases.
• SCVP (Server-Based Certificate Validation Protocol) – delegates validation to a central server.
• OCSP MultiResponder – aggregates responses for multiple CAs.

Although not yet mainstream, these solutions indicate the future: moving away from heavy CRL files toward lightweight, continuously updated, and automated validation systems.

—

Cross-Signing and Root Migration – Practice and Risks

The PKI ecosystem is dynamic — roots expire, new algorithms appear, and browsers change their requirements.
To maintain compatibility, certificate authorities use **cross-signing**, issuing an intermediate certificate signed by two different roots.

How cross-signing works

Suppose a CA introduces a new root that is not yet trusted on older devices.
It issues an intermediate certificate signed by both the new and the old root.
New systems will use the new chain, while legacy ones can still rely on the old one — ensuring continuous trust.

Real-world example:
Let’s Encrypt used cross-signing between its new ISRG Root X1 and the older DST Root CA X3 to maintain compatibility with Android 7 and earlier.

Potential issues

While necessary, cross-signing can create ambiguity.
A browser may build multiple possible chains.
If one of the roots expires or is revoked, some users will encounter “certificate not trusted” errors.

A similar challenge arises during root migrations such as USERTrust RSA → R46/E46 (Sectigo).
The new root may not exist in older trust stores, so the CA keeps cross-signed intermediates for a transitional period.
Administrators should test their servers against both chains during this phase.

HEXSSL recommendations:

1. Verify the full chain using HEXSSL SSL Checker.
2. Ensure new roots are present in target systems (Windows, Android, macOS).
3. Avoid manually importing roots – always rely on official trust stores.

—

Example of Chain Analysis in Practice

Imagine a server presenting the following certificates:

1. example.com (Leaf)
2. Sectigo RSA Domain Validation Secure Server CA (Intermediate)
3. USERTrust RSA Certification Authority (Root)

OpenSSL output:

depth=2 CN = USERTrust RSA Certification Authority  
verify return:1  
depth=1 CN = Sectigo RSA Domain Validation Secure Server CA  
verify return:1  
depth=0 CN = example.com  
verify return:1  

A status of verify return:1 means successful verification at all levels.
If instead you see:

verify error:num=20:unable to get local issuer certificate  

it indicates the local system does not know the appropriate root, or the intermediate was not sent by the server.

—

Testing Chain Completeness

Beyond command-line tools like openssl, the easiest method is using the **HEXSSL SSL Checker**.
It analyzes not only the validity of the chain but also:

• key type and length,
• signature algorithm,
• presence of OCSP stapling,
• CN/SAN host match,
• expiry date and alert status.

The HEXSSL Checker also generates a report with a security grade (A–F) and recommendations.
It can be integrated into TLS audits for NIS2 or ISO 27001 compliance.

Common Deployment Errors and Their Consequences

In theory, implementing an SSL/TLS certificate seems simple — install the certificate, private key, and intermediate chain.
In practice, even a small configuration mistake can cause trust failures, browser warnings, or total connection loss.
Below are the most frequent issues observed during HEXSSL audits.

1. Missing Intermediate Certificate (Incomplete Chain)

This is by far the most common issue, especially in legacy Apache, Tomcat, or load balancer setups.
The server presents only the leaf (domain) certificate but fails to send the intermediate(s).

Symptom:
Browser error: “certificate chain incomplete” or “unable to get local issuer certificate”.

Consequences:

• Some browsers may build the chain from cache, but many (especially mobile) will reject it entirely.
• Android and IoT devices often display “site not secure,” even when the domain’s certificate itself is valid.

Solution:
Always provide the **full chain** — the domain certificate plus all intermediates.
For Nginx:

ssl_certificate     /etc/ssl/certs/fullchain.pem;  
ssl_certificate_key /etc/ssl/private/domain.key;  

For Apache:

SSLCertificateFile      /etc/ssl/certs/domain.crt  
SSLCertificateChainFile /etc/ssl/certs/intermediate.crt  

2. Self-Signed Certificate in Production

Self-signed certificates are useful for testing or internal networks but provide no external trust.
Browsers will always flag them as untrusted.

Symptom:
“Your connection is not private” (NET::ERR_CERT_AUTHORITY_INVALID).

Consequences:

• Loss of credibility and user trust.
• Possible blocking by security scanners.
• Negative SEO and trust rank impact.

Solution:
Use certificates issued by recognized CAs — even free ones like Let’s Encrypt, unless organizational validation (OV/EV) is required.
For commercial sites, HEXSSL recommends Sectigo OV or EV certificates for full trust coverage.

3. Incorrect CN or SAN (Subject Alternative Name)

Since 2017, browsers ignore the Common Name (CN) and rely exclusively on Subject Alternative Name.

Symptom:
The connection works for one hostname but not for aliases or subdomains.

Solution:
When generating the CSR, include all hostnames that the server will handle:

[ req ]  
default_bits       = 2048  
prompt             = no  
default_md         = sha256  
distinguished_name = dn  
req_extensions     = req_ext  

[ dn ]  
CN = www.example.com  

[ req_ext ]  
subjectAltName = @alt_names  

[ alt_names ]  
DNS.1 = www.example.com  
DNS.2 = example.com  
DNS.3 = api.example.com  

The HEXSSL CSR Generator automatically creates a CSR with the correct CN and SAN fields.

4. Expired Certificates or Missing Renewal Automation

Certificates have a maximum lifetime of 398 days (1 year + 33 days).
Many incidents occur simply because the renewal was forgotten — especially in environments with dozens of domains.

Symptom:
“Certificate has expired” or “ERR_CERT_DATE_INVALID”.

Solution:
Use automated monitoring and renewal.
The HEXSSL SSL Expiry Monitor allows centralized expiry tracking and sends alerts before expiration.

5. Mixed Content – Non-Secure Elements within HTTPS

Even with a valid certificate, some assets (images, JS, iframes) may still load over HTTP.

Symptom:
“This page is not fully secure” or a ⚠️ warning icon near the padlock.

Solution:
Force HTTPS for all resources:

Content-Security-Policy: upgrade-insecure-requests;  

In WordPress, enforce HTTPS in wp-config.php or use plugins like *Really Simple SSL*.

6. Invalid or Stale OCSP Stapling

Occurs when the server presents an outdated OCSP response.

Symptom:
“OCSP response invalid” or “revocation check failed”.

Solution:
Clear the OCSP cache, fetch a fresh response, and ensure that ssl_trusted_certificate points to an up-to-date CA bundle.

Self-Testing Certificate Chains

Administrators should regularly test their implementations — not only after installation but also after each update, renewal, or CA migration.

Local testing

1. Display the full chain:

   openssl s_client -connect domain.tld:443 -showcerts  
   

2. Verify the chain against trusted CAs:

   openssl verify -CAfile ca-bundle.crt cert.pem  
   

3. Check OCSP status:

   openssl ocsp -issuer intermediate.pem -cert cert.pem -url http://ocsp.sectigo.com  
   

Online testing with HEXSSL SSL Checker

The **HEXSSL SSL Checker** performs all these steps automatically, presenting:

• Full trust chain (Root → Intermediate → Leaf),
• Signature algorithms and key lengths,
• OCSP/CRL status,
• Expiration date and remaining validity,
• Security configuration recommendations.

Example output:

• Chain: complete → OK
• OCSP stapling: active
• Algorithm: SHA256RSA 2048-bit → recommended
• NIS2 compliance: YES
• Rating: A+

HEXSSL Best Practice Recommendations for Administrators and Organizations

Based on years of experience, HEXSSL recommends several principles that minimize risk and ensure compliance with NIS2, eIDAS 2.0, and ISO 27001.

1. Design for trust, not just encryption.

A certificate is not merely a padlock icon.
Every element of the chain must be deliberate — CA choice, key strength, and algorithm.
Use trusted CAs, avoid self-signed certificates, and retest after every change.

2. Use strong algorithms and current roots.

Preferred algorithms today:

• RSA 3072+
• ECDSA P-256 / P-384
• Signatures: SHA-256 or SHA-384

Avoid SHA-1 and RSA 1024 — they are deprecated and non-compliant with CA/B Forum standards.

3. Automate renewals.

Automate CSR generation, installation, and service reloads (nginx, apache).
For large-scale environments, consider ACME clients (e.g., certbot, acme.sh) with API integration.

4. Monitor and act proactively.

The **HEXSSL SSL Expiry Monitor** supports multi-domain monitoring with configurable alerts:

• First alert: 30 days before expiry,
• Second: 7 days before,
• Final: 48 hours before.

5. Audit your infrastructure annually.

Each audit should include:

• Chain validity checks,
• TLS configuration (protocols, ciphers, OCSP stapling),
• Renewal procedures,
• Private key management policies.

HEXSSL also provides **SSL/TLS audit services** for server and cloud environments.
For details, contact our sales team via the contact form.

Trust and Compliance – NIS2, eIDAS 2.0

With the implementation of the NIS2 Directive and eIDAS 2.0 Regulation, SSL/TLS certificates have evolved from a technical feature to a **legal requirement**.

• NIS2 mandates encryption and integrity assurance for essential and important entities.
• eIDAS 2.0 establishes the European digital trust framework (Digital Identity Wallets, QTSP).
• SSL/TLS certificates are now considered part of the broader Trust Services infrastructure.

HEXSSL assists organizations in aligning TLS infrastructure with NIS2 and eIDAS requirements through audits, recommendations, and diagnostic tools (SSL Checker, OCSP Validator).

In Summary

The SSL/TLS trust chain is the backbone of global online security.
Through PKI hierarchy and strict validation principles, it ensures not just encryption but verified identity and integrity.
A single weak or missing link can break user trust, trigger browser errors, and expose real risks.

Proper SSL/TLS deployment requires:

• Regular testing and audits,
• Renewal automation,
• Active OCSP/CRL monitoring,
• And informed selection of CAs and algorithms.

HEXSSL provides the tools and expertise to streamline every stage of the certificate lifecycle — from CSR generation to chain validation and expiry monitoring.

FAQ – Frequently Asked Questions

1. What’s the difference between a Root CA and an Intermediate CA?
Root CAs sign intermediate CAs, which in turn issue end-entity certificates.
The root is offline and trusted in the local store, while intermediates operate in production.

2. Why does my browser show “incomplete chain”?
Because the server does not present the full intermediate chain.
Add a fullchain.pem in your server configuration.

3. Is Let’s Encrypt as secure as paid certificates?
Yes, in terms of encryption strength.
The difference lies in validation — Let’s Encrypt offers DV only, while OV/EV include organizational verification and warranty.

4. How can I check which Root CA my certificate uses?

openssl s_client -connect domain.com:443 -showcerts  

or use the **HEXSSL SSL Checker** to automatically identify your root anchor.

5. Why does the browser not trust my HTTPS site?
The root CA may be missing in the trust store or the chain is incomplete.
Rebuild and verify the chain.

6. How often should SSL certificates be renewed?
Maximum validity is 398 days.
Renew yearly and automate monitoring with HEXSSL Expiry Monitor.

7. What is OCSP Stapling and should I enable it?
Yes — it improves performance and privacy by embedding signed revocation status in the TLS handshake.

8. Does EV provide stronger encryption?
No, encryption is the same as DV/OV.
EV adds deeper identity verification for trust and brand assurance.

9. What does “cross-signed” mean?
It means the same intermediate is signed by multiple roots, ensuring compatibility during root transitions.

10. How does HEXSSL support SSL/TLS management?
HEXSSL provides professional tools:

• CSR Generator – creates valid CSR files with CN/SAN fields,
• SSL Checker – analyzes trust chains and TLS setup,
• Expiry Monitor – tracks certificate validity and alerts before expiry,
• Decoder & Validator – interprets OCSP/CRL data and validation status.