[Suggestion] reuse existing private key when auto-renewing certificates (--reuse-key)

What would you like to be added or improved?

Support reusing the existing private key when auto-renewing certificates.

Currently, when SafeLine issues or renews a certificate for a site, it generates a new private key each time. The resulting public key hash changes with every renewal.

Any one of the following would address this:

1. Reuse the existing private key on renewal. Both certbot (--reuse-key) and acme.sh support this natively — the public key hash then stays stable across renewals.
2. Allow uploading an existing private key, and have SafeLine issue/renew certificates against it.
3. If either is too costly to implement, even a note in the site configuration UI mentioning that automatic issuance generates a new private key would help.

Why is it needed?

My Android app uses OkHttp's CertificatePinner (SSL pinning), which pins the server's public key hash. This is common practice on mobile, especially in finance, government, and enterprise apps.

After migrating to SafeLine from another reverse proxy, SafeLine automatically issued a new certificate. The certificate itself is perfectly valid, but the new private key meant the public key hash no longer matched the pin, and every request from the app started failing:

javax.net.ssl.SSLPeerUnverifiedException: Certificate pinning failure!
  Peer certificate chain:
    sha256/EyRv2xw3E4RCcANRz5UN2T2hcQQfyxaREKmMIay5+Ck=: CN=api.example.com
  Pinned certificates for api.example.com:
    sha256/dneebek0Xi/6iBKTHpVdcUHz5mypqEbqcv6SE+HpvaY=

Two things made this hard to diagnose:

• The failure happens during the TLS handshake, so requests never reach the server. There were no access logs in either SafeLine or the backend.
• Every server-side test passed normally — curl and browsers don't perform pinning, so they gave no indication anything was wrong.

The impact is significant: all app clients fail at once, and the problem recurs on every renewal. Users who aren't aware of this behavior are likely to spend a long time looking in the wrong place.

Supporting --reuse-key should be a small change, but it would prevent this entire class of problem.

Thank you for the feedback. We confirm that SafeLine does not currently guarantee that the certificate private key or SPKI public key fingerprint remains unchanged across ACME renewals. This can affect clients that use certificate pinning.

We will evaluate reusing the existing certificate private key during ACME renewal as a compatibility enhancement. There is no confirmed timeline yet. Until then,applications that require a stable public key fingerprint should manage the certificate private key externally and update the certificate through manual upload.