Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Sebastian Tiedtke
    @sourishkrout
    Have you tried step certificate install yet?
    Michael Malone
    @mmalone
    and in your local app store
    Aaaand. HELLO to anyone who joins this channel. Welcome. As you can see, we just created this space. The smallstep gang’s all here though, and we’re looking forward to questions & comments & feedback & whatever else is on your mind. ✌️
    Asanka Dissanayake
    @asanka88
    Hi All, when I use step ca certificate to generate a key and cert , validity period of the cert is 1 day
    how can I pass the validity period when I create the cert
    Michael Malone
    @mmalone
    There’s a -not-after flag that can take a duration like 72h.
    Try step help ca certificate for other options, btw
    It’s usually best practice is to keep cert lifetimes as short as possible though, so another option is to leave it at 24h and use step ca renew (possibly with -daemon flag)
    Sebastian Tiedtke
    @sourishkrout
    By the way, please see https://github.com/smallstep/certificates/blob/seb/custom-claims/examples/README.md#custom-claims-for-provisioners-certificate-validity-etc if you want to change the default validity or extend the max validity on the CA
    Mariano Cano
    @maraino
    @asanka88 see @sourishkrout link and https://github.com/smallstep/certificates/blob/seb/custom-claims/docs/GETTING_STARTED.md#whats-inside-cajson where you can find the description of each claim
    mattiasvh
    @mattiasvh
    Hi, I am testing the step commands, really nice tool!
    I have a question about step ca renew srv.crt srv.key
    once the certificate is expired, how can I renew it?
    response is: cannot renew an expired certificate
    Max
    @dopey
    Hey @mattiasvh, in essence that response is correct, although it sounds like we should be doing a better job of recommending the next step.
    Once a certificate has expired there is no way to renew that certificate. You have to get a new certificate using step ca certificate.
    You can setup 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.
    You can also do 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.
    Michael Malone
    @mmalone
    is there some other behavior you’d want / expect? definitely open to ideas.
    mattiasvh
    @mattiasvh

    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?

    Michael Malone
    @mmalone
    So basically make the cert renewable once after expiration..? The problem is that certs would effectively become permanent. The current setup ensures that expired certs are worthless — they’re no longer a security concern. But allowing renewals after expiry would make them a permanent liability.
    That said, you’re not the first person who has brought this connected / embedded device issue to our attention... it’s hard. Doing what you’ve proposed may be the only answer if you really need this to be completely automated and can’t do any sort of manual approval and don’t have any other way to do trusted re-bootstrapping.
    (E.g., a trusted platform module)
    I do also wonder what the benefits of allowing renewal after expiry are vs just extending the expiry to something much longer..?
    I guess with renewal-after-expiry you get some assurance that the cert hasn’t been exfiltrated since we’d only allow renewal once per cert
    Michael Malone
    @mmalone
    We’ve been talking to Twilio about Trust Onboard (https://www.twilio.com/docs/wireless/trust-onboard) which is a really simple TPM embedded in their SIM cards. It gives you a private key that’s non-exportable from the SIM hardware. It’s not ideal for direct use for a variety of reasons, but it’s perfect for bootstrapping into a PKI. So with something like that you could, say, allow renewal-after-expiry but only if you’re also able to sign an assertion with the TPM private key… sort of multi-factor. But I’m not sure how prevalent this sort of capability is in embedded devices & it would require some more integration work relative to allowing renewal after expiry.
    mattiasvh
    @mattiasvh
    Hi Michael, thanks for the interesting feedback
    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?
    Michael Malone
    @mmalone
    I think it would be the latter — the TPM would hold a “provisioner key” that could be used to request a new certificate. We’d need to build TPM support into 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.
    Just allowing renewal after expiry would certainly be easier :P
    Question: do your devices have resolvable hostnames? We’re very close to releasing ACME support in 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.
    Michael Malone
    @mmalone
    Another question: I think this is a really interesting use case and I wanna learn more about it and what you think is the right answer. If you’re interested I’d be down to hop on a video call some time and talk through some options. Also happy to keep the convo here if this is better for you. Just trying to solve for the 12 hour lag :)
    mattiasvh
    @mattiasvh
    Thanks for your proposal (and current state of step in supporting this flow).
    The ACME protocol of Let's Encrypt would not solve our problem, because the embedded devices do not have a resolvable hostname.
    I think a video call would be great, I will send you a private message
    Ben Agricola
    @benagricola
    Q: any plans to allow provisioner creation remotely via API? (or at least allow setting provisioner claim settings from 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 :)
    Michael Malone
    @mmalone
    Yes! That’s definitely in the plans. We need to figure out how to authenticate those requests though.
    Michael Malone
    @mmalone
    On the command line a tool like jq can help automate things for now, assuming that’s what you’re trying to do :/
    Ben Agricola
    @benagricola
    Don't have an automated process for provisioners yet, but I'm familiar with jq and wouldn't be too hard, no - but early in the journey using the smallstep ca :)
    Michael Malone
    @mmalone
    Cool! We need a ticket or two (one for command line another for API) and should collect use case(s). I can think of at least two ways to authenticate: using a provisioner to sign a request or using mTLS with a client cert issued by a provisioner.