Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    @Tony-The-Developer ^=
    Michael Shamash
    @mshamash
    Hi all, I was looking for some input on exposing a DIY CA (following smallstep's guides) to the internet directly? In theory if I use ufw to allow only port 443 and also set my network's firewall rules accordingly, it should be secure enough... Ideally I'd like to be able to generate SSH certificates from anywhere (whether I'm at home, which is 90% of the time these days, or out) to connect to my hosts. I've tried using Cloudflare, but testing with the step ca certificate command yielded x509: certificate signed by unknown authority errors. I guess I could also setup VPN to my home network (where the CA is hosted) and connect via VPN for SSH cert generation once per day if I'm not home, too...
    15 replies
    Michael Shamash
    @mshamash
    Hi, sorry for the continued messages, but I've come across another question when working with step's SSH certs. I've also got some feedback on the step-ca docs but am not sure where to send it, or if you'd like me to send some here.
    In any case, I've managed to get my SSH cert CA up and running and working with 90% of my hosts. I then had the thought to implement it with my GitHub account (non-enterprise), since GitHub can use SSH keys for authentication. Ultimately, I'm hoping that every time an SSH cert is generated on my machine, I'd setup a script so that it would replace the previous SSH cert on my GitHub account, so that way I'd have SSO for GitHub as well, in a sense.
    In my preliminary testing, I have been trying to add my SSH cert public key to my Github account online manually and then testing with their ssh -T git@github.com test. I've been extracting the currently active step SSH public key like this step ssh list --raw | step crypto key format --ssh on my local machine, with output looking something like this ecdsa-sha2-nistp256 AAAAE2VjZHNhLXN..., then adding it to my github account. However, that didn't seem to work and I keep getting Permission denied (publickey). errors when testing SSH. I've also tried uploading the output of step ssh list --raw, but their web UI didn't like that, even after changing the ecdsa-sha2-nistp256-cert-v01@openssh.com head to ecdsa-sha2-nistp256.
    I guess what I'm wondering is, is something like this possible to do? I feel like I'm very close but can't quite extract the correct public key for some reason. I know on GitHub's enterprise plans I could even add my SSH CA user key, but can't justify the purchase of an enterprise plan for 1 user/myself. Thanks in advance, and apologies for the wall of text!
    6 replies
    Allen Conlon
    @A1994SC
    A weird ask, but is it possible to have a custom web page at https://tinyca.lan? I would like to host the root CA for downloading on local clients.
    2 replies
    etudurd
    @etudurd_gitlab
    Hello, while trying to deploy line by line the script provided in the SSH DIY example on the Host, i received the following error: The request lacked necessary authorization to be completed. Please see the certificate authority logs for more info. - at the “step ssh certificate ... —token $TOKEN” line. Do you know what I am missing and where i can find the step ca logs? Thank you!
    9 replies
    Matt Tuttle
    @LookoutHill
    Why isn't there a -Principal switch for "step ssh login ..." when this switch exists for "step ssh certificate ..."? It seems like an oversight since both commands generate a new SSH certificate and the ability to control the certificate principals should be equally useful in either situation. I posted this question earlier but retracted the post thinking that the -Identity switch listed in the documentation for "step ssh login ..." took the place of the -Principal switch, but no. In fact, I can't tell what it does. It doesn't cause any errors, doesn't have any effect on the generated certificate, and I can't find where it is handled in the code.
    5 replies
    Reese
    @reesericci
    I'm getting this error when trying to connect to a CA instance on kubernetes: error downloading root certificate: invalid character 'S' looking for beginning of value
    Marco Marinello
    @mmaridev
    Hi all! Sorry if I've been away for so long. Issue in integration of Smallstep ACME with Proxmox certification system has now been solved. Reference: https://bugzilla.proxmox.com/show_bug.cgi?id=2462#c9
    3 replies
    sbingram
    @sbingram
    I'm continuing to work through the step ssh tools and revoked a ssh cert for the first time. It finally worked, but I still see the host in the list when I issue step ssh hosts. Should the host still be in there even though it's a principal on a revoked cert and doesn't appear on any active cert? Is there no way to clean this up?
    3 replies
    Sergey
    @selfuryon_gitlab

    Hello! Can somebody explain how stepca acme server checks the email in incoming requests?
    I have stepca with admin@***.com JWK provisioner created during ca init and if I use this email for ACME - all works fine.
    But I can't use any other emails. I tried to add another JWK provisioner with acme@***.com but I can't get the certificate for this email.
    Can i get the certificate for other emails/provisioner emails or I should use only the first provisioner email?

    I use Caddy as ACME client with simple config:

    {
      email acme@***.com
      acme_ca https://acme.***.corp/acme/acme/directory
      acme_ca_root /etc/caddy/root_ca.crt
    }

    Provisioner List:

    [
       {
          "type": "JWK",
          "name": "admin@***.com",
          "key": {
             "use": "sig",
             "kty": "EC",
             "kid": "***",
             "crv": "P-256",
             "alg": "ES256",
             "x": "***",
             "y": "***"
          },
          "encryptedKey": "***,
          "claims": {
             "maxTLSCertDuration": "8760h0m0s",
             "defaultTLSCertDuration": "2160h0m0s"
          }
       },
       {
          "type": "ACME",
          "name": "acme",
          "claims": {
             "maxTLSCertDuration": "2160h0m0s",
             "defaultTLSCertDuration": "2160h0m0s"
          }
       },
       {
          "type": "JWK",
          "name": "acme@***.com",
          "key": {
             "use": "sig",
             "kty": "EC",
             "kid": "***",
             "crv": "P-256",
             "alg": "ES256",
             "x": "***",
             "y": "***"
          },
          "encryptedKey": "***"
       }
    ]
    Max
    @dopey
    Hey sergey, I think our docs may be a little confusing here.
    @selfuryon_gitlab
    The jwk provisioner doesn’t have anything to do with the ACME provisioner.
    The JWK provisioners are, as you’ve probably found, just password provisioners. If you have the password to decrypt the JWK you can create any certificate you want.
    ACME is separate, and in our implementation does not require an email.
    When you say “use this email for ACME all works fine”, what do you mean?
    In step-ca the way to use ACME is by selecting the ACME provisioner from the provisioners drop down when you do step ca certificate.
    So, give me an example of the step ca certificate command you’re trying to run that is failing.
    Ryan Holt
    @carpenike
    Hey folks -- anyone using smallstep on Windows and automating certificate renewals / storing in cert store?
    Looking to use certs for mTLS on clients.
    and want to automate the renewal via task manager.
    Guessing I may just need to one-time install the private key + cert as a p12 and then I can script the re-install of the .crt file during renewals.
    15 replies
    Ryan Holt
    @carpenike
    image.png
    Will validate that these settings actually work tomorrow when it's supposed to renew the cert. :)
    Somewhat torn on whether it'd be better to run in --daemon mode or just trigger task scheduler a couple times throughout day.
    Ryan Holt
    @carpenike
    Anyone using a yubikey to manage the SSH secrets for step-ca too?
    1 reply
    Mariano Cano
    @maraino
    You can do it but you will need to manually generate the keys on a non used slot
    With manually I mean using yubico-piv-tool or something similar
    Ryan Holt
    @carpenike
    Mariano Cano
    @maraino

    yes, the generateone , the only thing that you need to decide is which slots do you want to use, and configure them in the ca.json, right now step-yubikey-init stores the root key in 9a, and the intermediate in 9c

    At some point all these step-foo-init commands will be implemented in step ca init and ssh will be supported

    I remember somebody here initialized a tiny ca with ssh support using a yubikey, but I cannot find the conversation
    Ryan Holt
    @carpenike
    Good deal! Was planning on using 82/83 or something.
    Ryan Holt
    @carpenike
    image.png
    My scripted process didn't work btw. End up with two certs imported into the store. Will likely need to p12 the cert / key before importing them
    9 replies
    Craig Holyoak
    @cholyoak
    I'm just wondering what the status or plans might be for step-ca and CAA support. I can't find any references at all to this, other than @mmalone back in April 2020 implying that it doesn't (didn't) currently respect CAA records. IMHO this would be useful to support, but we would need to know in advance so appropriate records could be provisioned before hand.
    Thanks for the great project!
    Michael Malone
    @mmalone
    @cholyoak we don’t currently respect CAA records. I agree it’d be useful to support.
    Ryan Holt
    @carpenike

    Hoping someone can point me in the right direction as I'm having a hard time finding it in the docs. I need to use a yubikey for the ssh block:

            "root": "/etc/step-ca/certs/root_ca.crt",
            "federatedRoots": [],
            "crt": "/etc/step-ca/certs/intermediate_ca.crt",
            "key": "yubikey:slot-id=9c",
            "kms": {
                "type": "yubikey",
                "pin": ""
            },
            "address": ":443",
            "dnsNames": [
                    "pki.tld",
                    "10.20.0.15"
            ],
            "ssh": {
                    "hostKey": "/etc/step-ca/secrets/ssh_host_ca_key",
                    "userKey": "/etc/step-ca/secrets/ssh_user_ca_key"
            },

    I believe I have the SSH keys loaded properly in the yubikey into slots 82 and 83:

    Slot 82:
            Algorithm:      ECCP256
            Subject DN:     CN=SSH Host Key
            Issuer DN:      CN=SSH Host Key
            Serial:         12149987402350878307
            Fingerprint:    794316931b57ca9a91174f723dda3a9aa488fc7205d231f0366e8c29b8783f4e
            Not before:     2021-02-04 01:37:41
            Not after:      2022-02-04 01:37:41
    Slot 83:
            Algorithm:      ECCP256
            Subject DN:     CN=SSH User Key
            Issuer DN:      CN=SSH User Key
            Serial:         16282145902089869600
            Fingerprint:    ac28fac1f5144608f0d0211e02cae719d70a984c5408e074163edbd322e88720
            Not before:     2021-02-04 01:41:37
            Not after:      2022-02-04 01:41:37
    Mariano Cano
    @maraino

    @carpenike It should be

    {
        "ssh": {
            "hostKey": "yubikey:slot-id=82",
            "userKey": "yubikey:slot-id=83"
        }
    }

    But I'm looking at the code now and only this slots are supported "9a","9c","9e","9d" :(

    It should be pretty simple to allow more, let me read yubico docs to see if there's any issue using others
    Mariano Cano
    @maraino
    I see the issue, the underlaying package only defines those 4 slots, but I think supporting 82-95 should not be hard, we only need to define them using the table here https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf#page=30
    I'll create an issue
    Ryan Holt
    @carpenike
    Ah, just figured that out too and was about to write back. :-D
    Also, here's the series of yubico commands I ran:
    yubico-piv-tool -s9e -a generate -AECCP256 -o ssh-host-key-public.pem
    yubico-piv-tool -a verify-pin -a selfsign-certificate -s 9e -S "/CN=SSH Host Key/" -i ssh-host-key-public.pem -o ssh-host-key-cert.pem
    yubico-piv-tool -s9e -aimport-certificate -i ssh-host-key-cert.pem
    yubico-piv-tool -s9d -a generate -AECCP256 -o ssh-user-key-public.pem
    yubico-piv-tool -a verify-pin -a selfsign-certificate -s 9d -S "/CN=SSH User Key/" -i ssh-user-key-public.pem -o ssh-user-key-cert.pem
    yubico-piv-tool -s9d -aimport-certificate -i ssh-user-key-cert.pem
    service starts fine:
    ryan@pki:~/tmp$ systemctl status step-ca
    ● step-ca.service - step-ca
         Loaded: loaded (/etc/systemd/system/step-ca.service; enabled; vendor preset: enabled)
         Active: active (running) since Wed 2021-02-03 21:02:27 EST; 2min 43s ago
           Docs: https://smallstep.com/docs/step-ca
       Main PID: 6952 (sh)
          Tasks: 10 (limit: 971)
         CGroup: /system.slice/step-ca.service
                 ├─6952 /bin/sh -c /usr/local/bin/step-ca /etc/step-ca/config/ca.json
                 └─6953 /usr/local/bin/step-ca /etc/step-ca/config/ca.json
    
    Feb 03 21:02:27 pki systemd[1]: Started step-ca.
    Feb 03 21:02:27 pki sh[6953]: 2021/02/03 21:02:27 Serving HTTPS on :443 ..
    Going to add --valid-days=3650 so the expiration matches the CA PKI certs
    Mariano Cano
    @maraino
    You don't need the certificates they don't mean anything in SSH
    those X.509
    certificates