Autocert currently generates a private key when there is no valid certificate in the cache and a certificate is requested.

I would like the ability to provide the private key for a certificate when it is requested for the first time.

Current prototype: mjl-/autocert@2f3f1ce
I can look into making a CL for this change.

My use case: I am writing a mail server. The incoming SMTP server offers TLS with STARTTLS. Historically there has been no validation of TLS certificates in that situation. Two new opt-in mechanisms now exist: 1. MTA-STS, which requires common-CA-validation (which I already support); 2. DANE, which requires validation against a public key in DNS (in a TLSA record, protected with DNSSEC). When a new domain is set up in my mail server, I plan to generate a private key, tell the user the DANE TLSA record to add to their DNS (after which I cannot easily get a user to change it, especially with rollover), and request a certificate through ACME for the key. This approach should allow validation with both MTA-STS and DANE.

While making the change, I found that autocert appears to reuse private keys for renewals when a valid certificate is present in the cache. Generating a new private key seems like a safer default. TestRenewFromCacheAlreadyRenewed in renewal_test.go has checks about a new private key, but only in the context of another process already having placed a new certificate with new private key in the cache. It does not check if a new certificate with a new private key was requested. The test may be better off checking if the entire certificate from the updated cache is returned.
When an expired certificate is in the cache, it seems to be ignored and its private key not reused for the newly requested certificate. I don't know if the difference in behaviour around private key reuse for expired-and-renewed and preemptive-renewal is intentional, but I found it a bit surprising.