Generate new domain key on renewal. Otherwise, the domain key is not changed by default.
I swear we've had this discussion before. Don't most standard TLS configs have forward secrecy enabled these days? And doesn't forward secrecy basically invalidate most of the argument for rotating private keys on a regular basis since even if the key is compromised you can't decrypt old captured traffic with it?
For what it's worth, Posh-ACME also does not rotate private keys by default (though it can be configured to do so). It was a design choice I probably copied from acme.sh at the time combined with a Windows specific feature I was hoping to use that would prevent the need to restart services after a renewal (which didn't end up working out sadly).
Personally, I treat the decision to rotate private keys the same way I treat the decision to revoke a cert...only on suspected compromise or if some other external factor has deemed the key no longer fit.
Fun fact: When you delete a certificate from the Windows cert store that has a private key associated with it, the private key isn't actually deleted and still exists on the filesystem basically forever unless you know how to find it and delete it.
At one point there was also pressure from some security-interested people not to change subject keys frequently because different alternative ideas for replacing or augmenting the web PKI tried to treat the end-entity certificate, or its subject key, or a hash of either of those, as a user-visible identifier for the site operator. There was something of a golden age for such proposals about 5-10 years ago and I was pretty enthusiastic about several of them myself.
Most of them have fallen by the wayside as Google insisted on CT, while refusing to implement the other proposals in Chrome. The other proposals had many virtues compared to CT, but they all called for significantly more work on the part of the relying party or at least on the part of the service operator, and Google and many other observers didn't see that as practical.
But it doesn't surprise me that people would have the intuition that not changing subject keys frequently is desirable, because someone or something could be using them as identifiers.
Slightly related to this: When Let's Encrypt was first getting organized, the people working on it on the EFF side were encryption advocates, but PKI skeptics. We not infrequently said that a good thing about having a CA would be a front-row opportunity to experiment with new ways to constrain and reduce CAs' power. CT is the main one that's come to fruition, and it was primarily other people's idea. (One of many vestiges of this is the now-removed
--manual-ip-public-logging-ok option in Certbot, which was based on a proposal that the CA's detailed logs of certificate requests and challenge verification might be published for security researchers to examine for possible evidence of misissuance or assessing risks of misissuance.)
Although Let's Encrypt has been a leader in various best practices, I think the hypothetical focus on helping reinvent PKI has mostly fallen by the wayside because just operating the services that Let's Encrypt already offers is so valuable and so much work. If people keep having ideas for new directions for PKI and Internet naming in the future, I hope Let's Encrypt will be open to cooperating with them!
Like ACME account keys, perhaps?
Alrighty, so I downloaded the Let's Encrypt ISRG Root X1 pem and then ran the following command to generate the sha256 signature:
openssl x509 -in isrgrootx1.pem -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
this spat out:
We then added this to our Android app's list of pinned certs and to the Public-Key-Pins headers in nginx, but it's still not working. "Certificate pinning failure!" exception. Am I misunderstanding what is meant by "pin the root certificate"?
Should we just disable pinning? I keep finding stuff saying that's it's been deprecated and should not be used and that Certificate Transparency is now the recommended solution.
I suspect so. At least, the contents of
isrgrootx1.pem are the root certificate itself, while the identifier
C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M= is just a name for that certificate. If your application isn't using a root store that already includes this root, just mentioning
C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M= won't help it become trusted; servers aren't supposed to send roots as part of their certificate chains. (But I don't know the exact reason for your pinning failure.)
Maybe! It's not that unusual for application developers to pin their own certificates (that they issued themselves), but pinning Let's Encrypt certs is just a way of trying to prevent other CAs from issuing certificates for your service at all. Certificate Transparency is a way of trying to detect if they do, which is different from, but related to, preventing it. If your TLS client requires CT, then you can monitor CT logs to find out whether there were any unexpected certificates issues by authorities you didn't expect and that covered your service.
This is probably in reference to HPKP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning) which was a feature for the Web and which yes, you should not use today on web sites. But for software you control (such as a phone app), even if that app actually uses HTTP behind the scenes you are not obliged to necessarily take the same attitude.
Unlike the Web, you may have the power to push out new versions of your software to all its users at regular intervals ensuring any new keys are trusted as necessary. So you don't need to obey the deprecation and can recover from mistakes. I would definitely not recommend this strategy if you aren't confident you understand how it works though, it's definitely an expert feature.