The operating system my web server runs on is (include version):
Linux -- Ubuntu 18.04 LTS
My hosting provider, if applicable, is:
Amazon AWS
I can login to a root shell on my machine (yes or no, or I don’t know):
Yes
Both Pebble and Boulder return 2 certificates (client certificate, intermediate-CA certificate), but not the Root-CA certificate.
I want to bundle all 3 certificates in a PKCS7 pem file, and with Pebble, I can easily do this.
Pebble provides an endpoint /root to download the Root-CA certificate, but Boulder does not seem to provide an equivalent endpoint. (Am I missing it?)
When testing Boulder, the Root-CA certificate seems to be taken from this file:
test/test-root.pem
But in production, … how is a client expected to obtain a copy of the Root-CA (that was used to sign the Intermediate-CA certificate, which is used for signing client certificates) ??
The answer most likely would be: it isn't expected to obtain the root certificate at all, as the client would have that certificate already in it's trusted root certificate store.
Boulder may at some point start sending the ISRG-signed intermediate instead of the DST-signed one, which would mean that the root involved would be changed.
You should look at the intermediate you receive, and look at the issuer of the intermediate. That's all that the ACME protocol guarantees.
Perhaps I was unclear. I was asking about x509 certificates, not public+private key pairs.
I was expecting there to be a self-signed Root-CA certificate, containing only the public key, … in the same way that client and intermediate-CA certificates only contain public keys.
You can fetch it in an ad-hoc way from https://letsencrypt.org/certificates/ , but I think the “programmatic” way to do it would be to look at the issuer key, and locate it in your trust store.
Edit: The DST PEM is a bit hard to find on that page, you can get it from here.
Yes, I understand for LetsEncrypt it will already be in the trusted root certificate store, … but for running Boulder, the root-CA certificate won’t be in the trusted store. I thought that was one of the reasons Pebble makes the root-CA certificate available through an endpoint, … so I was hoping Boulder would be compatible. It sounds like that’s not the case.
Yeah, part of the whole concept of a PKI is that you generally don’t need to tell people about root certificates.
As is often said, if they trust the root certificate, then they already trust it, while if they don’t trust it, being told about it won’t convince them to trust it.
So for example, for the DST Root and ISRG Root, Let’s Encrypt doesn’t tell people about those because users must already have one of them installed in advance as a trusted root in order to accept Let’s Encrypt certificates. If they don’t, then they should reject Let’s Encrypt certificates because they have no basis for trusting them (unless they performed their own investigation of Let’s Encrypt’s certificate-issuing practices, in which case they could choose to directly trust the Let’s Encrypt intermediate cert, which is served up by the Let’s Encrypt ACME endpoint).
The certificate chain that Let’s Encrypt provides users is essentially “things that clients may not know about yet but that, if they see, they’ll most likely accept”. Including any root certificate wouldn’t align with this because either the client already knows about a root, or the client shouldn’t accept that root.
This is also the case in a private PKI! The clients that are going to consume the certificates should already have had the appropriate roots or intermediates distributed to them via some other channel. Boulder doesn’t have a way to facilitate that channel from software in part because it represents an organizational problem that probably can’t be solved by software (although perhaps in cases of centralized administration of desktops, there might be software tools that would be relevant and someone could create a tool to integrate with Boulder somehow in order to push out an organizational root).
In the latter case, the root still isn’t needed at issuance time for the individual end-entity certificates, but rather when the Boulder instance is created and configured (whatever mechanism will be used to distribute the root should then begin to be used in conjunction with the new CA).
Yes, it all makes sense. Thanks for taking the time to walk though it in detail.
Out of curiosity, … for a private PKI, when the Root-CA changes (because it expired, or because of key compromise, or whatever), what would be the normal mechanism for conveying the new Root-CA to client software? I am thinking of an IoT scenario where you’re possibly never updating the client software (in contrast to regular updates to web browsers).
Whatever trust anchor(s) you use to update your devices (including updating the trust store), need to be valid for longer than the useful lifetime of the device.
Key compromise of the trust anchor is just game over in general, I believe.
If you look to Let’s Encrypt specifically, they keep the actual ISRG Root X1 (which is valid through 2035) in secure offline storage, and only take it out to sign new intermediates. So the chance of key compromise is minuscule.
The intermediates have a much shorter validity period and are kept online in HSMs for use by Boulder. If they are compromised, new intermediates can be issued without having to update everybody’s trust anchors.
A similar set of practices is probably good for IoT as well.
Just for clarity … Yes, the root root private key is kept securely offline, … but of course the root certificate (containing the root public key) is intended to be very public and widely known.
This is a confusing, or misleading, statement to me:
Yes, public certs are intended to be public - to the entire public (Internet).
But public certs are generally not (always) "known"; they are learned, used or not (based on who certified their authenticity), and then discarded.
Only trusted roots are (always) "widely known".
I wrote that phrase in reaction to @Osiris who said “root certificates … are securely saved offline”, as if to suggest that public viewing of root certificates was somehow a security risk, which it isn’t.
As you point out, the certificates of trusted Root-CAs (such as LetsEncrypt) are indeed “widely known”.
If you are developing an IoT product, it is critically important that you make provisions for updating the client software. Otherwise there is no way to patch vulnerabilities, and your deployed IoT devices can be exploited to become part of a botnet, or simply to betray their owners' interests by leaking their data.
Even just from the perspective of PKI it's important that you maintain the ability to update trusted roots. There was an important recent transition in the WebPKI from SHA-1 to SHA-256. It was held up by the fact that some payment card vendors had deployed devices that only supported SHA-1 and could not be updated.
Can you explain more about why you want to deploy non-updating IoT software?
Just like the payment card vendors you mentioned, it seems common among “device” manufacturers to avoid updates. There are lots of reasons behind this: (1) it’s easier since you don’t need to figure out a secure method to update 1 million remote devices, (2) it gives a (false) sense of security since the software is “locked down”, and (3) the device has a limited lifetime anyway, so customers can just buy the next version when updates are needed (good for business).
I agree with concerns about the trusted roots and patches for vulnerabilities. I am working on the CA aspect of the project, and I’ll have to convince the device folks to follow your advice.
Well, I believe the payment card providers had to rush-ship huge numbers of replacement devices at presumably great expense, so it’s not always good business to ship non-updateable software.
Thanks for trying to convince your colleagues to ship an update channel! I very much hope you are successful. You can raise the specter of the Mirai botnet too if they are still reluctant.
