> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/galera-cluster/galera-security/responding-to-a-key-or-certificate-compromise.md).

# Responding to a Key or Certificate Compromise

If a node's private key or certificate is compromised, the goal is to stop trusting it across the cluster as quickly as possible. There are two approaches, which can be combined.

## Revoke via a Certificate Revocation List (CRL)

Only the `SERVER_X509` TLS mode requests and verifies peer certificates (the `SERVER` mode encrypts traffic but does not request a peer certificate), so a CRL applies only in `SERVER_X509`. In that mode, inter-node TLS uses the server's TLS configuration, which supports a CRL through the `ssl_crl` (file) and `ssl_crlpath` (directory) system variables.

1. Add the compromised certificate to the CRL and distribute the updated CRL to every node.
2. Run `FLUSH SSL;` on each node so the new CRL takes effect.

{% hint style="info" %}
CRL checking applies to inter-node traffic only in the `SERVER_X509` TLS mode, which is the only mode that requests and verifies peer certificates.
{% endhint %}

## Reissue from a New CA

For a CA-key compromise, or to invalidate a certificate without relying on CRL distribution, rotate the cluster CA and reissue all node certificates. See [Cluster CA Rotation](/docs/galera-cluster/galera-security/cluster-ca-rotation.md).

## See Also

* [Cluster CA Rotation](/docs/galera-cluster/galera-security/cluster-ca-rotation.md)
* [Reloading TLS Certificates Without Downtime](/docs/galera-cluster/galera-security/reloading-tls-certificates-without-downtime.md)
* [wsrep\_ssl\_mode](/docs/galera-cluster/reference/wsrep-variable-details/wsrep_ssl_mode.md)

<sub>*This page is licensed: CC BY-SA / Gnu FDL*</sub>