ficate in the bundle will be
printed. Pass the --bundle option to print all fingerprints in the order in
which they appear in the bundle.

## POSITIONAL ARGUMENTS

<crt-file>
:  A certificate PEM file, usually the root certificate.

## EXAMPLES

Get the fingerprint for a root certificate:
'''
$ step certificate fingerprint /path/to/root_ca.crt
0d7d3834cf187726cf331c40a31aa7ef6b29ba4df601416c9788f6ee01058cf3
'''

Get the fingerprint for a remote certificate:
'''
$ step certificate fingerprint https://smallstep.com
e2c4f12edfc1816cc610755d32e6f45d5678ba21ecda1693bb5b246e3c48c03d
'''

Get the fingerprints for a remote certificate with its intermediate:
'''
$ step certificate fingerprint --bundle https://smallstep.com
e2c4f12edfc1816cc610755d32e6f45d5678ba21ecda1693bb5b246e3c48c03d
25847d668eb4f04fdd40b12b6b0740c567da7d024308eb6c2c96fe41d9de218d
'''

Get the fingerprint for a CSR using base64-url encoding without padding:
'''
$ step certificate fingerprint --format base64-url-raw hello.csr
PJLNhtQoBE1yGN_ZKzr4Y2U5pyqIGiyyszkoz2raDOw
'''**%s** command manages DNS domains in policies

## EXAMPLES

Allow www.example.com DNS in X.509 certificates on authority level
'''
$ step ca policy authority x509 allow dns www.example.com
'''

Allow all DNS subdomains of "local" in X.509 certificates on authority level
'''
$ step ca policy authority x509 allow dns "*.local"
'''

Deny DNS badhost.local in X.509 certificates on authority level
'''
$ step ca policy authority x509 deny dns "badhost.local"
'''

Remove badhost.local from denied DNS names in X.509 certificates on authority level
'''
$ step ca policy authority x509 deny dns "badhost.local" --remove
'''

Allow all DNS subdomains of "example.com" in X.509 certificates on provisioner level
'''
$ step ca policy provisioner x509 allow dns "*.example.com" --provisioner my_provisioner
'''

Allow all DNS subdomains of "account1.acme.example.com" in X.509 certificates on ACME Account level
'''
$ step ca policy acme x509 allow dns "*.account1.acme.example.com" --provisioner my_acme_provisioner --reference account1
'''

Allow all DNS subdomains of "local" in SSH host certificates on authority level
'''
$ step ca policy authority ssh host allow dns "*.local"
'''

Deny badsshhost.local in SSH host certificates on authority level
'''
$ step ca policy authority ssh host allow dns "badsshhost.local"
'''**step crypto keypair** generates a raw public /
private keypair in PEM format. These keys can be used by other operations
to sign and encrypt data, and the public key can be bound to an identity
in a CSR and signed by a CA to produce a certificate.

Private keys are encrypted using a password. You'll be prompted for this
password automatically when the key is used.

## POSITIONAL ARGUMENTS

<pub_file>
: The path to write the public key.

<priv_file>
: The path to write the private key.

## EXIT CODES

This command returns 0 on success and \>0 if any error occurs.

## EXAMPLES

Create an RSA public / private key pair with 4096 bits:

'''
$ step crypto keypair foo.pub foo.key --kty RSA --size 4096
'''

Create an RSA public / private key with fewer than the recommended number of
bits (recommended >= 2048 bits):

'''
$ step crypto keypair foo.pub foo.key --kty RSA --size 1024 --insecure
'''

Create an EC public / private key pair with curve P-521:

'''
$ step crypto keypair foo.pub foo.key --kty EC --curve "P-521"
'''

Create an EC public / private key pair but do not encrypt the private key file:

'''
$ step crypto keypair foo.pub foo.key --kty EC --curve "P-256" \
--no-password --insecure
'''

Create an Octet Key Pair with curve Ed25519:

'''
$ step crypto keypair foo.pub foo.key --kty OKP --curve Ed25519
'''
**step ca bootstrap** downloads the root certificate from the certificate
authority and sets up the current environment to use it.

Bootstrap will store the root certificate in <$STEPPATH/certs/root_ca.crt> and
create a configuration file in <$STEPPATH/configs/defaults.json> with the CA
url, the root certificate location and its fingerprint.

After the bootstrap, ca commands do not need to specify the flags
--ca-url, --root or --fingerprint if we want to use the same environment.

## EXAMPLES

Bootstrap using the CA url and a fingerprint:
'''
$ step ca bootstrap --ca-url https://ca.example.com \
  --fingerprint d9d0978692f1c7cc791f5c343ce98771900721405e834cd27b9502cc719f5097
'''

Bootstrap and install the root certificate
'''
$ step ca bootstrap --ca-url https://ca.example.com \
  --fingerprint d9d0978692f1c7cc791f5c343ce98771900721405e834cd27b9502cc719f5097 \
  --install
'''

Bootstrap with a smallstep.com CA using a team ID:
'''
$ step ca bootstrap --team superteam
'''

To use team IDs in your own environment, you'll need an HTTP(S) server
serving a JSON file:
'''
{"url":"https://ca.example.com","fingerprint":"d9d0978692f1c7cc791f5c343ce98771900721405e834cd27b9502cc719f5097"}
'''

Then, this command will look for the file at https://config.example.com/superteam:
'''
$ step ca bootstrap --team superteam --team-url https://config.example.com/<>
'''Whether the Authorization Server prompts the End-User for reauthentication and consent.
OpenID standard defines the following values, but your provider may support some or none of them:

    **none**
    :   The Authorization Server MUST NOT display any authentication or consent user interface pages.
        An error is returned if an End-User is not already authenticated or the Client does not have
        pre-configured consent for the requested Claims or does not fulfill other conditions for
        processing the request.

    **login**
    :   The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot
        reauthenticate the End-User, it MUST return an error, typically login_required.

    **consent**
    :   The Authorization Server SHOULD prompt the End-User for consent before returning information
        to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required.

    **select_account**
    :   The Authorization Server SHOULD prompt the End-User to select a user account. This enables an
        End-User who has multiple accounts at the Authorization Server to select amongst the multiple
        accounts that they might have current sessions for. If it cannot obtain an account selection
        choice made by the End-User, it MUST return an error, typically account_selection_required.
**step ssh login** generates a new SSH key pair and send a request to [step
certificates](https://github.com/smallstep/certificates) to sign a user
certificate. This certificate will be automatically added to the SSH agent.

With a certificate servers may trust only the CA key and verify its signature on
a certificate rather than trusting many user keys.

## POSITIONAL ARGUMENTS

<identity>
:  The certificate identity. If no principals are passed we will use
the identity as a principal, if it has the format abc@def then the
principal will be abc.

## EXAMPLES

Request a new SSH certificate and add it to the agent:
'''
$ step ssh login bob
'''

Request a new SSH certificate using an OIDC provisioner:
'''
$ step ssh login
'''

Request a new SSH certificate valid only for 1h:
'''
$ step ssh login --not-after 1h alice
'''

Request a new SSH certificate with multiple principals:
'''
$ step ssh login --principal admin --principal bob bob@smallstep.com
'''

Request a new SSH certificate and set a custom comment in the agent
'''
$ step ssh login --comment my-custom-comment bob@smallstep.com
'''

Request a new SSH certificate with an EC key and P-521 curve:
'''
$  step ssh certificate --kty EC --curve "P-521" mariano@work id_ecdsa
'''

Request a new SSH certificate with an Octet Key Pair and Ed25519 curve:
'''
$  step ssh certificate --kty OKP --curve Ed25519 mariano@work id_ed25519
'''**step crypto kdf hash** uses a key derivation function (KDF) to produce a
pseudorandom secret key based on some (presumably secret) input value. This is
useful for password verification approaches based on password hashing. Key
derivation functions are designed to be computationally intensive, making it
more difficult for attackers to perform brute-force attacks on password
databases.

If this command is run without the optional <input> argument and STDIN is a TTY
(i.e., you're running the command in an interactive terminal and not piping
input to it) you'll be prompted to enter a value on STDERR. If STDIN is not a
TTY it will be read without prompting.

This command will produce a string encoding of the KDF output along with the
algorithm used, salt, and any parameters required for validation in PHC string
format.

The KDFs are run with parameters that are considered safe. The 'scrypt'
parameters are currently fixed at N=32768, r=8 and p=1. The 'bcrypt' work
factor is currently fixed at 10.

For examples, see **step help crypto kdf**.

## POSITIONAL ARGUMENTS

<input>
:  The input to the key derivation function. <input> is optional and its use is
not recommended. If this argument is provided the **--insecure** flag must also
be provided because your (presumably secret) <input> will likely be logged and
appear in places you might not expect. If omitted input is read from STDIN.**step ca** command group provides facilities to initialize a certificate
authority, retrieve the root of trust, sign and renew certificates, and create
and manage provisioners.

## EXAMPLES

Create the configuration for a new certificate authority:
'''
$ step ca init
'''

Configure the ca-url and root in the environment:
'''
$ step ca bootstrap \
  --ca-url https://ca.smallstep.com \
  --fingerprint 0d7d3834cf187726cf331c40a31aa7ef6b29ba4df601416c9788f6ee01058cf3
$ cat $STEPPATH/config/defaults.json
{
  "ca-url": "https://ca.smallstep.com",
  "fingerprint": "0d7d3834cf187726cf331c40a31aa7ef6b29ba4df601416c9788f6ee01058cf3",
  "root": "/home/user/.step/certs/root_ca.crt"
}
'''

Download the root_ca.crt:
'''
$ step ca root root_ca.crt \
  --ca-url https://ca.smallstep.com \
  --fingerprint 0d7d3834cf187726cf331c40a31aa7ef6b29ba4df601416c9788f6ee01058cf3
'''

Get the Health status of the CA:
'''
$ step ca health --ca-url https://ca.smallstep.com --root /home/user/.step/certs/root_ca.crt
'''

Create a new certificate using a token:
'''
$ TOKEN=$(step ca token internal.example.com)
$ step ca certificate internal.example.com internal.crt internal.key \
  --token $TOKEN --ca-url https://ca.smallstep.com --root root_ca.crt
'''

Renew a certificate (certificate must still be valid):
'''
$ step ca renew internal.crt internal.key \
  --ca-url https://ca.smallstep.com --root root_ca.crt
'''**step path** command prints the configured step path and exits.

When using contexts to manage 'step-ca' environments, this command will return
the current authority path. If no current context is configured this command the
default step path of $HOME/.step, which can be overridden with the **STEPPATH**
environment variable.

## EXAMPLES

Get the path with no current context configured:
'''
$ step path
/Users/max/.step
'''

Get the path with no current context and environment variable STEPPATH overriding the default:
'''
$ export STEPPATH=/tmp/step
$ step path
/tmp/step
'''

Get the path with a current context (configured at $STEPPATH/current-context.json):
'''
$ cat $(step path --base)/current-context.json
{"context": "machine.step-internal.net"}

$ step path
/Users/max/.step/authorities/machine.step-internal.net
'''

Get the base path:
'''
$ step path --base
/Users/max/.step
'''

Get the base path with environment variable STEPPATH overriding the default:
'''
$ export STEPPATH=/tmp/step
$ step path --base
/tmp/step
'''

Get the path of the current profile:
'''
$ cat $(step path --base)/current-context.json
{"context": "ca.acme.net"}

$ cat $(step path --base)/contexts.json
{
	"ca.beta.net": {
        "profile": "beta-corp",
        "authority": "machine.beta.net"
    },
	"ca.acme.net": {
        "profile": "example-corp",
        "authority": "machine.acme.net"
    }

}
$ step path --profile
/Users/max/.step/profiles/beta-corp
'''
The operation(s) for which the key is intended to be used. Corresponds to
the "key_ops" JWK parameter. The '--key-ops' flag can be used multiple times
to indicate multiple intended operations.

  <key-op> can be one of the values defined in RFC7517:
    sign
      Compute digital signature or MAC
    verify
      Verify digital signature or MAC
    encrypt
      Encrypt content
    decrypt
      Decrypt content and validate decryption, if applicable
    wrapKey
      Encrypt key
    unwrapKey
      Decrypt key and validate decryption, if applicable
    deriveKey
      Derive key
    deriveBits
      Derive bits not to be used as a key

  The key operation values are case-sensitive strings. Other values may be
used, but values must not be duplicated.

  The '--use' and '--key-ops' flags cannot be used together without also
passing the '--subtle' flag. The '--subtle' flag allows both flags to be used
in a consistent way (e.g., '--key-ops=encrypt --key-ops=decrypt --use=enc').
Multiple unrelated operations (e.g., '--key-ops=encrypt --key-ops=sign') or
inconsistent combinations of '--use' and '--key-ops' (e.g., '--use=enc
--key-ops=sign') are not allowed without also passing the '--insecure' flag
because of potential vulnerabilities associated with using the same key with
multiple algorithms.

  Related operations include:
    sign + verify
    encrypt + decrypt
    wrapKey + unwrapKey
  If multiple values are passed and at least one is a non-standard value the
'--subtle' flag is required as you must verify that the operations are
related.
$ErrorActionPreference = 'Stop'
[version]$minimumVersion = '2.2.0'

$mod = Import-Module Az.Accounts -MinimumVersion $minimumVersion -PassThru -ErrorAction SilentlyContinue

if (-not $mod) {
    Write-Error '%s'
}

$params = @{
    ResourceUrl   = '%s'
	WarningAction = 'Ignore'
}

# Only force AsSecureString for Az.Accounts versions > 2.17.0 and < 5.0.0 which return plain text token by default.
# Newer Az.Accounts versions return SecureString token by default and no longer use AsSecureString parameter.
if ($mod.Version -ge [version]'2.17.0' -and $mod.Version -lt [version]'5.0.0') {
    $params['AsSecureString'] = $true
}

$tenantId = '%s'
if ($tenantId.Length -gt 0) {
    $params['TenantId'] = '%s'
}

$token = Get-AzAccessToken @params

$customToken = New-Object -TypeName psobject

# The following .NET interop pattern is supported in all PowerShell versions and safely converts SecureString to plain text.
if ($token.Token -is [System.Security.SecureString]) {
    $ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($token.Token)
    try {
        $plainToken = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
    } finally {
        [System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ssPtr)
    }
    $customToken | Add-Member -MemberType NoteProperty -Name Token -Value $plainToken
} else {
    $customToken | Add-Member -MemberType NoteProperty -Name Token -Value $token.Token
}
$customToken | Add-Member -MemberType NoteProperty -Name ExpiresOn -Value $token.ExpiresOn.ToUnixTimeSeconds()

$jsonToken = $customToken | ConvertTo-Json
return $jsonToken
**step crypto jwt sign** command generates a signed JSON Web Token (JWT) by
computing a digital signature or message authentication code for a JSON
payload. By default, the payload to sign is read from STDIN and the JWT will
be written to STDOUT. The suggested pronunciation of JWT is the same as the
English word "jot".

A JWT is a compact data structure used to represent some JSON encoded "claims"
that are passed as the payload of a JWS or JWE structure, enabling the claims
to be digitally signed and/or encrypted. The "claims" (or "claim set") are
represented as an ordinary JSON object. JWTs are represented using a compact
format that's URL safe and can be used in space-constrained environments. JWTs
can be passed in HTTP Authorization headers and as URI query parameters.

A "claim" is a piece of information asserted about a subject, represented as a
key/value pair. Logically a verified JWT should be interpreted as "<issuer> says
to <audience> that <subject>'s <claim-name> is <claim-value>" for each claim.

Some optional arguments introduce subtle security considerations if omitted.
These considerations should be carefully analyzed. Therefore, omitting <subtle>
arguments requires the use of the **--subtle** flag as a misuse prevention
mechanism.

A JWT signed using JWS has three parts:

    1. A base64 encoded JSON object representing the JOSE (JSON Object Signing
       and Encryption) header that describes the cryptographic operations
       applied to the JWT Claims Set
    2. A base64 encoded JSON object representing the JWT Claims Set
    3. A base64 encoded digital signature of message authentication code

For examples, see **step help crypto jwt**.