by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Michael Malone
    @mmalone
    right, so you’re basically relying on whoever has access to the provisioner-password-file to make the decision about which extensions should be included
    Evil Mog
    @Evil_Mog_twitter
    exactly
    Michael Malone
    @mmalone
    so there would be some logic in the CA… but that logic would basically be something like “copy the ssh_extensions property from the JWT into SSH extensions in the issued certificate"
    Is that right?
    Evil Mog
    @Evil_Mog_twitter
    we were doing it directly with ssh-keygen but it was safer to move the master key off box, and then max out a 1 week issuance time on our signing server
    nope, the JWT is just a straight provisioner, only logic we add to it is don't issue keys more than a week
    basically right now we add ssh authorized principals via --principal blah I'd like the ability to specify --extension blah:blah
    from step ssh
    and if the JWT has permissions for custom extensions
    then just do it
    we did this because we didn't like the way the OIDC provisioners worked so we made our own, and smallstep just needs to interface with ours
    Michael Malone
    @mmalone
    right, so when you do -principal blah what happens is you get a JWT with ”sans”: [“foo”]
    $ step ca token foo | step crypto jwt inspect --insecure
    ✔ Provisioner: mike@example.com (JWK) [kid: Q0ZRGcmEngj7CEPhxOUi0qw4kq0Mh7P0CCmO6sGFY-4]
    ✔ Please enter the password to decrypt the provisioner key:
    {
      "header": {
        "alg": "ES256",
        "kid": "Q0ZRGcmEngj7CEPhxOUi0qw4kq0Mh7P0CCmO6sGFY-4",
        "typ": "JWT"
      },
      "payload": {
        "aud": "https://127.0.0.1/1.0/sign",
        "exp": 1590689549,
        "iat": 1590689249,
        "iss": "mike@example.com",
        "jti": "eb5b99d203b0a8f830667a950eb8ddbab54cd7731b653f12da0de519fceacd6d",
        "nbf": 1590689249,
        "sans": [
          "foo"
        ],
        "sha": "977dc180e3dc79de3290681073580c6e835af26be3b1981723e99ed21c63d3dc",
        "sub": "foo"
      },
      "signature": "CkVKavOm8IsbAGiG5hp321XYDRgNRh04jwzmWz3LSyYwzr7Makjbs13h9yl5X2ZArtsdcdUNCwSMcvGztdUa_A"
    }
    Evil Mog
    @Evil_Mog_twitter
    ok yes, so we basically need full control of the extensions attribute from step ssh
    Michael Malone
    @mmalone
    so I think we’d need to also put extensions in that JWT when you pass -extension
    so the CA knows what to put in the issued cert
    Evil Mog
    @Evil_Mog_twitter
    yeah
    Michael Malone
    @mmalone
    kk
    yea, b/c ultimately what the CA will get is a request with the public key and the JWT, so it needs to map from those two artifacts to a certificate
    Evil Mog
    @Evil_Mog_twitter
    yep, exactly
    Michael Malone
    @mmalone
    kk. lemme try to summarize this in the ticket.
    ah, you beat me to it. thanks! :)
    Evil Mog
    @Evil_Mog_twitter
    no problem
    Joost van Dijk
    @joostd
    I am struggling with an OIDC provider that does not allow ephemeral port numbers on loopback redirect URIs (similar to issues with Okta a while back). I noticed that I can use step ca bootstrap --redirect-url http://127.0.0.1:8080 (or add an entry to config/defaults.json) to specify a redirect-uri, but that doesn't seem to make much difference. Am I misinterpreting the purpose of this option?
    Michael Malone
    @mmalone
    @joostd yea, I think that’s a redirect that happens after the OIDC redirect… it’s confusing. In any case, it’s not what you want. What you want is to add listenAddress to your $(step path)/confit/ca.json on your CA. Your OIDC provisioner in ca.json should look something like this:
       {
          "type": "OIDC",
          ...
          "listenAddress": "127.0.0.1:10000",
          ...
       }
    Joost van Dijk
    @joostd
    Ah, great! Will try that, thanks!
    Joost van Dijk
    @joostd
    Works fine - I now receive the authorization code. One strange thing though: I have "listenAddress": "127.0.0.1:8080" in my ca.json, and the request conveying the authorization code to the redirect URI returns an HTTP 302 with Location: :8080 (and as the local server has stopped listening my browser shows an error message).
    Not a big deal, but I was expecting the "Success/Look for the token on the command line" message I get with step oauth.
    Michael Malone
    @mmalone
    @joostd that’s weird. You should get “Success / Look for the token…” as described. Do you still have the redirect URI in your defaults.json? If so, that’s probably the problem. The redirect-url there is used by step oauth. When the IdP redirects back to the callback URL (http://127.0.0.1:8080 in your case), if redirect-url is set, the little webserver we start on localhost will actually serve another redirect to that URL instead of dispalying the “Success / Look for token…” message.
    we use this with our SSH product so that, after ssh login, we can redirect users to something more helpful than the standard page. You can use it yourself for the same purpose, or just delete that parameter from defaults.json and you should get the default behavior.
    Joost van Dijk
    @joostd
    oops, you are right. I forgot to revert my defaults.json. Thanks!
    Miclain K Keffeler
    @mkkeffeler
    Is there a way to audit all the certs that have been issued for viewing?
    20 replies
    we are trying to see the certs that have been signed by any provisioner
    Adrian L Lange
    @p3lim
    @dopey Hey, just saw your response to my issue, just a quick question: badger is a database?
    46 replies
    Miclain K Keffeler
    @mkkeffeler
    Has anybody documented installing the CLI on RHEL or CentOS?
    9 replies
    Miclain K Keffeler
    @mkkeffeler
    @tashian see above thread, this would be a MUST have that I would be happy to help on, time for a call later?
    1 reply
    Miclain K Keffeler
    @mkkeffeler
    Anybody had luck getting smallstep to put logs on a file on the filesystem? cant find info on doing that online and my usual unix knowledge isn't helping me with this
    Max
    @dopey
    step-ca sends all logs to stdout so you should be able to redirect them to wherever you wanted from there.
    Miclain K Keffeler
    @mkkeffeler
    [root@pr-flex001-ic01 smallstep]# /bin/step-ca /root/.step/config/ca.json --password-file=/root/.step/pwd > /var/log/smallstep/output.log
    2020/06/02 17:31:16 Serving HTTPS on :18443 ...
    {"duration":"267.658µs","duration-ns":267658,"fields.time":"2020-06-02T17:31:51-05:00","level":"info","method":"GET","msg":"","name":"ca","path":"/provisioners?limit=100","protocol":"HTTP/2.0","referer":"","remote-address":"169.198.76.182","request-id":"brbd6lsaglbo888rk5kg","size":894,"status":200,"time":"2020-06-02T17:31:51-05:00","user-agent":"Smallstep CLI/0.14.4 (linux/amd64)","user-id":""}
    {"duration":"104.561µs","duration-ns":104561,"fields.time":"2020-06-02T17:31:51-05:00","level":"info","method":"GET","msg":"","name":"ca","path":"/provisioners/FBp5TS_4REH5-yKUZnxdufuQvI-CQE97KnvMORjMpwI/encrypted-key","protocol":"HTTP/2.0","referer":"","remote-address":"169.198.76.182","request-id":"brbd6lsaglbo888rk5l0","size":586,"status":200,"time":"2020-06-02T17:31:51-05:00","user-agent":"Smallstep CLI/0.14.4 (linux/amd64)","user-id":""}
    and >> fail to do the trick
    that was why I was confused, cuz I wouldve thought the same thing
    and the log file doesnt have output
    Miclain K Keffeler
    @mkkeffeler
    was missing 2>&1
    sorry
    Miclain K Keffeler
    @mkkeffeler
    ?
    Miclain K Keffeler
    @mkkeffeler
    Also, is there a way to default sign certs using 4096 bytes and then the exception be 2048?
    Max
    @dopey
    I think that documentation is nabbed directly from our README: https://github.com/smallstep/certificates#debian.
    Unfortunately the default rsa key size is hardcoded. That’s something that’s probably worth allowing users to set at the authority and provisioner level.
    Michael Malone
    @mmalone
    @sebageek I think we talked a while back about name constraints on root certificates. Have you tested or moved forward with that idea? I was playing around with a CA with name constrained roots the other day and found that Chrome appears to not respect name constraints on root certificates. I think this is a limitation of the underlying NSS library. See https://bugs.chromium.org/p/chromium/issues/detail?id=1072083&q=name%20constraints&can=5, for example. Any thoughts?