Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: x/crypto/acme/autocert: add mechanism for providing a private key for a new certificate #63124

mjl- opened this issue Sep 20, 2023 · 1 comment
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues


Copy link

mjl- commented Sep 20, 2023

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.

@mjl- mjl- added the Proposal label Sep 20, 2023
@gopherbot gopherbot added this to the Proposal milestone Sep 20, 2023
Copy link

mjl- commented Sep 20, 2023

CC @FiloSottile @rolandshoemaker @golang/security
(Copied from an earlier issue for autocert, not sure if I should be doing this or it should be triaged by someone from the Go team)

@ianlancetaylor ianlancetaylor added the Proposal-Crypto Proposal related to crypto packages or other security issues label Sep 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Status: Incoming

No branches or pull requests

3 participants