And if you pin, never pin a single CA, but always pin a secondary, backup CA.
1 Like
Here are some reasonable things you might choose to do, all of them incur a risk, but you can understand and manage the risk, if you feel it's worth the benefit which I'll explain:
You could pin leaf keys. The idea here is, rather than pinning a certificate, your clients are checking that the public keys in the certificate they're shown are always from a small set you've chosen. You (perhaps an ACME client like Certbot on your behalf) pick random key pairs, but you can choose these in advance, and pin your clients to these keys. Say you have three, the one from the certificate you've got right now, one you intend to use when renewing and then one kept on standby in case things go wrong. If you change the keys every 60 days or so, this could be practical if you can update client pins every month or two at most. But Let's Encrypt does not force you to use new keys every time, if you're confident the private keys can be kept safe by your systems for a longer period you can keep using the same keys for new certificates, Certbot doesn't do this by default but it's a valid choice.
The risk of that approach is a client doesn't get updated before you have to change keys, for whatever reason, and then you're in the same place you are now. The benefit is, a bad guy who persuades any public CA including Let's Encrypt to issue them a certificate, whether by attacking a CA or you, does not break your security so long as they can't get your private keys. No other keys can work. A problem is that your tooling may not provide a nice way to pin to the leaf keys.
You could pin to leaf certificates, but refresh your clients frequently with newly trusted leaves, before you then roll those new certificates out to your servers. So e.g. you ask Let's Encrypt for renewed certificates every 30 days, you add these new certificates to your pinning (so it accepts either the current or next certificate) and then a month later you roll to that certificate.
The risk of this approach is if anything goes wrong your timeframes are quite tight. You are never more than 60 days from total disaster. You can't have "spares" on stand by like in the previous scenario because the certificates are issued and expire. Benefit: Again bad guys can't just get certificates and have them work. It's more likely your existing tooling can allow this approach to work.
You could pin to root CAs. You can choose a root (not an intermediate) and pin to that. Your clients will then only trust certificates from that root. This could make sense if you're quite sure you trust, for example, ISRG (the organisation which runs Let's Encrypt) but not most other public CAs. You should definitely choose at least two CAs which are not ultimately controlled by the same people, as grave problems can sometimes result in rapid distrust of all CAs under common management, and you might want to pin more than one root controlled by each CA you trust.
The risk from this approach is that your clients can't distinguish your legitimate certificates from the CA you trust from any other certificates issued by that CA. No matter how bad guys were able to obtain such a certificate, it will match the pin and work. The benefit is your don't have to worry about problems at any other CA at all, they're now irrelevant to you. NB You don't need to actually get certificates from your second (or third) trusted CA, they're your safety backstop. You should however periodically check they are still publicly trusted and can offer you service as it'd be a problem if you realise that your backstop went out of business a year before you needed them.
4 Likes
Wow, super useful @tialaramex, thanks a lot for your feedback on this. We're going to study it carefully to choose the best path moving forward.
Also to @JuergenAuer and @Osiris for their help.
Let's encrypt community rocks!
Further to @tialaramex's great list of options:
If you're developing the only software that ever consumes the certificate (so that it's not also accepted by web browsers, or something), then you could also issue your own certificate (not using a public certificate authority) and then pin that in your application.
Publicly-trusted CAs are able to issue certificates that are automatically trusted by a wide range of third-party software, but if you don't need that trust relationship for your application, there might be no reason to use a public CA at all!
5 Likes
Thanks @schoen, we'll take note!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.