Venafi SSH Protect as an SSH Certificate Authority

The key to using SSH certificate authentication in your environment is the SSH certificate authority (SSH CA). Venafi SSH Protect is designed to function as your SSH CA. There is some configuration required before you can start issuing SSH certificates. These steps are usually performed by your Venafi Platform system administrator.

An SSH CA allows you to do the following:

  • Create and manage SSH certificate issuance templates.

  • Generate certificates using the existing CA private key, or generate a new private key.

  • Define default settings.

  • Set access restrictions for clients and hosts.

SSH Protect allows you to create and manage multiple SSH CAs with multiple issuance templates in each, allowing you to enforce security policies. SSH Protect also allows you to audit SSH certificate requests.

The SSH Protect user interface (e.g. https://domain.example/aperture/ssh-protect) does not support issuing SSH Certificates. These are issued using the WebSDK. Please see the following topics for additional information:

What is an SSH certificate Issuance template?

SSH certificates are based on an SSH certificate Issuance template, which is a list of settings that define a blueprint (i.e. policy) for creating a certificate. An issuance template is used to define the content and purpose of a digital certificate. For SSH certificates, this includes issuance requirements (security policies, whitelisted Principals, etc.) and access restrictions (certificate extensions, source addresses, etc.).

Show me how to work with issuance templates

Because SSH certificate issuance templates are designed to be flexible, there's a lot of flexibility in configuring them to match your unique use cases. For example, when you want to use SSH certificates for user authentication to corporate servers, you can use a specific issuance template that pertains to that user's role in the company. These issuance templates will likely be different for users in human resources than they will be for users in finance, or information systems. For example, if your user is a database administrator, they will usually need limited SSH access (e.g., non-root) to the servers that they use. So their issuance template might allow users with this role to request certificates that cannot be used for authentication as privileged (e.g., root) users. However, privileged access is needed for system administrators, so system administrators would have a separate issuance template that provides them with the access they need.