Learn about using the credential library resource to provide credentials from a credential store. Understand the credential library attributes you can configure.
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
SSH certificate-based authentication extends key-based authentication using digital signatures.
Your users' authenticity is determined by a certificate signed by a trusted certificate authority (CA).
You can configure Vault's SSH secrets engine to act as the CA.
SSH certificates let you specify how long they are valid for, who can gain access to a target host, how users can log in, and what commands can be used on the target machine.
Unlike SSH key pairs, SSH certificates are short-lived and self-destructive.
A Vault SSH certificate credential library has the following additional attributes:
<Note>
The certificate is issued for the entire session, so if the `ttl` value is shorter than the target's `session_max_seconds` value, later connections may fail.
To prevent failures, you should ensure that the `ttl` value is equal to or longer than the target's `session_max_seconds`.
Alternatively, you could set the `session_connection_limit` to `1` for any targets that use the credential library.
You can create a template for this value using [Vault credential library parameter templating](#vault-generic-credential-library-parameter-templating).
- `key_id` - (optional) The key ID for the created SSH certificate. You can create a template for this value using [Vault credential library parameter templating](#vault-certificates-library-parameter-templating).
- `critical_options` - (optional) Any critical options that the certificate should be signed for.
For more information, refer to the [list of critical options](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L221-L269) supported by OpenSSH.
- `extensions` - (optional) Any extensions that the certificate should be signed for.
For more information, refer to the [list of extensions](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L270-L319) supported by OpenSSH.
Note that the `permit-pty` value should be set for an interactive shell to function properly.
For more information, refer to OpenSSH's ["valid principals" definition](https://github.com/openssh/openssh-portable/blob/5f93c4836527d9fda05de8944a1c7b4a205080c7/PROTOCOL.certkeys#L176-L181) as well as Vault's documentation for the [SSH secrets engine](https://developer.hashicorp.com/vault/api-docs/secret/ssh#valid_principals).
Note that all SSH certificates issued by a Vault SSH certificate credential library use the `SSH_CERT_TYPE_USER` certificate type mentioned in the OpenSSH definition link.
Sometimes it can be useful to provide information about a Boundary user or account when making a call to Vault. For example, this can allow picking the correct role when asking for database credentials (if roles are separated per-user), or providing a value to encode in an X.509 certificate generated by Vault. You can template user and account information into either the path in Vault, the `POST` request body, or both.
Refer to the [SSH certificate injection with HCP Boundary](/boundary/tutorials/credential-management/hcp-certificate-injection) tutorial to learn how to configure credential injection with SSH certificates using Vault.
