step - the open source zero trust toolkit to securely connect and operate your apps (we’re on Pacific Time)
step help ca certificate for other options, btw
step ca renew (possibly with -daemon flag)
step ca certificate.
step ca renew as a daemon so that it continuously renews the certificate before 2/3 of the lifetime of the certificate has elapsed: step ca renew --daemon internal.crt internal.key.
step ca renew --daemon --exec "nginx -s reload" internal.crt internal.key which will continuously renew the certificate and sighup a process (in this case nginx) every time the certificate is renewed.
Hi, yes I understand the flow of automatic renewing, which is great when the systems have constantly internet connection.
But I have a use case in which we want to use TLS on embedded systems (mTLS for example) which do not have constantly internet connection. So it happens a lot, the embedded devices have only internet access again (to be used for certificate renewal towards intermediate CA) after the lifetime of the certificates (embedded system was powered down for 1 month for example) -> so certificate is expired. In this situation the embedded systems are not accissible anymore (no TLS connection possible anymore -> so manual intervention would be needed with current flow of step).
I think it would be a good addition if theses embedded devices can do a renewal of their expired certificates based on the "exceptional" condition: lifetime of certificates are expired, but the devices can prove they have the last valid certificate for this subject of the certificate -> Intermediate CA trust this "exceptional" condition and executes a renewal of the certificates. After this, the embedded systems can use the regular renewal flow of 2/3 of lifetime.
Condition when the intermediate CA does not have to trust this exceptional condition: When there were multiple attempts of certificate renewal for this subject of the certificate or when the devices do not use the last (expired) valid certificate.
What do you think of this idea? Or is this a bad idea and an alternative solution with step exists already?
The idea of extending the expiry is great, we were also thinking this could be already a partial solution in most conditions, but still there will be exceptional cases which are not covered (if the device is powered down for a very long time.)
Your proposal of using TPM is a good idea, actually we have the possibility to use TPM module on these devices (currently not active yet). What would then need to be adapted to get this flow working with step? currently it is impossible to do renewal after expiry by the step tool on the embedded device. Does the renewal have to be extended? Or do we then have to use the flow for requesting a new certificate (with provisioner) by using some signing from the TPM?
step or you’d have to generate provisioning tokens some other way (not too hard, since they’re just JWTs, but also not trivial). The other issue is that provisioners are currently all-or-nothing: a provisioner can issue certificates for any identity. So each device would be able to get certificates for any other device. So that’s not ideal, and we’d probably have to lock that down somehow… Finally, there’s no API for adding and removing provisioners. You have to run a command to modify a JSON configuration file at the CA and you need to HUP or restart the CA to pick up the change.
step-ca which would allow a device to request a certificate for a fully-qualified domain name if that domain name resolves to the device’s IP address… ACME is the protocol that Let’s Encrypt uses.
step ca provisioner create)? Rest of the process is almost seamless but setting up multiple provisioners (and realising you need to HUP / restart the CA) was not quite as obvious :)