[GH-ISSUE #5123] Management API remote error: tls: bad certificate, all clients failing to connect #10616

Closed
opened 2026-08-05 01:26:39 -04:00 by saavagebueno · 1 comment
Owner

Originally created by @clarkmcc on GitHub (Jan 16, 2026).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/5123

Describe the problem

All of the sudden I was unable to access my self-hosted portal due to net::ERROR_CERT_DATE_INVALID when making GET requests to https://<hostname>.com:33073/api/users for example. After a review of the logs on the management container, I see a bunch of IPs are failing to connect which leads me to believe that all the netbird clients are unable to connect as well.

2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:54314: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:33012: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:52708: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:47000: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:49676: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:56444: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:54996: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:35318: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:38534: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:16116: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:56208: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:48473: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:51282: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:51864: remote error: tls: bad certificate
2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:58906: remote error: tls: bad certificate

The cert for https://.com:443 is valid/not-expired, etc, but it appears the management API uses a different cert or something for some reason?

To Reproduce

No idea

Expected behavior

Certificates to automatically renew

Are you using NetBird Cloud?

No

NetBird version

Container image sha256:5db0797fdb5a9358afca0922b63e8abe438976b2831dabb5d8f8d9d997018fc8 from docker inspect

Is any other VPN software installed?

N/A

Debug output

To help us resolve the problem, please attach the following anonymized status output

N/A

Create and upload a debug bundle, and share the returned file key:

N/A

Uploaded files are automatically deleted after 30 days.

Alternatively, create the file only and attach it here manually:

N/A

Screenshots

N/A

Additional context

Add any other context about the problem here.

Have you tried these troubleshooting steps?

  • Reviewed client troubleshooting (if applicable)
  • Checked for newer NetBird versions
  • Searched for similar issues on GitHub (including closed ones)
  • Restarted the NetBird client
  • Disabled other VPN software
  • Checked firewall settings
Originally created by @clarkmcc on GitHub (Jan 16, 2026). Original GitHub issue: https://github.com/netbirdio/netbird/issues/5123 **Describe the problem** All of the sudden I was unable to access my self-hosted portal due to `net::ERROR_CERT_DATE_INVALID` when making GET requests to `https://<hostname>.com:33073/api/users` for example. After a review of the logs on the management container, I see a bunch of IPs are failing to connect which leads me to believe that all the netbird clients are unable to connect as well. ``` 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:54314: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:33012: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:52708: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:47000: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:49676: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:56444: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:54996: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:35318: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:38534: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:16116: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:56208: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:48473: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:51282: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:51864: remote error: tls: bad certificate 2026/01/16 02:24:55 http: TLS handshake error from <REDACTED>:58906: remote error: tls: bad certificate ``` The cert for https://<hostname>.com:443 is valid/not-expired, etc, but it appears the management API uses a different cert or something for some reason? **To Reproduce** No idea **Expected behavior** Certificates to automatically renew **Are you using NetBird Cloud?** No **NetBird version** Container image `sha256:5db0797fdb5a9358afca0922b63e8abe438976b2831dabb5d8f8d9d997018fc8` from `docker inspect` **Is any other VPN software installed?** N/A **Debug output** To help us resolve the problem, please attach the following anonymized status output N/A Create and upload a debug bundle, and share the returned file key: N/A *Uploaded files are automatically deleted after 30 days.* Alternatively, create the file only and attach it here manually: N/A **Screenshots** N/A **Additional context** Add any other context about the problem here. **Have you tried these troubleshooting steps?** - [x] Reviewed [client troubleshooting](https://docs.netbird.io/how-to/troubleshooting-client) (if applicable) - [ ] Checked for newer NetBird versions - [x] Searched for similar issues on GitHub (including closed ones) - [x] Restarted the NetBird client - [x] Disabled other VPN software - [x] Checked firewall settings
saavagebueno added the triage-needed label 2026-08-05 01:26:39 -04:00
Author
Owner

@clarkmcc commented on GitHub (Jan 16, 2026):

I re-pulled the latest docker images and rebooted the containers and that fixed it.

docker compose pull
docker compose up -d
<!-- gh-comment-id:3761765010 --> @clarkmcc commented on GitHub (Jan 16, 2026): I re-pulled the latest docker images and rebooted the containers and that fixed it. ```bash docker compose pull docker compose up -d ```
Sign in to join this conversation.
No Label triage-needed
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10616