smallstep / cli Goto Github PK

View Code? Open in Web Editor NEW

3.5K 57.0 240.0 6.97 MB

🧰 A zero trust swiss army knife for working with X509, OAuth, JWT, OATH OTP, etc.

Home Page: https://smallstep.com/cli

License: Apache License 2.0

Makefile 0.17% Go 99.64% Shell 0.09% Dockerfile 0.03% PowerShell 0.07%

security security-tools jwt oauth x509 tls oath totp encryption cryptography

cli's People

Contributors

Stargazers

Watchers

Forkers

5up3rc apty jameschen79 oneiroi miguelraulb montana techlord-rce gabrie30 modulexcite oksbsb mmalone pabit pallas shammishailaj kumarchatla mrmichalis adelowo influx6 nichivo alanmiller triplekill jbronn awesome-security jibingeo venkat-abhi rckasa bluemutedwisdom dankamongmen rmgmedia everesio pshail shelltips janknieling electrowizard carles-figuerola brandonstone rtradeltd gaobrian realkcn synadia tuapuikia dzlabsch bianhezhen suyambuganesh raisingstar jdoss mkontani awesomegolang i-developers naiduarvind dev-idoxtreme-com paulyc emccrea topherisswell nonlogicaldev marcosrmendezthd zenreach krbcmt bvdeenen davidnarayan solidgoldbomb wishdev vanyell nimbius irab etsangsplk aebm helloritesh saeaccess azdnice erwbgy homedepot thesecmaven 8d8d joostd rabin-io innotechengineering gucchisk xianlimei sbambach jsoref jennyfromthedotte69 h2atecnologia alfian878787 guardacyber denji mgregoro xj3r3myx digitalarche xmrcl0 l1kw1d korhojoa th3architect isgasho tehmoon dcecco devadvocado vadirajks john92630 desnij

cli's Issues

Windows support?

One of the best features of Go is that it can fairly easily cross-compile to other operating systems, namely Windows. Windows lacks a lot of good CLI tools for, well, pick just about anything, so I would like to see this tool have Windows support.

certificate inspect should work for invalid certificates

step certificate inspect should work for invalid certificates

Step certificate inspect should work for invalid certificates. An easy way to reproduce this is trying to inspect the www.google.com certificate but using an IP, as the certificate does not have an IP SAN is not really valid, but we should have an option to see the content of it.

Your environment

OS - Any

Steps to reproduce

$ bin/step certificate inspect https://216.58.219.36
failed to connect: x509: cannot validate certificate for 216.58.219.36 because it doesn't contain any IP SANs

Expected behavior

Display the certificate information, and probably some messages about why the certificate is not valid.

Switch prompts to the ui package

Description

Switch to the ui package for all prompts.

Some of the old prompts like the password ones can break the terminal if the user ctrl-c, and you will need to reset it to make it working again.

Fingerprint certificate of remote server

It'd be nice if we could fingerprint a certificate on a remote machine the same way we can inspect one. That is, I'd like to be able to do the following:

step certificate fingerprint https://smallstep.com

Support configuration of certificate validity window in `step certificate create` command.

We should probably stick to the the system we use for step ca certificate where we support optional --not-before and --not-after flags.

step certificate inspect --full-chain

Subject of the issue

(Note: there isn't actually a github issue type for "feature request", only "bug report")

When debugging certificate chains, it can be useful to inspect the entire chain included in a certificate bundle. This can currently be accomplished using the following fairly unwieldy set of commands:

openssl crl2pkcs7 -nocrl -certfile foo.crt | openssl pkcs7 -print_certs -text -noout

Proposed Solution

step cert inspect could provide this same functionality with a --full-chain flag, which would inspect every certificate in the chain, from leaf to root.

Add optional flags to pass client cert for step certificate inspect

Subject of the issue

When debugging mTLS'd environments it's handy to be able to inspect a server's cert remotely granted one is possession of a valid cert to pass client auth on the server.

Expected behaviour

Optional flags for subcommand to provide cert, e.g. step certificate inspect --roots federated.pem --cert client.crt --key client.key https://127.0.0.1:443

Actual behaviour

Fails because the server rejects client requests without/invalid certs.

Move CLI to APL-2.0 license

Make sure we collect agreement from all existing contributors

Run step ca renew as a service

Allow running step ca renew as a service with custom flags. The service will renew the certificates after a specified duration has passed, and if a PID has been specified it will send a signal (HUP by default) to it after the renewal.

Add support for inspect DER encoded certificates

Description

Currently step certificate inspect only support PEM certificates, we should support add support to inspect DER encoded certificates.

certificate inspect does not output requested extensions

Running `step certificate inspect` does not print out any extensions on a CSR.

max @ maxs-mbp ~/src/github.com/smallstep/cli (sans *$%=) $ bin/step certificate inspect foo.crt
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: CN=foobar
        Subject Public Key Info:
            Public Key Algorithm: ECDSA
                Public-Key: (256 bit)
                X:
                    9b:fa:82:6f:91:cf:e1:36:76:07:96:d2:ea:dc:01:
                    38:c9:2a:38:23:10:66:ca:c0:0c:5c:ab:fd:05:da:
                    5a:72
                Y:
                    2d:9e:c5:c5:88:5c:c4:13:14:d3:74:5d:75:32:10:
                    55:17:3b:44:e6:15:4b:a7:7d:c9:04:d1:60:99:0c:
                    68:47
                Curve: P-256
    Signature Algorithm: ECDSA-SHA256
         30:45:02:20:42:26:1d:f4:49:9c:71:f6:10:6a:11:24:25:d3:
         3d:f3:96:b9:53:02:40:32:72:75:dc:35:63:de:2f:7f:38:73:
         02:21:00:f9:63:a6:41:07:d7:84:3a:4b:d8:2f:dc:a5:00:2e:
         10:49:12:06:fc:ea:50:99:9c:36:ba:c9:72:8f:2d:d0:0d

⬆ [ exit: 0 ] [ time: 18:23:36 ]
max @ maxs-mbp ~/src/github.com/smallstep/cli (sans *$%=) $ openssl req -in foo.crt -noout -text
Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: CN=foobar
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:9b:fa:82:6f:91:cf:e1:36:76:07:96:d2:ea:dc:
                    01:38:c9:2a:38:23:10:66:ca:c0:0c:5c:ab:fd:05:
                    da:5a:72:2d:9e:c5:c5:88:5c:c4:13:14:d3:74:5d:
                    75:32:10:55:17:3b:44:e6:15:4b:a7:7d:c9:04:d1:
                    60:99:0c:68:47
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
        Requested Extensions:
            X509v3 Subject Alternative Name:
                DNS:hello, IP Address:1.1.1.1
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:42:26:1d:f4:49:9c:71:f6:10:6a:11:24:25:d3:
         3d:f3:96:b9:53:02:40:32:72:75:dc:35:63:de:2f:7f:38:73:
         02:21:00:f9:63:a6:41:07:d7:84:3a:4b:d8:2f:dc:a5:00:2e:
         10:49:12:06:fc:ea:50:99:9c:36:ba:c9:72:8f:2d:d0:0d

SAN option ignored when creating a ca certificate

Subject of the issue

When trying to create certificate, the san option seems to get ignored

Your environment

OS - Docker step-cli image
Version - 0.8.6

Steps to reproduce

Having a ca available and configured, from the cli do:

step ca certificate --san foo --san bar foobar foobar.crt foobar.key
step certificate inspect foobar.crt

Expected behaviour

The X509v3 Subject Alternative Name: should list

DNS:foo
DNS:bar

Actual behaviour

The X509v3 Subject Alternative Name: lists

DNS:foobar

Review utility of internal `assert` testing package and discuss alternatives

We have our own internal testing package for verifying assertions (called assert). I believe this package was created to address deficiencies (missing functions, e.g. FatalError(), Fatal()) in more popular libraries. I have reviewed the current state of the require package and it seems to have the functionality that we wanted.

Switching to require (or a similar package) will give us access to a many more features that our implementation does not have. A more popular package will also make it much easier and straightforward for new contributors to grok existing tests and write new ones.

@maraino we discussed this a while ago, so interested in hearing your opinion on two questions:

Is require a superset of assert? Would it be a full substitute, and offer more features on top, or would we be missing certain features that we already have?
Is require the most appealing alternative?

`step certificate create --csr` should not require `--ca/--ca-key`

Presence of these keys is required by certificates (not CSRs) that are non-root profile. None of this matters for CSR.

Log HTTP requests to OAuth HTTP server

If an unexpected request comes into the OAuth HTTP server we should log it. We should also consider having the server remain up after such a request, but we we need to think about any security considerations before doing so. Currently, the OAuth subcommand uses the httptest server and closes down after one request, whether or not that request is a successful OAuth redirect. If a client has some plugin (e.g., https://www.wappalyzer.com/) that sends a request to the server ahead of the OAuth redirect, the server will shutdown and the redirect won't be properly handled. At a minimum, we should output enough information that an end user can debug what's going on.

Be able to format PKCS#1 or RFC5915 PEMs to PKCS#8

Description

Add new options to step crypto key format to be able to format keys using PKCS#1 or RFC5915 formats to PKCS#8 and the other way around:

PKCS#1 private keys:

RFC5915 private keys:

PKCS#8 keys:

step certificate fingerprint <cert-file> fails when bundle (leaf+intermediate) is presented

Subject of the issue

Fingerprint throws an error when contains more than one cert which is common for leaf+intermediate cert bundles.

Steps to reproduce

$ step certificate fingerprint remote_site.crt

Where remote_site.crt is:

Expected behaviour

I'd expected the leaf cert's fingerprint to be printed. Analogous to how step certificate inspect works. If additional --bundle is provided I'd expected both fingerprints to be printed.

Actual behaviour

error decoding remote_site.crt: contains more than one key

Allow to use certificates as key parameters

Description

Some commands like step crypto jwt verify should accept certificates as --key parameters, we can easily extract a public key from it and verify the JWT.

Related to #67

Wrap --flag descriptions

Subject of the issue

Description of flags should wrap in the usage / help text. Currently long descriptions are not broken into multiple lines and if you manually break them the next line does not begin in a natural position.

Your environment

OS - OSX
Version - 0.0.24-rc.1

Steps to reproduce

run step certificate create -h. Notice the long flag descriptions under the profile flag.

Expected behaviour

      --profile=profile
          The certificate profile sets various certificate details such as
          certificate use and expiration. The default profile is 'leaf' which is
          suitable for a client or server using TLS.

          profile is a case-sensitive string and must be one of:

            leaf              Generate a leaf x.509 certificate suitable for 
                              use with TLs.
            intermediate-ca   Generate a certificate that can be used to sign 
                              additional leaf or intermediate certificates.
            root-ca           Generate a new self-signed root certificate suitable 
                              for use as a root CA.

Actual behaviour

      --profile=profile
          The certificate profile sets various certificate details such as
          certificate use and expiration. The default profile is 'leaf' which is
          suitable for a client or server using TLS.

          profile is a case-sensitive string and must be one of:

            leaf               Generate a leaf x.509 certificate suitable for use with TLs.
            intermediate-ca    Generate a certificate that can be used to sign additional leaf or intermediate certificates.
            root-ca            Generate a new self-signed root certificate suitable for use as a root CA.

Additional context

Needs to be fixed in the renderer -> https://github.com/smallstep/cli/blob/master/usage/renderer.go#L221-L302

Step certificate inspect cannot decode our own X.509 extension

Subject of the issue

The command step certificate inspect cannot decode our own X.509 Extension.

Your environment

OS - all
Version - all

Steps to reproduce

Run step certificates
Create a certificate using step ca certificate foo.bar foo.crt foo.key
Inspect the certificate using step certificate inspect foo.crt

Expected behavior

Show the proper information for our extension:

Certificate:
   ...
   Step Provisioner ID:
      xxxx
   ...

Actual behavior

Certificate:
   ...
   Unknown extension 1.3.6.1.4.1.37476.9000.64.1
   ...

Add a command to download or print a certificate

Description

Add a command to print or download a certificate. Sometimes is useful to get the PEM version of a certificate, we should add a command like

# Just the cert
step certificate download https://smallstep.com > smallstep.pem
# Bundled with intermediate
step certificate download --bundle https://smallstep.com > smallstep.pem

Debian package name conflicts with another package

Subject of the issue

In Debian there's already a package named step that is an interactive physical simulator. We need to rename the package to avoid problems when a debian/ubuntu system is upgraded

Your environment

OS - Linux
Version - Debian 9.4 (Stretch)

Replace json marshaler for x509 with custom impl (remove dependency)

zcrypto is being used to marshal x509 for certificate inspect. However, modifications were necessary to make zcrypto/x509 support *25519 keys. The CLI's using multiple version of crypto/x509 for various reasons in the codebase. Let's consider writing a custom implementation of JSON marshaling or integrate the functionality into a version of x509 in some other way.

Fix broken versions in homebrew-core formula

linting certificate w/ *25519 signature returns "algorithm not supported"

...
"e_signature_algorithm_not_supported": {
   "result": "error"
  },
...

Check should pass and not error.

Add a command to extract keys from certificates and CSRs

Description

Add a command to extract the public keys from certificate and certificate signing requests.

Related to #67

Explore different linux install strategies

https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-binary-using-curl

Switch pemutil to use primitives of the stdlib by default

Right now pemutil.Read() and pemutil.Parse() returns Certificates and Certificates request of the internal x509 implementation, and there's an option to get the standard library implementation pemutil.WithStdLib().

We should switch to return the default types unless some other option is added. So, use default types unless you know what you're doing.

Add SCT support to certificate inspect

Offline mode for step ca certificate

Create an offline mode for step ca certificate that uses the configuration file created with step ca init

'certificate inspect' does not support inspecting a CSR

Update the cli (and maybe our fork of certinfo) to support inspecting CSRs.

GOPATH warning during brew install

Subject of the issue

brew install smallstep/smallstep/step generates a warning about an unset $GOPATH.

Your environment

OS - OS X
Version - High Sierra

Steps to reproduce

brew install smallstep/smallstep/step

Expected behaviour

Installation completes successfully without warning

Actual behaviour

A valid GOPATH is required to use the `go get` command.
If $GOPATH is not specified, $HOME/go will be used by default:
  https://golang.org/doc/code.html#GOPATH

You may wish to add the GOROOT-based install location to your PATH:
  export PATH=$PATH:/usr/local/opt/go/libexec/bin

Unify 1st and 3rd person use in docs

Description

The description of the commands in docs sometimes use the 1st person and sometimes the 3rd one. Notice for example step help ca:

...
      health       get the status of the CA
      init         initializes the CA PKI
      bootstrap    initializes the environment to use the CA commands
      token        generates an OTT granting access to the CA
      certificate  generates a new certificate pair signed by the root certificate
      renew        renew a valid certificate
      root         downloads and validates the root certificate
      provisioner  create and manage the certificate authority provisioners
      sign         generates a new certificate signing a certificate request

We should unify those docs to always use the same person.

Don't open a prompt terminal if the option for the prompt is already set via the cli.

If a user wants to use the cli w/out input we shouldn't be opening a fd for a prompt because this could cause an exception in environments where a terminal is not available.

Add simple offline mode for step ca token

Add a simple offline mode to step ca token using the configuration file created with step ca init

Add --insecure --no-password flags to `step crypto change-pass`

Ability to extract the private key and write back to disk unencrypted.

Verifying a Kubernetes serviceaccount token with step

I'm trying to use step to verify a Kubernetes ServiceAccount token.

Provision a Service Account

:; kubectl create serviceaccount trixrabbit
serviceaccount "trixrabbit" created

:; kubectl get -o json sa/trixrabbit
{
    "apiVersion": "v1",
    "kind": "ServiceAccount",
    "metadata": {
        "creationTimestamp": "2019-01-23T23:52:59Z",
        "name": "trixrabbit",
        "namespace": "default",
        "resourceVersion": "3745182",
        "selfLink": "/api/v1/namespaces/default/serviceaccounts/trixrabbit",
        "uid": "033b7edb-1f6a-11e9-98ce-80fa5b5b38db"
    },
    "secrets": [
        {
            "name": "trixrabbit-token-7ln2l"
        }
    ]
}

Obtain the credentials

:; token=$(kubectl get -o json sa/trixrabbit |jq -r '.secrets[0].name')
:; kubectl get -o json secret $token |jq -r '.data.token' |base64 -d >trixrabbit.jwt
:; kubectl get -o json secret $token |jq -r '.data["ca.crt"]' |base64 -d >trixrabbit.ca.crt

Inspect the credentials

; step crypto jwt inspect --insecure <trixrabbit.jwt |jq .                              
{
  "header": {
    "alg": "RS256",
    "kid": ""
  },
  "payload": {
    "iss": "kubernetes/serviceaccount",
    "kubernetes.io/serviceaccount/namespace": "default",
    "kubernetes.io/serviceaccount/secret.name": "trixrabbit-token-7ln2l",
    "kubernetes.io/serviceaccount/service-account.name": "trixrabbit",
    "kubernetes.io/serviceaccount/service-account.uid": "033b7edb-1f6a-11e9-98ce-80fa5b5b38db",
    "sub": "system:serviceaccount:default:trixrabbit"
  },
  "signature": "AgDNyeFlVlQBmBC32iCCMUSF1AGU_GxehYQmY_P-Jh4N3rD33MUSoWe0SLUa7Sl7yPXK-HpdKMLuerlmghgVp9SAnuSO1QQD9Hh0jHfJZCEmfWtEVItHeBEbV6on15wRAEs75HFfjGHnShrdgwZHYxupMUNt84f5KHYC3U3VfMtKx9X7xkwqll9oC0q-bGsY4X4Jxq45zFi7AXBwMbmcnu1U00M9dHfUBHQ2Z2Lti8N3Wt5PrpGC3-zSyfsw3U__VJDt_N7sMDkq7YmppL9IWYVeWbrFO2kl4xRXGuEEYfidTizJghOQ4adFFK5juKwbwvs7WrO7qOkFDg0_jDsQjQ"
}

:; step certificate inspect trixrabbit.ca.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 12509686381743968844 (0xad9b557c2b64124c)
    Signature Algorithm: SHA256-RSA
        Issuer: CN=127.0.0.1
        Validity
            Not Before: Dec 3 23:00:39 2018 UTC
            Not After : Apr 20 23:00:39 2046 UTC
        Subject: CN=127.0.0.1
        Subject Public Key Info:
            Public Key Algorithm: RSA
                Public-Key: (2048 bit)
                Modulus:
                    b1:44:71:70:4d:96:ba:49:87:3d:5c:be:a0:61:e9:
                    40:e8:90:fa:f1:de:67:c8:6f:af:db:60:60:75:12:
                    96:94:70:1c:ce:51:9f:c0:05:4c:46:b9:b2:ed:59:
                    75:7f:53:7c:2a:bf:0e:ab:20:d9:ae:c2:d7:8a:a9:
                    ff:49:86:96:f2:0b:94:d1:b0:fc:d9:f4:25:8f:b2:
                    3d:cc:8b:4e:be:bf:36:35:24:47:da:18:4f:70:16:
                    73:8e:f3:a2:f0:f6:26:ae:d0:c5:db:40:2f:9c:60:
                    ba:e7:44:b5:66:99:48:a9:09:7e:d6:ab:a8:22:0f:
                    9b:de:cc:17:1f:2e:b6:74:83:48:8a:ee:60:f4:7d:
                    71:d5:f6:21:2f:9d:d1:7c:87:37:f1:63:f2:af:24:
                    6e:5a:fd:1c:a2:4e:af:d9:9b:85:ee:f3:66:6c:c8:
                    2b:dc:3e:d1:fe:61:70:07:ff:8b:4e:83:fb:73:a9:
                    44:98:81:b8:27:c2:57:a2:9f:a6:80:29:61:80:b9:
                    e5:e6:f1:d0:00:ec:d8:4b:ca:9b:67:83:53:1e:66:
                    b0:f1:06:69:23:56:e6:1b:91:25:79:73:85:9f:e0:
                    cd:48:14:67:51:9c:a8:e2:3d:c9:8d:96:fd:c1:97:
                    9b:4a:cd:89:4f:8e:b0:e0:d6:14:7c:a4:21:cd:fd:
                    fb
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                E4:12:02:D3:F4:17:10:FA:63:EC:A3:11:DF:B0:A3:2B:35:E8:CF:F0
            X509v3 Authority Key Identifier:
                keyid:E4:12:02:D3:F4:17:10:FA:63:EC:A3:11:DF:B0:A3:2B:35:E8:CF:F0
            X509v3 Basic Constraints:
                CA:TRUE

    Signature Algorithm: SHA256-RSA
         42:72:61:72:2a:c8:a2:b7:33:1d:a5:32:f4:fa:8d:2b:de:9e:
         ff:7e:d3:a4:95:9b:96:aa:75:c5:3e:a0:4b:c0:d3:cd:7d:5f:
         60:a2:b5:1d:98:c9:1f:a1:f8:fe:3b:18:6d:b4:00:b4:87:97:
         cc:5b:c1:94:5e:8d:f8:87:81:d6:91:c7:eb:22:38:d2:f4:8c:
         4d:9a:ca:51:83:c9:c6:17:52:a4:0f:8e:c8:7e:84:eb:bb:ab:
         20:7e:22:e3:ee:c1:c3:95:10:13:ed:2e:59:01:57:60:78:3e:
         59:53:ff:53:0d:2d:c7:22:42:cf:5a:76:7b:38:ff:ba:28:2f:
         d8:54:06:38:62:23:5b:04:9b:cc:3a:3f:cf:e2:a9:a0:32:03:
         12:f2:74:38:11:22:29:92:ba:f4:93:67:11:81:8d:6a:29:fb:
         68:9e:37:60:f9:64:bc:9f:34:65:4f:1f:e7:34:19:f2:6c:02:
         aa:06:14:e1:e2:bc:c0:62:f9:c8:3a:9a:f0:20:cf:85:ec:4e:
         f7:50:fb:0a:36:94:c5:f1:9c:17:d5:02:18:fd:6f:d4:b6:65:
         98:88:cb:89:be:4a:f5:6a:e3:82:2f:3a:a8:c4:67:84:ec:11:
         8b:f4:b3:4b:94:bc:b5:94:f1:c4:19:62:88:be:0d:a0:d1:97:
         d1:ea:ce:b9

Problem: How to verify credentials?

I can't figure out how to use the step CLI to validate that the given jwt was signed such that it can be trusted via the ca.crt...

:; step crypto jwt verify --subtle --key trixrabbit.ca.crt --alg RS256 <trixrabbit.jwt 
alg 'RS256' is not compatible with the given key

(The --subtle flag isn't documented in --help output, so I don't know what I'm exactly specifying here)

Any suggestions?

Thanks.

Support installation of self-signed root certs into your local trust store

lint needs documentation

step certificate lint needs documentation.

Make sure auto-completion is working

Bash and Zsh

Step cli from homebrew does not have a version

Subject of the issue

Makefile gets the version using a git repository, the tar file used by the homebrew does not include a git repository so it sets the version blank.

The Makefile has been updated to be able to overwrite VERSION using an environment variable, so we need to update the homebrew script to use this variable or include the repository in the tar file.

Your environment

OS - macOS
Version - High Sierra

Steps to reproduce

Run step version:

$ step version
Smallstep CLI/ (darwin/amd64)
Release Date: 2018-08-07 18:44 UTC

Expected behaviour

See the version number:

$ step version
Smallstep CLI/0.0.1 (darwin/amd64)
Release Date: 2018-08-07 18:44 UTC

integrate mariano's PEM functions (in crypto/pem) into other crypto/* subpackages

replacing / migrating existing code to use a single implementation. Currently we have two implementations with a bunch of code duplication.

Ability to extract a public key from a private key

Consider adding a subcommand under step crypto or step crypto key to extract public keys from any object. Should probably be under step crypto?

Integrate debian packages building into travis

Description

Debian package building and releases should be integrated into Travis.

On a Debian machine with the right tools, running make debian will build a Debian package. To update the version the debian/changelog must be changed properly.

git-buildpackage or gbp can be used on a Debian machine to update the changelog from git commits, doing:

gbp dch --release

step ca certificate sign --not-after equivalent to min duration will often fail

step ca certificate sign --not-after equivalent to min duration will fail with message like error="sign: requested duration of 4m59.968830657s is less than the authorized minimum certificate duration of 5m0s" due to order of operations.

Key Usage on Root CA & Intermediate CA Certificates

We need to make sure we're setting the key usage correctly on root and intermediate certificates generated by step certificate create. Currently the intermediate certificates have "Key Encipherment" set as a key usage and "TLS Web [Client/Server] Authentication" set in extended key usage. Root certificates have "Key Encipherment". Best I can tell these usages aren't required for CA intermediate and root certificates and should probably be removed.

See Let's Encrypt's root and intermediate certificates for examples.

But Let's Encrypt is just one data point... I'm not sure where this stuff is actually specified. RFC 5280 seems like a good starting point but the section on Key Usage references three other RFCs ([RFC3279], [RFC4055], and [RFC4491]) for extensions that should be used for various algorithms. There might be more info in CAB Browser Forum stuff somewhere?

I don't think this is a major problem, but at some point we should dig deeper on this and make sure we're doing the right thing here. Or, even better, maybe someone who knows the answer here will stumble on this and clarify for us :).

Add ACME support for letsencrypt to command line

Provide CLI subcommand to launch a web server that will successfully respond to ACME's HTTP challenge and obtains web-PKI certs for nginx, apache, or any other server that ones to run over TLS.

smallstep/cli libraries cannot be linked on windows

We build our CLI across several platforms. When I try to introduce a dependency against this repo to use library code, we get the following error:

 ---> f44aec2ece40
Step 11/22 : RUN CGO_ENABLED=0 GOOS=darwin  go build -o /out/linkerd-darwin  -tags prod -ldflags "-s -w" ./cli
 ---> Running in 717aaaef4661
Removing intermediate container 717aaaef4661
 ---> 9e2bcfc7ccb7
Step 12/22 : RUN CGO_ENABLED=0 GOOS=linux   go build -o /out/linkerd-linux   -tags prod -ldflags "-s -w" ./cli
 ---> Running in 7c6187106257
Removing intermediate container 7c6187106257
 ---> bbe43df0a7d7
Step 13/22 : RUN CGO_ENABLED=0 GOOS=windows go build -o /out/linkerd-windows -tags prod -ldflags "-s -w" ./cli
 ---> Running in 7ad0c430bd98
# github.com/smallstep/cli/ui
../../smallstep/cli/ui/ui.go:205:25: cannot use syscall.Stdin (type syscall.Handle) as type int in argument to readline.IsTerminal
../../smallstep/cli/ui/ui.go:235:25: cannot use syscall.Stdin (type syscall.Handle) as type int in argument to readline.IsTerminal
The command '/bin/sh -c CGO_ENABLED=0 GOOS=windows go build -o /out/linkerd-windows -tags prod -ldflags "-s -w" ./cli' returned a non-zero code: 2

How feasible is it to make compilation succeed on windows?

CreateCRL and CreateCertificateRequest should use same hashing method as CreateCertificate in x509

Subject of the issue

In changes to allow for *25519 keys in x509 the CreateCertificate method was modified to allow for 0 valued hash. The other two methods that use crypto.Hash were not updated and as a result inspect and generating CSR does not work.

`step certificate` top-level documentation needs once-over

More information about certificates in general (as opposed to the step certificate sub-commands) can be found at step help topics certificate or online at [URL].

Replace with actual url and also step help topics certificate just returns the help/usage info for step certificate.

smallstep / cli Goto Github PK

cli's People

Contributors

Stargazers

Watchers

Forkers

cli's Issues

step certificate inspect should work for invalid certificates

Your environment

Steps to reproduce

Expected behavior

Description

Subject of the issue

Proposed Solution

Subject of the issue

Expected behaviour

Actual behaviour

Description

Running step certificate inspect does not print out any extensions on a CSR.

Subject of the issue

Your environment

Steps to reproduce

Expected behaviour

Actual behaviour

Description

Subject of the issue

Steps to reproduce

Expected behaviour

Actual behaviour

Description

Subject of the issue

Your environment

Steps to reproduce

Expected behaviour

Actual behaviour

Additional context

Subject of the issue

Your environment

Steps to reproduce

Expected behavior

Actual behavior

Description

Subject of the issue

Your environment

Description

Subject of the issue

Your environment

Steps to reproduce

Expected behaviour

Actual behaviour

Description

Don't open a prompt terminal if the option for the prompt is already set via the cli.

Provision a Service Account

Obtain the credentials

Inspect the credentials

Problem: How to verify credentials?

Subject of the issue

Your environment

Steps to reproduce

Expected behaviour

Description

Subject of the issue

Recommend Projects

Recommend Topics

Recommend Org

Jobs

Running `step certificate inspect` does not print out any extensions on a CSR.