X.509 certificate on Netdata

Synthetic Monitoring Solution For APIs & Services

Thu, 18 Dec 2025 00:00:00 +0000

Real-time synthetic monitoring for APIs, certificates, DNS, and network health - unified with infrastructure observability for faster troubleshooting and predictable costs.

CockroachDB certificate expired: TLS handshake failures and online rotation

Mon, 01 Jan 0001 00:00:00 +0000

CockroachDB uses mutual TLS for every connection: node-to-node, client-to-node, and admin UI. There is no plaintext fallback and no grace period. When a certificate expires, affected connections fail immediately.

Node certificate expiry prevents nodes from completing TLS handshakes with each other, which can look like a network partition or quorum loss. Client certificate expiry prevents applications from connecting. CA certificate expiry invalidates the entire trust chain at once, breaking every connection simultaneously.

HAProxy SSL certificate expired: total TLS failure and how to catch it first

Mon, 01 Jan 0001 00:00:00 +0000

Every client connecting to the affected frontend gets a TLS handshake failure. Not a percentage of clients, not a slow degradation: all of them, immediately, from the moment the certificate’s notAfter timestamp passes. Browsers show NET::ERR_CERT_DATE_INVALID, API clients throw certificate validation errors, and HAProxy itself is perfectly healthy, running, and passing every process-liveness check you have.

The mechanism is trivial, the blast radius is total, and HAProxy gives you no built-in metric, counter, or log warning that a certificate is about to expire. If you are reading this during an incident, skip to Quick checks and Fixes. If you are reading it afterward, the Prevention section is the part that matters.

Kubernetes kubelet certificate expired: detection, rotation, and recovery

Mon, 01 Jan 0001 00:00:00 +0000

A healthy node suddenly shows NotReady. Pods keep running, but the kubelet stops reporting status. kubectl logs and kubectl exec fail with TLS errors. The cluster event stream is quiet. This is usually an expired kubelet client certificate that failed to rotate.

Every kubelet maintains two independent TLS credentials: a client certificate that authenticates it to the kube-apiserver, and a serving certificate that secures the kubelet’s own HTTPS endpoints. Both typically have a one-year validity. When the client certificate expires, the kubelet cannot authenticate to the API server. The node goes NotReady. Workloads may continue running, but they are unmanaged: no evictions, no probe execution, no status updates, and no new pod scheduling. When the serving certificate expires, metrics-server, kubectl exec, and kubectl logs break even if the node is otherwise Ready.

NGINX SSL certificate expired: detection and emergency renewal

Mon, 01 Jan 0001 00:00:00 +0000

An expired SSL certificate on NGINX is an immediate outage, not gradual degradation. Browsers and API clients reject the connection at the TLS handshake, often before NGINX logs anything useful. The fix is rarely as simple as running a renewal script again. Verify what is on disk, confirm the running configuration is using it, and force a reload so workers load the new certificate.

NGINX loads certificates at configuration parse time. Workers present whatever the master loaded at startup or during the last reload. Replacing the PEM file on disk does not change what active workers present. Only a reload or restart pulls the new material into memory. If a reload fails, NGINX continues serving with the previous configuration, which still holds the expired certificate. Old workers continue until their connections drain, so even after a successful reload, long-lived connections may briefly present the old certificate.

vCenter '503 Service Unavailable': the vSphere Client will not load

Mon, 01 Jan 0001 00:00:00 +0000

A 503 from the vSphere Client means the reverse HTTP proxy (rhttpproxy) accepted the TLS connection but could not reach the backend it routes to. The proxy itself is healthy. One of its dependents, typically vpxd, vmware-vapi-endpoint, vmware-stsd (STS), or the HTML5 client backend (vsphere-ui), is stopped, still starting, or crash-looping. The error string often reads “Initialization of one of the components failed.”

Running VMs are unaffected. The hypervisor plane keeps scheduling and serving I/O. What you lose is the management plane: DRS stops rebalancing, HA cannot be reconfigured, vMotion orchestration is gone, and provisioning is blocked. The urgency is operational visibility and control, not workload survival.

vCenter 'Cannot complete login due to an incorrect user name or password': SSO failures

Mon, 01 Jan 0001 00:00:00 +0000

The “Cannot complete login due to an incorrect user name or password” string is the exact message operators see in the vSphere Client, in PowerCLI sessions, and in API responses when SSO authentication fails. The text is misleading: the cause is rarely a typo. For a single user it is usually a credential or permission problem. For every account at once it is an SSO/STS infrastructure failure.

The first triage question is scope: does the local SSO administrator account (administrator@vsphere.local) still work? If yes, the STS signing certificate and token service are healthy, and the problem is in an identity source (AD/LDAP) or a service account. If administrator@vsphere.local also fails, the STS infrastructure itself is broken: expired STS signing certificate, clock skew rejecting SAML tokens, or STS memory pressure.

vCenter certificate expired: the STS signing cert outage nobody saw coming

Mon, 01 Jan 0001 00:00:00 +0000

vCenter is down. Not “slow” or “degraded.” Down. The vSphere Client shows a white screen or a 503. PowerCLI sessions fail to connect. API calls return authentication errors. ESXi hosts show as disconnected in bulk. Every integration that depends on vCenter (NSX, vRA, SRM, backup products) has lost connectivity simultaneously. VMs on the hosts are still running, but you cannot manage, migrate, or orchestrate anything.

You check the browser certificate on the vCenter URL. It looks fine. Months left. You check NTP. Synchronized. You check disk space. Plenty. Nothing in your standard monitoring explains why the entire management plane went dark at once.

X.509 Certificate Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

X.509 Certificate Monitoring

What Is an X.509 Certificate?

X.509 certificates are critical to internet security, setting the foundation for a secure online experience. These certificates verify identities through digital signatures, establishing secure communication channels via protocols like SSL/TLS.

Monitoring X.509 Certificates with Netdata

With Netdata, monitoring X.509 certificates becomes an intuitive and streamlined process. Netdata’s X.509 certificate monitoring tool stands out by providing real-time insights into your certificates’ expiration times and revocation statuses.

X.509 certificates Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

What are X.509 certificates?

X.509 is an International Telecommunication Union (ITU) standard defining the format of public key certificates. X.509 certificates are used in many Internet protocols, including TLS/SSL, which is the basis for HTTPS, the secure protocol for browsing the web. They are also used in offline applications, like electronic signatures.

Monitoring X.509 certificates with Netdata

The prerequisites for monitoring x509certificates with Netdata are to have x509certificates and Netdata installed on your system.