what is an ssl certificate chain? Complete Guide

A website can have a valid, unexpired SSL certificate and still trigger a security warning. The reason is often not the certificate itself but the certificate chain connecting it to a Certificate Authority that the visitor’s device trusts.

An SSL certificate chain is an ordered sequence of digital certificates that connects a website’s SSL/TLS certificate to a trusted root Certificate Authority (CA). It normally consists of a leaf certificate, one or more intermediate CA certificates, and a root certificate stored in the client’s trust store.

Understanding what is an ssl certificate chain makes HTTPS errors much easier to diagnose. Instead of seeing an SSL certificate as a standalone file, think of it as one part of a cryptographically verifiable path of trust.

A typical chain looks like this:

Trusted Root CA
      ↓
Intermediate CA
      ↓
Website / Leaf Certificate

Each level establishes trust in the level below it. The browser verifies those relationships until it reaches a root certificate it already trusts.

What Is an SSL Certificate Chain and Why Does It Exist?

An SSL certificate chain, often called a certificate chain of trust or certification path, provides the evidence a browser needs to decide whether a website certificate should be trusted.

When you connect to https://example.com, the server presents its certificate. But the browser cannot simply assume that certificate is legitimate. Anyone could create a certificate claiming to represent a particular domain.

Instead, the browser attempts to build a trusted path:

example.com
   ↓ issued by
Intermediate CA
   ↓ issued by
Root CA
   ↓
Trusted by the client

The website certificate is signed by an issuing CA. That CA certificate may in turn be signed by another CA. The process continues until the client reaches a trusted root, also known as a trust anchor. DigiCert describes a certificate chain as an ordered list in which the SSL/TLS certificate begins the path and each certificate is signed by the entity identified by the next certificate.

This model makes the public key infrastructure, or PKI, scalable. Browsers and operating systems do not need a preinstalled certificate for every website. They need a controlled collection of trusted root certificates from which valid certification paths can be constructed.

SSL vs. TLS terminology

“SSL certificate” remains the familiar industry term, but modern HTTPS connections use TLS (Transport Layer Security) rather than the obsolete SSL protocols. The certificates themselves generally follow the X.509 certificate format, while certificate-path validation is standardized in RFC 5280.

So terms such as these are commonly used for essentially the same subject:

• SSL certificate chain
• TLS certificate chain
• Certificate chain
• Chain of trust
• Certificate trust chain
• Certification path

The exact technical details can vary, but each describes the process of connecting an end-entity certificate to a trusted certificate authority.

The Three Main Parts of an SSL Certificate Chain

Most public website certificate chains involve three roles: the root CA certificate, an intermediate CA certificate, and the leaf or server certificate. A chain can contain more than one intermediate.

Certificate	Main role	Typically signed by	Usually supplied during TLS connection?
Root certificate	Trust anchor	Itself	Normally no
Intermediate certificate	Delegates CA trust	Root or another intermediate	Yes
Leaf certificate	Identifies website/service	Intermediate CA	Yes

Understanding these roles is the easiest way to understand the entire chain.

1. Root CA certificate

The root certificate sits at the trust end of the chain.

A root certificate belongs to a root Certificate Authority and is generally self-signed. In other words, its issuer and subject represent the same CA. Its authority does not come from another certificate above it; it comes from being included in a trusted root store maintained by a browser, operating system, or other client.

Common trust stores are maintained as part of operating systems and browser ecosystems. A client uses its local trust configuration to determine which roots can act as trust anchors.

Because a root CA’s private key has enormous security importance, public CAs generally avoid using root keys for routine website certificate issuance. Instead, roots authorize intermediate CAs.

2. Intermediate CA certificate

An intermediate certificate sits between the leaf certificate and a root.

It may also be called:

• Intermediate CA
• Issuing CA
• Subordinate CA
• Chain certificate

An intermediate certificate is signed by a root CA or by another intermediate CA.

For example:

Root CA
   ↓
Intermediate CA 1
   ↓
Intermediate CA 2
   ↓
Website Certificate

This separation limits the need to expose root signing infrastructure during everyday certificate issuance.

For website administrators, intermediate certificates are especially important because they normally need to be delivered with the website’s certificate. DigiCert notes that failing to install the required intermediate certificate can prevent some browsers, mobile devices, and applications from trusting an otherwise valid SSL/TLS certificate.

3. Leaf or end-entity certificate

At the website end of the chain is the leaf certificate.

You may also see it called the:

• Server certificate
• Website certificate
• Domain certificate
• End-entity certificate

This is the certificate associated directly with the website or service.

Among other information, a typical leaf certificate contains its public key, issuer, validity period, digital signature, permitted key usage, and the domain names it covers through fields such as the Subject Alternative Name (SAN) extension.

For a visitor requesting www.example.com, this is the certificate directly associated with that hostname.

How Does an SSL Certificate Chain Work?

The chain is checked during the process of establishing a secure TLS connection.

Suppose a server has this certification path:

www.example.com
      ↓
Example Issuing CA
      ↓
Example Root CA

The browser does not merely look at all three names and accept them. It performs cryptographic and policy checks to determine whether a valid certification path exists.

Step 1: The client connects to the HTTPS server

A browser or another TLS client connects to the server, normally over TCP port 443 for HTTPS.

During the TLS handshake, the server provides its leaf certificate and normally the intermediate certificate or certificates needed to construct its chain.

The root usually does not need to be transmitted because the trust anchor is expected to exist in the client’s trust store.

Step 2: The leaf certificate is examined

The client examines the website certificate.

Among the relevant checks are whether the certificate is currently valid, whether it is appropriate for the intended use, and whether the hostname being accessed is covered by the certificate.

A valid signature alone is therefore not enough. A certificate for the wrong hostname should not be accepted merely because a legitimate CA signed it.

Step 3: The issuer is identified

The leaf certificate identifies its issuer.

The client then needs the corresponding issuer certificate—usually an intermediate CA certificate—to continue building the certification path.

Conceptually:

Leaf:
Subject = example.com
Issuer  = Example Intermediate CA

Intermediate:
Subject = Example Intermediate CA
Issuer  = Example Root CA

Step 4: Digital signatures are verified

Each certificate is cryptographically signed by its issuer.

The client uses the issuer’s public key to verify the signature on the certificate below it. The same basic process continues through the certification path.

This establishes that the certificates have a valid cryptographic relationship rather than merely containing matching issuer names.

Step 5: Certificate constraints are checked

Path validation involves more than following signatures.

X.509 certificates can contain extensions and constraints controlling how they may be used. A CA certificate, for example, must be permitted to act as a certificate authority.

Clients can also evaluate factors such as certificate validity periods, policy requirements, key usage, and other path-validation rules.

Step 6: The client reaches a trusted root

Eventually, the client attempts to reach a certificate it accepts as a trust anchor.

If a valid path reaches an appropriate trusted root and the other TLS certificate checks succeed, the certificate can be accepted for the connection.

If the chain cannot be constructed or validated, the client may reject the connection or display a certificate warning.

Quick takeaway: The browser does not trust a website merely because it presents a certificate. It trusts the site certificate when it can validate an acceptable cryptographic path from that certificate to a trust anchor it recognizes.

what is an ssl certificate chain of trust?

The chain of trust is the hierarchy of cryptographic endorsements behind a certificate.

A useful way to picture it is as delegated authority.

Imagine a browser already trusts Root CA A:

Browser trusts Root CA A
          ↓
Root CA A authorizes Intermediate CA B
          ↓
Intermediate CA B issues example.com certificate

The browser does not begin by trusting example.com. Instead, it verifies that the site’s certificate was issued by Intermediate B and that Intermediate B’s authority can be traced to Root A.

That is why the word chain matters. Each link depends on another link until the validation process reaches a trust anchor.

Why not have root CAs issue every website certificate?

Technically, a root could sign end-entity certificates, but separating root and issuing functions creates a safer hierarchy.

The root CA’s private key is exceptionally sensitive. Compromise of a widely trusted root could affect trust far beyond a single website.

Intermediate CAs allow certificate authorities to delegate issuance while keeping root keys much more tightly protected.

They also make certificate ecosystems easier to manage. Different intermediates can be created for particular products, policies, algorithms, operational environments, or periods without replacing the root trusted by clients.

Root Certificate vs. Intermediate Certificate vs. Leaf Certificate

The three certificate types are sometimes confused because all can use the X.509 format. Their roles, however, are very different.

Feature	Root CA	Intermediate CA	Leaf Certificate
Represents a website	No	No	Yes
Can issue/sign certificates	Yes	Yes, within its constraints	Normally no
Acts as trust anchor	Yes	Normally no	No
Self-signed	Typically yes	No	No
Installed in client trust store	Typically	Not necessarily	No
Normally sent by web server	Usually unnecessary	Yes	Yes
Also called	Root, trust anchor	Issuing/subordinate CA	Server/end-entity certificate

One practical distinction matters most for server administrators:

Your server normally needs to provide the leaf certificate plus the necessary intermediate certificates—not rely on the visitor already having those intermediates.

Why Intermediate Certificates Matter So Much

A missing intermediate is one of the classic causes of an incomplete certificate chain.

Imagine that a client trusts Root A and your server certificate was issued by Intermediate B:

Server Certificate
      ↓
Intermediate B
      ↓
Root A

If your server sends only:

Server Certificate

the client may lack the information it needs to construct the path to Root A.

This explains a frustrating situation administrators sometimes encounter: a site works on one device but produces a certificate error on another.

A client may already possess or have cached a useful intermediate, while a fresh client does not. That makes testing only from your regular browser unreliable when diagnosing chain problems. Several current certificate-chain guides identify missing intermediates as a major source of inconsistent TLS failures across browsers, mobile devices, APIs, and command-line clients.

The safe approach is to configure the server to provide the required chain correctly.

What Is a Full Certificate Chain?

A full certificate chain commonly refers to a certificate bundle containing the leaf certificate followed by the intermediate certificate or certificates needed to establish its path.

You may encounter filenames such as:

cert.pem
chain.pem
fullchain.pem
server.crt
bundle.crt
ca-bundle.crt

Do not assume the filename alone tells you what the file contains. Inspect the configuration and certificate contents.

For example, a PEM-encoded certificate is represented using markers such as:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

A chain file may contain several certificate blocks one after another.

GitLab’s certificate-chain documentation similarly notes that PEM certificates may use .crt or .pem extensions and that the contents, rather than the extension itself, determine the encoding.

What is fullchain.pem?

The name fullchain.pem is especially familiar in automated certificate deployments.

Conceptually, it contains:

Leaf certificate
+
Intermediate certificate(s)

The corresponding private key is separate and must remain protected.

That distinction matters. A certificate contains public information and a public key; the private key is the secret cryptographic material proving control of that certificate’s key pair.

Never treat a private-key file as if it were simply another certificate in the public chain.

Correct SSL Certificate Chain Order

When certificate files are combined for server configuration, order can matter.

The conventional server-side sequence begins with the certificate closest to the server and moves toward the trust anchor:

1. Leaf / server certificate
2. Intermediate CA certificate
3. Additional intermediate CA certificate, if required
4. Root CA certificate, if the particular application requires it

Oracle documents this leaf-to-intermediate-to-root ordering for certificate-chain files.

For a typical public HTTPS server, however, the root generally does not need to be sent during the handshake because clients already establish root trust locally.

A common conceptual server bundle therefore looks like:

example.com
Intermediate CA 1
Intermediate CA 2

rather than unnecessarily appending the root.

what is an ssl certificate chain Error?

A certificate-chain error occurs when a client cannot construct or validate an acceptable path from the presented leaf certificate to a trusted root.

The certificate on the website may still be within its validity period. That does not guarantee the chain is usable.

Missing intermediate certificate

This is one of the first things to investigate.

The server has the domain certificate installed but fails to provide one or more required intermediate CA certificates.

The path effectively becomes:

Leaf → ? → Trusted Root

The missing link prevents reliable validation.

Wrong intermediate certificate

Installing an intermediate certificate is not enough. It needs to be an issuer that can participate in a valid certification path for the leaf certificate.

An unrelated CA certificate cannot complete the chain.

Certificates in the wrong order

Some server software, applications, and import procedures expect certificates in a particular sequence.

A badly assembled certificate bundle can therefore create configuration or interoperability problems.

Expired certificate in the path

Administrators often check only the website certificate’s expiration date.

Certificates elsewhere in a candidate certification path also matter. If the usable path contains a certificate that is no longer valid, clients may be unable to validate it.

Untrusted root

A mathematically valid signature chain does not automatically mean a client trusts the chain.

The path ultimately needs to terminate at a trust anchor accepted by that client. An internal company CA, private PKI root, or self-signed root will not automatically be trusted by unrelated public devices.

Hostname mismatch

This is technically different from a missing-chain problem, but it is commonly encountered during the same troubleshooting process.

A certificate issued for one hostname cannot simply be used for any other hostname. The client checks whether the requested hostname is covered by the certificate’s identities, normally through its Subject Alternative Name values.

Self-signed certificates

A self-signed certificate does not gain public trust simply because it is cryptographically valid.

It can work in controlled environments when administrators explicitly distribute and trust the appropriate root certificate. Without that trust configuration, public clients have no independent reason to accept it.

How to Check an SSL Certificate Chain

You can inspect a certificate chain using a browser, an external TLS analyzer, or command-line tools.

For technical troubleshooting, OpenSSL is particularly useful because it lets you inspect what the server actually provides.

Check the chain with OpenSSL

A commonly used command is:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Replace example.com with the actual hostname.

The -servername parameter supplies the Server Name Indication (SNI) hostname. This is important on servers hosting multiple HTTPS sites on the same IP address.

The output can reveal the certificates presented by the server, their subjects and issuers, and verification information. OpenSSL s_client is also widely used in current certificate-chain documentation for diagnosing incomplete chains.

Inspect an individual certificate

If you have a PEM certificate file, you can inspect it with:

openssl x509 -in certificate.pem -text -noout

Pay attention to fields such as:

Subject
Issuer
Validity
Public Key
X509v3 extensions
Subject Alternative Name
Basic Constraints
Key Usage
Authority Key Identifier
Subject Key Identifier

The Subject tells you who the certificate represents, while Issuer identifies the authority that signed it.

Verify a certificate against a CA chain

OpenSSL can also perform explicit verification when you have the relevant files.

A simplified pattern is:

openssl verify -CAfile root.pem \
  -untrusted intermediate.pem \
  server.pem

A successful result indicates that OpenSSL could build and validate the supplied path under the specified trust configuration.

Real deployments can involve more complicated paths, multiple intermediates, cross-signing, and client-specific trust stores, so successful verification with one local setup does not prove every possible client will build exactly the same path.

How to Fix an Incomplete SSL Certificate Chain

If your server has a valid certificate but fails chain tests, avoid immediately replacing the leaf certificate. First determine what the server is actually presenting.

A reliable troubleshooting sequence is:

1. Inspect the server’s current certificate chain. Use OpenSSL or a remote TLS analyzer rather than relying solely on a browser that may have cached certificate information.
2. Identify the leaf certificate’s issuer. Inspect the certificate and determine which CA issued it.
3. Obtain the correct intermediate certificate or CA bundle. Use the certificate authority’s official certificate files or the files supplied with the certificate.
4. Build the server chain in the expected order. Place the leaf certificate first, followed by the appropriate intermediate certificate or certificates.
5. Configure the web server to use the complete chain. The exact directive depends on the server software and certificate deployment method.
6. Reload or restart the affected service when required.
7. Test externally again. Confirm what a fresh client actually receives.

The key is to fix the served chain, not merely create a correct chain file somewhere on the server.

A practical troubleshooting mistake to avoid

Suppose this file is correct:

/etc/ssl/example/fullchain.pem

but the web server is configured to use:

/etc/ssl/example/cert.pem

Editing fullchain.pem will accomplish nothing if the active configuration never reads it.

Always confirm the exact certificate path referenced by the running server configuration.

Certificate Chain on Nginx, Apache, and Other Servers

Different web servers expose certificate configuration differently, but the underlying requirement remains the same: clients need enough certificate information to build a valid path.

Nginx

An Nginx TLS configuration commonly references a certificate file and private key:

ssl_certificate     /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;

The certificate file needs to contain the chain expected by the configuration, generally beginning with the server certificate and followed by intermediate certificates.

Apache

Apache’s exact configuration depends on the software version and deployment environment.

Modern configurations commonly use the server certificate/chain through the relevant SSLCertificateFile configuration, while the private key is configured separately.

Do not copy old configuration snippets blindly. Confirm the directives supported by the Apache version actually running on the server.

Reverse proxies and CDNs

If TLS terminates at a reverse proxy, load balancer, CDN, ingress controller, or cloud service, changing the certificate on the backend origin may not change the certificate visitors see.

Test the public endpoint first and identify where TLS termination actually occurs.

That practical distinction saves a great deal of wasted debugging time.

Why Can a Broken Chain Work in One Browser but Not Another?

This is one of the most confusing certificate-chain problems.

Two clients can have different:

• Root trust stores
• Cached intermediate certificates
• Operating-system certificate stores
• Certificate path-building behavior
• Software versions
• Enterprise trust policies

A browser that already knows the missing intermediate may successfully construct a path even though the server is not providing a complete deployment. Another browser, API client, mobile application, or command-line utility may fail.

This is why “it works on my computer” is weak evidence that an SSL certificate chain is configured correctly. A fresh external test is much more useful when checking what your server actually sends.

Does the Server Need to Send the Root Certificate?

Usually, a public HTTPS server does not need to send the root certificate.

The whole purpose of the root is to act as a locally trusted anchor. The client should already possess or otherwise trust that root through its trust-store configuration.

The server’s responsibility is normally to provide:

Leaf certificate
Intermediate certificate(s)

The client then connects those certificates to an appropriate trust anchor in its own store.

This also explains why simply sending an arbitrary root certificate does not make it trusted. Trust is determined by the client, not declared by the server.

What Is Cross-Signing in a Certificate Chain?

Certificate paths are not always a simple three-certificate ladder.

A CA certificate can sometimes participate in multiple possible paths. Cross-signing allows a CA certificate or key hierarchy to connect to another trusted hierarchy, which can help support clients with different root stores.

As a result, the certificates a server sends and the final path a particular client constructs are related but not always identical concepts.

This distinction is useful:

Certificate chain sent by server: the certificates delivered during the TLS handshake.

Certification path built by client: the path the client ultimately constructs to one of its acceptable trust anchors.

A sophisticated TLS client may have more than one possible path available and select one that validates under its own trust-store and policy rules.

Certificate Chain vs. Private Key

An SSL certificate chain should never be confused with the server’s private key.

The chain establishes identity and trust relationships. The private key proves that the server controls the cryptographic key corresponding to its leaf certificate.

Component	Secret?	Main purpose
Leaf certificate	No	Identifies server and contains public key
Intermediate certificate	No	Connects leaf toward trusted CA
Root certificate	No	Represents trust anchor
Private key	Yes	Proves control of the certificate’s key pair

Certificates are intentionally public. Private keys are not.

If a private key is exposed, the security implications are much more serious than an incorrectly ordered certificate bundle. Protect private keys with appropriate filesystem permissions, access controls, and secure key-management practices.

Certificate Chain vs. Certificate Bundle

The terms are related but not perfectly interchangeable.

A certificate chain describes the trust relationship between certificates.

A certificate bundle describes a file or collection containing multiple certificates.

A bundle may contain a valid ordered chain, but simply placing several certificates into one file does not guarantee that those certificates form a valid certification path.

For example:

server.pem
intermediate-a.pem
intermediate-b.pem

may represent a correct chain if each certificate properly relates to the next.

But:

server.pem
unrelated-ca.pem
another-root.pem

is still a bundle of certificates—it is just not a useful chain for that server certificate.

How Certificate Revocation Fits Into the Picture

A chain being cryptographically valid does not mean every certificate should necessarily continue to be accepted.

Certificate ecosystems include mechanisms intended to communicate revocation status, including the Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).

TLS deployments may also use OCSP stapling, where a server supplies relevant revocation-status information during the connection.

These mechanisms address a different question from basic path construction:

• Certificate chain: Can this certificate be connected to a trusted issuer hierarchy?
• Validity period: Is the certificate within its permitted time window?
• Hostname validation: Is it valid for the requested hostname?
• Revocation: Has its status changed before its scheduled expiration?

Successful HTTPS validation can therefore involve several checks beyond simply finding a root certificate.

How Certificate Chains Relate to Certificate Authorities

Public Certificate Authorities such as DigiCert, Sectigo, and Let’s Encrypt operate within the broader Web PKI ecosystem.

A CA does more than issue a file containing a public key. It operates under policies and technical requirements governing certificate issuance and CA behavior.

Let’s Encrypt, for example, uses root and intermediate certificates within its hierarchy, while public clients decide which roots they trust through their own root programs and trust stores.

This division of responsibility is central to Web PKI:

Certificate Authority
        ↓ issues/signs
Certificate hierarchy
        ↓ validated by
Browser or TLS client
        ↓ according to
Local trust store and policies

A CA can create a cryptographically valid certificate hierarchy, but a client still controls which roots it accepts as trust anchors.

Common Misconceptions About SSL Certificate Chains

Several assumptions repeatedly cause troubleshooting problems.

“My SSL certificate is valid, so the chain must be valid.”

No. The leaf certificate can be unexpired and correctly issued while the server fails to provide the intermediate certificates required by clients.

“The browser should download anything that is missing.”

Do not build a production configuration around that assumption. Servers should be configured to deliver the required intermediate certificates reliably.

“If Chrome works, every client will work.”

No. Browsers, operating systems, APIs, Java runtimes, embedded devices, and other TLS clients may use different trust stores and path-building behavior.

“I should always send the root certificate.”

Normally unnecessary for public HTTPS. The root’s authority comes from the client’s trust store.

“The root certificate is trusted because it is self-signed.”

Self-signing does not create trust by itself. The root is trusted because the client has explicitly designated it as a trust anchor.

“SSL chain errors mean encryption is broken.”

Not exactly. A chain error primarily means the client cannot establish the required identity/trust path. Secure TLS depends on both cryptographic protection and authenticated identity.

A Simple Real-World Example

Imagine that a certificate authority has this hierarchy:

Example Root CA
      ↓
Example TLS Issuing CA 01
      ↓
www.example.com

The server is configured with:

www.example.com certificate
Example TLS Issuing CA 01 certificate
www.example.com private key

A visitor connects.

The server sends the leaf and intermediate certificates. The browser sees that the leaf was issued by Example TLS Issuing CA 01, verifies its signature, checks the intermediate, and determines whether it can build an acceptable path to Example Root CA in its trusted store.

If all relevant checks succeed, the browser can authenticate the certificate for the requested hostname and continue the TLS connection.

Now remove the intermediate certificate:

www.example.com
      ↓
      ?
      ↓
Example Root CA

The website certificate itself has not changed. Its expiration date has not changed. Its domain names have not changed.

Yet a client unable to obtain or construct the missing relationship can reject the connection.

That is the practical purpose of the SSL certificate chain.

Best Practices for Maintaining a Healthy Certificate Chain

Certificate-chain problems are easier to prevent than troubleshoot after users begin reporting security warnings.

Use a few basic operational habits:

• Install the complete chain supplied or recommended by your Certificate Authority.
• Serve the leaf certificate followed by the necessary intermediate certificates.
• Keep the private key separate and protected.
• Test the public endpoint after certificate issuance and renewal.
• Do not rely only on a browser that may already know an intermediate certificate.
• Check certificate expiration across the relevant certification path, not just the leaf.
• Verify the hostname and Subject Alternative Names.
• Re-test after changing a CDN, reverse proxy, load balancer, hosting provider, or TLS termination point.
• Automate certificate renewal where appropriate, but verify that automation deploys the correct chain as well as the new leaf certificate.
• Use OpenSSL or a reputable external TLS analyzer when troubleshooting.

Automation deserves particular attention. A certificate renewal can succeed while deployment fails to update the correct chain file or reload the service. Treat issuance, chain installation, service configuration, and external validation as separate steps.

Final Takeaway

Understanding what is an ssl certificate chain comes down to one idea: a browser needs a verifiable path between the certificate presented by a website and a root authority the client already trusts.

The usual structure is:

Leaf / Website Certificate
        ↓
Intermediate CA Certificate(s)
        ↓
Trusted Root CA

The leaf identifies the website. Intermediate CAs provide delegated signing authority. The root acts as the trust anchor. During certificate path validation, the client checks the cryptographic relationships and relevant certificate requirements before deciding whether the identity can be trusted.

For website administrators, the practical lesson is simple: installing the leaf certificate alone is not always enough. Configure the server or TLS termination service with the correct intermediate chain, verify what it actually presents publicly, and test it from a fresh client after every certificate deployment or renewal.