I’m rolling out an internal PKI for an organization having several use cases where it’s not possible to deploy an agent, such as Certbot, on hosts. These devices not supporting an agent, include, but are not limited to F5 LB’s, Cisco IOS, Cisco ISE, printers, power management (APC), and the list continues. Most of these services can utilize an api to submit and sign a csr, and/or they require specific certificate enrollment protocols, such as EST, CMP etc. With that said, I’ve rolled out Let’s Encrypt using Certbot in a previous life, however, this setup won’t comply with the use cases above. Considering this design factor, does Let’s Encrypt expose an API to submit/sign a csr and auto-retrieve the certificate? Also, just to confirm, are there any plans to support certificate protocols, such as EST, CMP etc?
Letsencrypt supports and uses the ACME-protocol.
Uploading a CSR and downloading the certificate is the last step.
Certbot is only one client and uses the ACME-protocol.
So you can create your own client and use it.
Check the list of libraries:
Given the popularity of Let’s Encrypt/ACME and the increased reliance on proper TLS certificates across the industry, you will likely start to see those device vendors including native ACME implementations eventually. But it’s going to take a while.
In the meantime, your only real option is to have an intermediary host running the ACME client that can take care of getting the cert and then uploading it to the device via its API. For cases like this, it’s usually also easier to use DNS-based challenges.
You named Cisco, some of their devices already support ACME:
From X12.5 the Cisco Expressway Series supports the ACME protocol (Automated Certificate Management Environment) which enables automatic certificate signing and deployment to the Cisco Expressway-E from a certificate authority such as Let’s Encrypt
Also, if you have an older network device which only supports EST, CIMP etcera, nothing prevents you from creating a EST/CIMP <–> ACME wrapper where the ACME validation happens between your ACME wrapper and LE ACME Server, and then the ACME wrapper makes the complete certificate available over EST/CIMP.
An advantage of this is that only the ACME wrapper needs to be “exposed” to the internet to be able to complete the validations.
This is an interesting approach. Thank you.
I’m familiar with ACME, but my main concern is actually even using Let’s Encrypt to do the signing considering the rate limits/availability concerns. This org has hundreds of hosts, which if I enforce a low validity period (e.g. 7 days), the amount of signing is quite substantial. With that said, it seems appropriate to pivot away from using Let’s Encrypt to deploying a true internal pki.
Good idea, although as mentioned above, this org has hundreds of hosts, which if I enforce a low validity period (e.g. 7 days), the amount of signing is quite substantial. With that said, it seems appropriate to pivot away from using Let’s Encrypt to deploying a true internal pki. I’m still able to use ACME, but it seems creating my own root ca with an intermediary using acme for the cert life cycle is best outside of using Let’s Encrypt.
Maybe you could have the ACME wrapper only request ONE certificate, that is then reused across devices. As I understand, EST/CIMP does request a full certificate including private key from the server, thus the ACME wrapper does not need to take in consideration that different devices might “want” different public keys.
You could just serve all your devices the same cert & keypair.
True. It’s definitely a design consideration, although need to find that balance with security. If any of these keypair’s become compromised then that would affect the entire fleet. Of course, this could be offset with low validity periods.
The best here when managing large amount of devices which needs to be provisioned with something security-sensitive, like a keypair or password, is to group them in “trust groups”.
A “trust group” is then a group of devices, which share something in common that makes them trust each other.
For example, if you have devices which are owned or managed by the same entity, they could share the same trust group, so if you provide services for both organization A and organization B, and A and B have a fair amount of customer-premises devices, you could have all devices belongning to A, share a keypair, and all devices belongning to B, share a keypair, and then have a third keypair for devices that are yours and are shared between the 2 customers.
Or if they are in the same location (same facility, or even in the same rack cabinet) they can share the same trust group, and thus share keypairs and passwords, while devices in another physical location, can have another trust group, and thus share keypairs within this location, limiting the number of keypairs to the number of physical locations.
Or if the devices logically have same security level, they can aswell have the same trust group, for example if you have a couple of devices meant for WAN, some devices meant for DMZ, some devices for Public_wifi, and some devices for LAN, and then some devices meant for Manager_TOPSECRET, you can create 5 trust groups out of this, and then you only need 5 keypairs.
These can also be combined in different ways to create interesting trust groups to in a good way managing the security WITHOUT having to manage endless amount of keypairs or passwords or whatever.
This also avoids the need to use low validity periods, as it doesn’t affect a security boundary if a key gets compromised.
Another trick, is to use validity times that aren’t a multiple of another validity time, thus ensuring that the certificates are renewed in such a way you almost never hit into a ratelimit.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.