smallstep/community

Smallstep: End-to-end encryption for distributed applications and the people who manage them. (we’re on Pacific Time)

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

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

Generally following this? https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PKCS11.html

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

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

with the -a generate commands should suffice

Ryan Holt

@carpenike

So no need to import?

Although, the ykman tools don't indicate anything is in the slot unless you import a cert

Where communities thrive

People

Repo info

Activity