Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    SahanaJC
    @SahanaJC

    Hi All
    We have a use case where we revoke certificate using step ca and create, renew certificate using dehydrated
    It is seen that certificate is successfully being revoked yet, renew of the same certificate is also happening, which must not ideally according to https://smallstep.com/docs/step-cli/reference/ca/revoke#description
    Please help us resolve this issue, Thanks in Advance!
    Here is the detailed command output:

    [root@gl-seednode-jc dehydrated]# ./dehydrated --domain 'gl-seednode-jc.glhc-hpe.local' --cron --force

    INFO: Using main config file /home/glcgadmin/vmaas-ansible-repo/dehydrated/config

    hook.py: Unknown hook handler
    hook.py: startup_hook
    Processing gl-seednode-jc.glhc-hpe.local

    • Creating new directory /home/glcgadmin/vmaas-ansible-repo/dehydrated/certs/gl-seednode-jc.glhc-hpe.local ...
      hook.py: Unknown hook handler
    • Signing domains...
    • Generating private key...
    • Generating signing request...
    • Requesting new certificate order from CA...
    • Received 1 authorizations URLs from the CA
    • Handling authorization for gl-seednode-jc.glhc-hpe.local
    • 1 pending challenge(s)
    • Deploying challenge tokens...
      hook.py: deploy_challenge for domain gl-seednode-jc.glhc-hpe.local - initiated
      hook.py: deploy_challenge for domain gl-seednode-jc.glhc-hpe.local - succeeded
    • Responding to challenge for gl-seednode-jc.glhc-hpe.local authorization...
    • Challenge is valid!
    • Cleaning challenge tokens...
      hook.py: clean_challenge for domain gl-seednode-jc.glhc-hpe.local - initiated
      hook.py: clean_challenge for domain gl-seednode-jc.glhc-hpe.local - succeeded
    • Requesting certificate...
    • Checking certificate...
    • Done!
    • Creating fullchain.pem...
      hook.py: sync_cert
      hook.py: deploy_cert
    • Done!
      hook.py: exit_hook

    [root@gl-seednode-jc dehydrated]# step ca revoke --cert certs/gl-seednode-jc.glhc-hpe.local/fullchain.pem --key certs/gl-seednode-jc.glhc-hpe.local/privkey.pem
    ✔ CA: https://172.16.5.124:8282
    Certificate with Serial Number 307300703289760345466735924092426714995 has been revoked.

    [root@gl-seednode-jc dehydrated]# ./dehydrated --domain 'gl-seednode-jc.glhc-hpe.local' --cron --force # INFO: Using main config file /home/glcgadmin/vmaas-ansible-repo/dehydrated/config
    hook.py: Unknown hook handler
    hook.py: startup_hook
    Processing gl-seednode-jc.glhc-hpe.local
    hook.py: Unknown hook handler

    • Checking domain name(s) of existing cert... unchanged.
    • Checking expire date of existing cert...
    • Valid till Nov 24 10:07:18 2020 GMT (Less than 30 days). Renewing!
    • Signing domains...
    • Generating private key...
    • Generating signing request...
    • Requesting new certificate order from CA...
    • Received 1 authorizations URLs from the CA
    • Handling authorization for gl-seednode-jc.glhc-hpe.local
    • 1 pending challenge(s)
    • Deploying challenge tokens...
      hook.py: deploy_challenge for domain gl-seednode-jc.glhc-hpe.local - initiated
      hook.py: deploy_challenge for domain gl-seednode-jc.glhc-hpe.local - succeeded
    • Responding to challenge for gl-seednode-jc.glhc-hpe.local authorization...
    • Challenge is valid!
    • Cleaning challenge tokens...
      hook.py: clean_challenge for domain gl-seednode-jc.glhc-hpe.local - initiated
      hook.py: clean_challenge for domain gl-seednode-jc.glhc-hpe.local - succeeded
    • Requesting certificate...
    • Checking certificate...
    • Done!
    • Creating fullchain.pem...
      hook.py: sync_cert
      hook.py: deploy_cert
    • Done!
      hook.py: exit_hook
    Max
    @dopey
    Hey @SahanaJC there’s a few things going on here, but the main issue is that step ca revoke is tied to step ca renew. What I mean by that is, if you use a different method to renew the cert then it doesn’t actually go through the same processes. For example, regular ACME client renewal does not work the same way that step ca renew works. In the ACME protocol when you renew a cert you don’t send in the old cert. You just go through the ACME protocol once more with the same information.
    Basically, step ca revoke only works if you plan to use step ca renew for renewals. For other clients it “probably” will not work because other clients do not send in the old certificate as part of the renewal flow.
    Does that make sense? Consider renewing certificates using step ca renew. It has all sorts of useful flags that allow it to run as a daemon, periodically attempt renewal, etc.
    That’s only if you are relying on the revocation. If you can get by without the revocation then you can continue to use dehydrated with the knowledge that the revocations will not be respected by your ACME client.
    SahanaJC
    @SahanaJC
    Hi @dopey, I tried executing step ca revoke followed by step ca renew. It worked as expected. Thanks!
    Romain Griffiths
    @wid
    Hi everyone, I was wondering if a command to list the certificates from the database was being worked on ?
    Max
    @dopey
    Hey @wid we have a few open issues in opening source tracking that type of feature. Here’s an example: smallstep/certificates#239. The short answer to your question is “no, no one is currently working on this”. If someone from the community would like to pick it up we’d be happy to work with that person or team to point them in the right direction. The longer answer is that this feature will likely be making it into our hosted offering (in the next few months) before we have the time to implement it in open source.
    The biggest hurdle in open source is that we store data in a nosql format (key - value), making it difficult to run any sort of query against the data without writing bespoke scripts to enumerate all values in a table, etc. So if someone wanted to take a look towards converting the storage layer to a SQL backend, that would be a good first step.
    Tomás Hidalgo
    @thidalgosalvador

    Hello,

    In my GCP account, I have distributed an instance of Smallstep ACME Registration Authority for CAS to test the product. The sensations are very good; the deploy has been very fast and easy. Congratulations on the product. One question, can an ACME smallstep server only issue final certificates from a subCA generated in Google CAS? In other words, is the caCAS value unique? Can't it have several values? I mention this because if an enterprise's PKI infrastructure is generated in Google, it is very likely that it is made up of several SubCA's ( my on-premise PKI is made up of four SubCA's, for example, for compliance needs among others... ) Thank you.

    Mariano Cano
    @maraino
    Hi @thidalgosalvador, at the moment one ACME RA only supports one CAS CA, to support multiple ones, multiple instances are required. As we support multiple ACME provisioners it would be possible with code changes to support multiple ones, can you add an issue in https://github.com/smallstep/certificates with your use case?
    Max
    @dopey
    I believe there are already issue(s) in step-ca for giving the ability for each provisioner to use it’s own signer.
    I think this is essentially the same thing.
    Not sure if we need another issue to track it (although this is a more specific use case).
    Kris Fremen
    @krisfremen
    is there any docs on how to get client certificates using JWK?
    Carl Tashian
    @tashian
    Hi @krisfremen, the intention is that you'd run a token server that has the JWK provisioner's encryption key and can sign single-use tokens on behalf of your users, if they are authorized. As long as the CA gets a valid, signed token, it will fulfill the request.
    You can play with step ca token to work out the sort of token you'd want your server to generate.
    (then run step ca certificate using --token to request a certificate from the CA using a token)
    There's an example in our docs that includes a bash script that uses the encryption key for the provisioner to generate a custom JWT for the CA. This is basically what you'd want your token server to do, if the user is authorized.
    Mariano Cano
    @maraino
    And @krisfremen, by default the certificates are valid for client and server authentication.
    etudurd
    @etudurd
    Hello, there is an example of implementing smallstep using keycloak?
    Max
    @dopey
    Hey @etudurd we don’t have any docs for that at the moment, but we do have this open issue smallstep/certificates#110 tracking docs for keycloack, and other OIDC providers.
    James Dadd
    @jamesdadd-nomi
    Hi, I need to configure SmallStep SSH users (synced via OKTA) to access a different default Linux shell when they login. Currently /bin/bash is being used. Is there a way we can configure that?
    2 replies
    korhojoa
    @korhojoa
    Hi, I'm trying to set up step as an intermediate CA for use with ssh login. I couldn't find documentation on how to do that. The intermediate works, step ca health says ok, I don't know what to use to generate the keys that appear with the generated ca and ' --ssh'
    Max
    @dopey
    Hey @korhojoa I’m not really sure what you mean by intermediate CA in the context of SSH certificates. SSH certificates don’t have a “chain of trust”. Just a signing key (root key) that signs SSH certificates. So not sure it would make sense to have step-ca be an intermediate in that sort of setup.
    korhojoa
    @korhojoa
    Ah, okay, yeah, I was wondering how that fits together.
    I currently have step-ca running with an intermediate. trying 'step ssh config' with --root and --ca-url specified, I get: error="getSSHConfig: ssh is not configured"
    etudurd
    @etudurd
    Hello, there is someone who tried to implement SSO via keycloak + smallstep to access ssh servers? I am trying already for 2 weeks but without any success
    thank you :0
    :)
    Max
    @dopey
    Hey @etudurd I believe that KeyCloak is possible, we just don’t have documentation for it (yet). We have this open ticket — smallstep/certificates#110. If you follow through with the KeyCloak integration we’d love to hear about it. KeyCloak, being an OIDC provisioner, should work similarly to Gsuite, Okta, Azure AD, etc.
    Max
    @dopey
    https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/ — we're partnering with yubico to give away five build kits for TinyCA run on a raspberry PI with a yubikey. Details in the post!
    masoudbahar
    @masoudbahar
    That’s indeed a great guide. I’m updating your Helm chart to support offline (existing) root CA and custom EC key length.
    ill publish it in January, probably with an all internal acme solution, if testing proves successful
    ckwalsh
    @ckwalsh
    @etudurd I set up Keycloak+smallstep in my homelab to play around, works fine and didn't run into any issues (besides the aforementioned documentation)
    ckwalsh
    @ckwalsh
    BTW, I want to say thank you to the smallstep team for building such a solid system. I don't have any huge deployment or complex configuration, just a little homelab I was tinkering with over the holidays, but smallstep was easy to set up and start distributing certs. Took a bit to fully grok the relationship of how cert requests work and how to maintain everything, but once I did it's a breeze. I ended up wanting to distribute ssh host certs in k8s, so I expanded autocert to support them, and put up a pull request at smallstep/autocert#24
    Mariano Cano
    @maraino
    @ckwalsh Thanks for the PR I'll need some time to look into it
    1 reply
    ckwalsh
    @ckwalsh
    As follow ups to that PR, I'd like to add more testing, and to add support for sending SIGHUP signals to the primary pod process to reload the certs. I'll wait until you have a chance to review that PR first, as both pieces require touching controller.go, and I don't want to keep moving the review goalposts
    Allen Conlon
    @A1994SC
    Hello, I have been trying to get the tiny-ca rpi system up and running but I am having some issues after getting everything installed and configured. I made a post of r/homelab, link here.
    I have gotten some issues worked out like the ca not using my internal dns server, but now I am stuck on the following error.
    error validating ACME Challenge at https://tinyca.lan/acme/acme/challenge/Rrk1iKFeEjDRkFu0w025Ogty17RsL2R0: client GET https://tinyca.lan/acme/acme/new-order failed: Post "https://tinyca.lan/acme/acme/challenge/Rrk1iKFeEjDRkFu0w025Ogty17RsL2R0": stream error: stream ID 17; INTERNAL_ERROR
    47 replies
    any help would be super useful
    Tony Ashvanian
    @Tony-The-Developer
    hey guys i have step working but the certificates coming our are not verified. Do you have any ideas
    Tony Ashvanian
    @Tony-The-Developer
    image.png
    same with an fqdn
    image.png
    ckwalsh
    @ckwalsh
    @Tony-The-Developer You need to add the root cert to your system and/or browser root store
    Tony Ashvanian
    @Tony-The-Developer
    it has been added.
    it works but the ssl is not verified
    ckwalsh
    @ckwalsh
    Firefox unfortunately disagrees, based on the NET::ERR_CERT_AUTHORITY_INVALID error code. Can you go into your firefox settings and share a screenshot of the root certificate in the list?
    Mariano Cano
    @maraino
    @ckwalsh firefox doesn't use the system truststore, it has its own, you should be able to install it in firefox settings or you can also install it using step certificate install --firefox root_ca.pem