step help ca certificatefor other options, btw
step ca renew(possibly with
step ca certificate.
step ca renewas 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.keywhich 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?
stepor 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-cawhich 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 :)