Find SSL certificates and private keys on Linux

Start with the service configuration. Linux has conventional certificate directories, but there is no single path that every TLS service must use. A system CA trust store, a website's certificate chain, and its private key serve different purposes.

Common locations

These are starting points, not guarantees. A container may use mounted secrets, and an application may keep files under its own directory. Certbot's configuration directory can be changed; its certificate name may also differ from the exact domain name.

In a normal Certbot lineage, cert.pem contains the leaf certificate, chain.pem the intermediate chain, fullchain.pem both, and privkey.pem the private key. The files under live/ are symlinks into archive/. Preserve the renewal configuration and relevant directory structure when backing them up.

Read the configured paths

# Run with sufficient privileges; the full configuration may contain secrets.
sudo nginx -T 2>&1 | grep 'ssl_certificate'

# Debian-style Apache layout; use /etc/httpd on many RHEL systems.
sudo grep -R 'SSLCertificate' /etc/apache2/

Nginx normally uses fullchain.pem for ssl_certificate and privkey.pem for ssl_certificate_key. Apache 2.4.8+ can also load the leaf and intermediate chain through SSLCertificateFile.

A targeted filename search can help when the configuration is unavailable:

sudo find /etc -type f \( -name '*.pem' -o -name '*.crt' -o -name '*.cer' \) -print

This does not find every certificate: symlinks, extensionless files, external mounts, and non-file stores need separate inspection. A filename extension does not determine the object type or encoding. Use openssl x509 -in server.crt -text -noout for a PEM certificate, or add -inform DER for a known DER certificate.

Preserve the key's access controls

A root-owned private key with mode 600 is common when the service starts with privilege. A non-root service may need tightly scoped group access instead. Check every parent directory, the service identity, and SELinux or AppArmor policy. Do not apply a universal owner or mode to every distribution's private-key directory.

Public certificates can usually be readable by others; the private key cannot. If it has been exposed, generate a replacement key, reissue the certificate, revoke the compromised certificate as appropriate, and investigate the exposure. Renewal alone does not necessarily replace the key or revoke the old certificate.

Finally, check the certificate served by the endpoint. A renewed file does not prove the running process has reloaded it. An SSL test in Guance can check the configured hostname and port and track certificate expiry from its monitoring location.

Reference: Certbot certificate locations.