Working with issuance templates

Once the correct components are enabled, your next step is to create issuance templates. You'll need to start with at least two: one template for client certificates, and one for host certificates. You'll specify which template type you are creating when you are using the template wizard.

Issuance templates work like policies that control what types of access are granted to the target host machines.

To create an SSH certificate issuance template

1. From the SSH Protect menu, click Configuration > Certificate Issuance Template.

2. Click New Template.

3. On the Template settings page:

   1. Fill in the Name of your template.

   2. Pick a Certificate Issuance Flow.

      This determines which rules and scripts will be run when these SSH certificates are issued.

      No issuance flows available? You need to create them first. See SSH certificate adaptable issuance flows for detailed instructions.

   3. Select the Contacts that correspond to this issuance template's purpose.

   4. Click Next.

4. On the CA Key settings page:

   1. Decide whether you want to create a new keyset for this certificate authority, or if you want to use an existing keyset in SSH Protect.

   2. [Conditional] If you choose to Create new:

      1. Enter the Name (or using the name supplied by default, which corresponds to the name of the template you selected in the previous section).

      2. Select the Algorithm you want to use to generate the keyset.

         Make sure you are following the security policies of your organization when you select the algorithm.

      3. Select where the private key is generated and stored.

         If you have an HSM, this is where you use it for the SSH CA.

      4. Click Next.

   3. [Conditional] If you choose to Select existing:

      1. Use the CA key dropdown to search for and choose an existing key.

         IMPORTANT  Do not use the same CA keypair for different certificate types (i.e. client certificates and host certificates).

      2. Click Next.

5. On the Certificate settings page you define the settings that will be used during the certificate signing process:

   1. Choose a folder where these certificates will be stored by using the Create Certificate Objects in Folder drop-down.

   2. Determine the Certificate Object Naming Pattern.

      1. Supply in the Request - allows the client to specify the certificate object name.

      2. Build using Pattern - define a standard pattern used for all certificates issued with this template. If you select this option, you can use a combination of static text and/or macros to define the pattern. You can use existing macros, or one of the new macros introduced for SSH certificate templates, as shown in the following table.

         New macros introduced for SSH certificate templates

         Macro	Description
         $SSHCertificateRequest.RequestedBy$	The prefixed universal ID of the user who is requesting the ssh certificate
         $SSHCertificateRequest.OriginatingIP$	The IP address of the requester.

   3. Select the Type of Certificates to Issue.

      You will need a separate Issuance Templates for clients and hosts.

      Users and applications will need client certificates so they can prove their permissions to a host.

      Servers will need host certificates so they can identify which clients are permitted to connect.

   4. Choose the Maximum Certificate Validity.

      This is how long a given certificate is valid before the client will need to request a new certificate with updated restriction information.

      A lower value reduces potential risk because restriction information is updated more frequently. A higher value reduces server load, and may provide performance benefits.

      The current recommended certificate validity for SSH client certificates is 4 hours. The current recommended certificate validity for SSH host certificates is 365 days.

      When a person requesting a certificate does not supply an expiration value (or when the expiration value is longer than the value set here), this default value will be used.

   5. Choose the Default Private Key Algorithm.

      If a requester does not provide a public key to sign, SSH Protect will use this setting to generate a new key using this algorithm.

   6. Decide if you want to Allow Private Key Reuse. If checked, a requester can pass an existing public key from the inventory for signing. We recommend leaving this option unchecked, which means a new private key will be required for each request.

   7. [Optional] Review the Advanced Settings.

      1. If a requester does provide a public key, then the Allowed Private Key Algorithms list allows you to select which algorithms are acceptable. If a user provides a key with a different algorithm than on this list, the request will be rejected.

      2. Specify a Signature Hashing Algorithm.

         When signing certificate requests, the specified hash will be used. We recommend a stronger algorithm for best security.

   8. Click Next.

6. On the Access Controls page you specify the Principals, Extensions, KeyIDs, (and more), which will be used for validating the incoming certificate requests. If a request does not comply with the access control settings, the connection will be rejected.

   For specific information about each access control, please see SSH Certificate Issuance Restrictions.

7. Click Create.

What's next?

Now that you have at least one issuance template, you could potentially already create SSH certificates. However, there are a few things you still need to do before the SSH certificates are actually useful. The next step is to configure your host servers to trust your SSH CA-hosted certificates.