Introduction

The phrase "bad certificate" in Traefik 2 can refer to more than one TLS failure, so the first job is to locate where the handshake is breaking. The error may be on the client-facing side where Traefik presents its certificate, or on the upstream side where Traefik is trying to validate a backend service certificate.

Identify Which TLS Connection Is Failing

Traefik often sits between two TLS conversations:

• client to Traefik
• Traefik to backend service

If browsers complain, the problem is usually the certificate Traefik serves on its entrypoint. If Traefik logs show upstream handshake failures, the problem is often backend validation, certificate chain issues, or mismatched server names.

A quick check with OpenSSL helps on the public side:

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

Look for the certificate subject, the issuer chain, and whether the server returns the full chain.

Fixing Traefik's Frontend Certificate

If Traefik is serving the wrong certificate, the most common problems are:

• wrong certFile or keyFile
• certificate and private key do not match
• the full chain is incomplete
• the certificate does not cover the requested hostname

Example dynamic configuration:

1tls:
2  certificates:
3    - certFile: /certs/fullchain.pem
4      keyFile: /certs/privkey.pem

Use the full chain file, not only the leaf certificate. Many clients treat a missing intermediate certificate as a certificate failure even when the leaf cert itself is valid.

You should also confirm that the private key matches the certificate. If they do not belong together, the handshake will fail before routing matters.

Fixing Backend TLS Validation

Another common scenario is Traefik talking to an HTTPS backend that uses a self-signed certificate or a certificate issued by an internal CA. In that case, Traefik may reject the backend certificate unless you tell it which CA to trust.

Dynamic configuration with a custom serversTransport looks like this:

1http:
2  serversTransports:
3    internal-tls:
4      rootCAs:
5        - /certs/internal-ca.pem
6
7  services:
8    app:
9      loadBalancer:
10        serversTransport: internal-tls
11        servers:
12          - url: https://app.internal:8443

This is the correct solution when the backend certificate is valid for your internal CA but not trusted by the default system trust store.

For temporary debugging, some teams use:

1http:
2  serversTransports:
3    insecure-backend:
4      insecureSkipVerify: true

That disables certificate verification for the backend connection. It can confirm that trust validation is the issue, but it should not be the long-term fix for production traffic.

Hostname and SAN Mismatches

Even a trusted certificate fails if the hostname does not match the certificate's Subject Alternative Name entries. If Traefik connects to https://10.0.0.12:8443 but the backend certificate is issued for app.internal, validation fails.

In that situation, fix the backend URL or issue a certificate that matches the actual server name Traefik uses. TLS validation is not only about trust; it is also about name matching.

Logging and Debugging

Turn on debug logging when the source of the error is unclear:

log:
  level: DEBUG

Then inspect whether the message refers to entrypoint certificates, ACME, upstream handshakes, or client certificate validation. The phrase "bad certificate" by itself is too broad to diagnose the problem without context.

Common Pitfalls

One frequent mistake is uploading only the leaf certificate to Traefik and forgetting the intermediate certificates. Many TLS failures that look mysterious are simply incomplete chain delivery.

Another issue is using insecureSkipVerify: true as a permanent solution. That hides trust problems instead of fixing them and removes an important security check.

Developers also sometimes blame Traefik when the backend service is presenting a certificate for the wrong hostname or an expired certificate. Traefik is often only the component surfacing the failure.

Finally, if you use ACME and file-based certificates at the same time, make sure you know which certificate source is actually being served for a router. Misunderstanding certificate selection can send debugging in the wrong direction.

Summary

• Determine whether the TLS failure is client-to-Traefik or Traefik-to-backend.
• On the frontend side, verify hostname coverage, full chain delivery, and key pairing.
• On the backend side, configure trusted internal CAs with serversTransport.rootCAs when needed.
• Treat insecureSkipVerify as a debugging tool, not the final fix.
• Use debug logs and openssl s_client to narrow the failure before changing Traefik configuration.