[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.

Trace SafeLine's automatic certificate issuance and renewal path, then inspect how its certificate tooling is invoked. Determine where an existing private key could be retained or supplied during renewal, and review the site configuration UI if documentation is the chosen fallback. Done means renewal can preserve the public key hash, or the UI clearly warns that automatic issuance generates a new key.