smallstep / cli Goto Github PK
View Code? Open in Web Editor NEW🧰 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
🧰 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
Fingerprint throws an error when contains more than one cert which is common for leaf+intermediate cert bundles.
$ step certificate fingerprint remote_site.crt
Where remote_site.crt
is:
-----BEGIN CERTIFICATE-----
MIICEjCCAbmgAwIBAgIRAJPWY9Bd2wgIPKHeWs4zahMwCgYIKoZIzj0EAwIwJDEi
MCAGA1UEAxMZU21hbGxzdGVwIEludGVybWVkaWF0ZSBDQTAeFw0xOTAyMjAwMDA1
NDFaFw0xOTAyMjEwMDA1NDFaMBAxDjAMBgNVBAMTBW5naW54MFkwEwYHKoZIzj0C
AQYIKoZIzj0DAQcDQgAEks8Ektkp9QL9hNIxv1jwvaig7mTzSeBfNn4sR3UOQKTG
fyC+/1GyULnujFZJVDyCXOiynWsrVeuwTmNZq7Y7WaOB3zCB3DAOBgNVHQ8BAf8E
BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBTb
tzlT8soA7CmfQzEWc+zDw101czAfBgNVHSMEGDAWgBTx0ojLlksfaHeKFaCqNymi
jl6rdjAQBgNVHREECTAHggVuZ2lueDBZBgwrBgEEAYKkZMYoQAEESTBHAgEBBBVt
YXJpYW5vQHNtYWxsc3RlcC5jb20EK0RtQXRadDJFaG1acl9pVEpKMzg3ZnI0TWQy
TmJ6TVhHZFhRTlcxVVdQWGswCgYIKoZIzj0EAwIDRwAwRAIgCLAEz4niywfTAsXe
msFt1sB1D5S7NQq8WWCArDonzzYCIBOAIcdyZv2pM4QhU0/auGgjOJDPmpbuGuJV
lWXj+wKd
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBxjCCAWugAwIBAgIQAYoOWhdChUmmKzlc0DWcWDAKBggqhkjOPQQDAjAcMRow
GAYDVQQDExFTbWFsbHN0ZXAgUm9vdCBDQTAeFw0xODExMDIyMzU0MTNaFw0yODEw
MzAyMzU0MTNaMCQxIjAgBgNVBAMTGVNtYWxsc3RlcCBJbnRlcm1lZGlhdGUgQ0Ew
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASxvIWme8/yDAxkR63KgSYkpN7mHKBH
k5c8S+uzba4xWbaxZtEZ9NNhEIAgYFZ9/3ThrzLOsuGwRCvPTaD5iycQo4GGMIGD
MA4GA1UdDwEB/wQEAwIBpjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
EgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU8dKIy5ZLH2h3ihWgqjcpoo5e
q3YwHwYDVR0jBBgwFoAU0IpOvAyBnn9UhDqOQzXnfEU3aYMwCgYIKoZIzj0EAwID
SQAwRgIhANXlcktuaEvORhgRvzQ6vVNgvpqCEXW3CcCHjUl1xSdaAiEAmakkpfFq
VsT5PqPnTRgOWlFESRhQ9btl6nQ+2Lt/S5A=
-----END CERTIFICATE-----
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.
error decoding remote_site.crt: contains more than one key
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.
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.
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.
Bash and Zsh
...
"e_signature_algorithm_not_supported": {
"result": "error"
},
...
Check should pass and not error.
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.
Ability to extract the private key and write back to disk unencrypted.
When trying to create certificate, the san option seems to get ignored
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
The X509v3 Subject Alternative Name:
should list
DNS:foo
DNS:bar
The X509v3 Subject Alternative Name:
lists
DNS:foobar
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?
Create an offline mode for step ca certificate
that uses the configuration file created with step ca init
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
.
Presence of these keys is required by certificates (not CSRs) that are non-root profile. None of this matters for CSR.
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.
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.
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
Fails because the server rejects client requests without/invalid certs.
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
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
Update the cli (and maybe our fork of certinfo) to support inspecting CSRs.
I'm trying to use step
to verify a Kubernetes ServiceAccount token.
:; 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"
}
]
}
:; 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
; 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
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.
We should probably stick to the the system we use for step ca certificate
where we support optional --not-before and --not-after flags.
Currently step certificate inspect
only support PEM certificates, we should support add support to inspect DER encoded certificates.
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.
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.
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.
$ 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
Display the certificate information, and probably some messages about why the certificate is not valid.
Add a simple offline mode to step ca token
using the configuration file created with step ca init
(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
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.
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 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:
-----BEGIN RSA PUBLIC KEY-----
BASE64 ENCODED DATA
-----END RSA PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
BASE64 ENCODED DATA
-----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,6b7ad703ae98c232dcfe6a08a053ff9c
BASE64 ENCODED DATA
-----END RSA PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
BASE64 ENCODED DATA
-----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY-----
BASE64 ENCODED DATA
-----END EC PRIVATE KEY-----
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,6b7ad703ae98c232dcfe6a08a053ff9c
BASE64 ENCODED DATA
-----END EC PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
BASE64 ENCODED DATA
-----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY-----
BASE64 ENCODED DATA
-----END PRIVATE KEY-----
-----BEGIN ENCRYPTED PRIVATE KEY-----
BASE64 ENCODED DATA
-----END ENCRYPTED PRIVATE KEY-----
replacing / migrating existing code to use a single implementation. Currently we have two implementations with a bunch of code duplication.
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.
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.
Make sure we collect agreement from all existing contributors
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
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.
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.
Run step version
:
$ step version
Smallstep CLI/ (darwin/amd64)
Release Date: 2018-08-07 18:44 UTC
See the version number:
$ step version
Smallstep CLI/0.0.1 (darwin/amd64)
Release Date: 2018-08-07 18:44 UTC
Consider adding a subcommand under step crypto
or step crypto key
to extract public keys from any object. Should probably be under step crypto
?
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 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
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.
brew install smallstep/smallstep/step
generates a warning about an unset $GOPATH
.
brew install smallstep/smallstep/step
Installation completes successfully without warning
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
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.
step certificate create -h
. Notice the long flag descriptions under the profile
flag. --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.
--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.
Needs to be fixed in the renderer -> https://github.com/smallstep/cli/blob/master/usage/renderer.go#L221-L302
step certificate lint
needs documentation.
The command step certificate inspect
cannot decode our own X.509 Extension.
step ca certificate foo.bar foo.crt foo.key
step certificate inspect foo.crt
Show the proper information for our extension:
Certificate:
...
Step Provisioner ID:
xxxx
...
Certificate:
...
Unknown extension 1.3.6.1.4.1.37476.9000.64.1
...
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:
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?require
the most appealing alternative?Add a command to extract the public keys from certificate and certificate signing requests.
Related to #67
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.