Policy object certificate settings

A policy object Certificate tab allows you to define settings, such as the certificate management type, for the subordinate certificate objects.

Certificate settings defined for a folder take precedence over the settings defined in the subordinate certificate objects if the values are locked. Otherwise, the policy’s certificate settings function as default values for subordinate certificate objects.

The following table describes Policy Tree Policy object Settings > Certificate tab.

Field

Description

Certificate Tab

The Certificate tab defines certificate settings for subordinate certificate objects.

Certificate settings defined at the folder level may take precedence over those defined in the subordinate Certificate objects.

TIP  The recipients and delivery method (email, SNMP trap, etc.) for expiration notifications are defined in Notification and Channel objects. You must configure the channel and notification objects to send notifications for expiration events. For more information, see Managing certificate notifications.

General Information

Contacts

User or group identities assigned to subordinate certificate objects.Default system notifications are sent to the contact identities.

Approvers

User or group Identities assigned to approve workflows (certificate approval or injection command) for subordinate Certificate objects. For more information on defining Workflows, see Implementing certificate workflow management. For information on when Trust Protection Platform references approvers defined in the Certificate object, see the option Approver Assigned to Object.

Management Type

Level where subordinate certificates will be managed. The default is Provisioning.

Trust Protection Platform provides the following levels of certificate management:

  • Monitoring: Trust Protection Platform monitors existing certificates and provides current information on the certificate status and lifecycle. When the certificate nears the end of its lifecycle, Trust Protection Platform notifies the administrator. It does not, however, renew the certificate. The administrator must manually create the CSR, send it to the certificate authority (CA), then retrieve and install the renewed certificate.

  • Enrollment: Trust Protection Platform can automatically generate and submit CSRs to Certificate Authorities using the parameters defined in designated CA Template objects. If preferred, the administrator can manually generate the CSR, then upload it to Trust Protection Platform to complete the enrollment process with the appropriate CA. After the CA signs the certificate, Trust Protection Platform retrieves the certificate and securely stores it in the central database. The administrator must then download the certificate from Trust Protection Platform and install it on the target systems.

  • Provisioning: Trust Protection Platform manages the entire certificate lifecycle—it automatically requests, installs, and monitors your system certificates.

  • Unassigned: Unlicensed Trust Protection Platform certificates and keys that do not allow network validation, expiration monitoring, enrollment, provisioning, or onboard validation. However, they are included in selected reports and on the dashboard.

Managed by

The Venafi application that manages the policy. Choose Aperture or User Portal if the policy is managed by that application. If not, leave this field blank.

CSR Handling

 

CSR Generation

Determines how CSRs are generated. The default is Service Generated CSR:

  • Service Generated CSR: Trust Protection Platform automatically generates the CSR.

  • User Provided CSR: CSR is manually generated by the administrator, then uploaded to Trust Protection Platform.

Generate Key/CSR on Application

Determines where the CSR and private key are generated. The default is No.

IMPORTANT  When one or more of the following items are true, Remote Generation is not supported and, therefore, the Generate Key/CSR on Application setting is ignored.

  • You're using a driver that does not support remote generation.

    To learn which drivers support remote generation, see Supported integrations: devices, applications, services and features supported by Venafi.

  • You're using a self-signed CA template to enroll a certificate; self-signed CA templates do not work with remote generation.

    This is because Trust Protection Platform requires that the private key be stored centrally so that it can be used to sign the self-signed certificate.

  • Your certificate is associated with more than one application; to work correctly, the certificate must be associated with one application.
  • You have not set the certificate's management type setting to Provisioning.
  • You're doing one-to-many provisioning.

If you do not select this option, the CSR and private key are centrally generated on the Trust Protection Platform server, then securely copied to the application.

If you do select this option, the CSR and private key are locally generated on the application’s server.

In both cases, the certificate and private key are archived in the Trust Protection Platform database.

Hash Algorithm

For the certificate signing request, choose either SHA-256, SHA-384, or SHA-512. The default is SHA-256.

Subject DN

Organization

Name that uniquely identifies the organization in the certificate.

Organization Unit

Department or division within the organization that is responsible for maintaining the certificate.

City, State/Province, Country

Location (city, state/province, and country) of your Organization or Organizational Unit.

Domain White List

 

Allowed Domains

Enter the suffix of allowed domains. For example, .com

acme.com, or sales.acme.com. If you leave this field blank, all domains will be allowed.

Allow Wildcards

  The default is Yes. Select No to prohibit wildcards.

Allow Duplicate Common and Subject Alternate Names

The default is Yes. Select No to require unique names.

Private Key

Reuse Private Key for Service Generated CSRs

Reuses the original private key when renewing the certificate. The default is No.

Allow Users to Import Duplicate Certificates and Reuse Private Keys

Controls the reuse of certificates and private keys. When enabled, this permits you to import a certificate even if another certificate with the same private key already exists in the system. It would also allow you to renew a certificate without uploading / re-generating a new private key.

When disabled, if you are renewing a certificate with a user-provided CSR, you cannot reuse a CSR that is tied to a private key that has ever been uploaded to Trust Protection Platform. Also, when importing a certificate manually, through WebSDK and Web UI, you won't be able to upload a certificate that is already in the inventory.

We recommend you leave this option disabled (unchecked).

NOTE  If you enable this option, you must have Write permission for the original certificate. Failing to have this permission will result in the system producing an error message: Duplicate Certificate. Insufficient Permissions to View Existing Certificate.

Key Algorithm

The allowable algorithm for certificate encryption. Works in conjunction with Elliptic Curve. The default is RSA. Choose either RSA or ECC (Elliptic Curve Cryptography).

Key Strength

The certificate key strength. The default is 2048.

If the key strength value conflicts with what the application can handle/requires, the application ignores the policy and sets the value accordingly. For example, if you set this value to 2048-bit encryption, but the target application cannot handle 2048-bit certificates, Trust Protection Platform generates the certificate CSR using 1024-bit encryption.

Elliptic Curve

The ECC size. Works in conjunction with Key Algorithm. The default is P256.

NOTE  The most broadly supported elliptic curve is P256. The other curves, P384 and P521, may be rejected by some CAs that support ECC.

Other Information

CA Template

CA Template object that reTrust Protection Platformferences to generate the CSR and submit it to the CA.

Key Generation

Encryption key to generate the certificate private key.

By default, Trust Protection Platform provides an AES-256 encryption key—the Venafi Platform software key—to generate private keys. However, you can also configure Trust Protection Platform to use AES encryption keys stored on supported HSM devices to generate certificate private keys. Your system is protected by either a hardware or a software encryption key (or both).

Encryption Key

Encryption key to use to protect the certificate private key.

The system uses either a hardware or software key (or both). The software encryption key secures data in the Trust Protection Platform database, and is stored in the Windows registry.

You can also configure Trust Protection Platform to use AES encryption keys stored on supported HSM devices to encrypt your system certificates.

For information, see Managing system encryption keys .

Disable Automatic Renewal:

Disables enrollment and provisioning for the current certificate. This means that Venafi TLS Protect does not attempt to renew or install the current certificate. However, Venafi TLS Protect still provides monitoring, validation, and notification for the certificate object. Additionally, the certificate is represented in Dashboard statistics and system reports. The default is No.

Trust Protection Platform automatically selects this option when it renews a certificate in response to a SCEP request.

Allow Simple Passwords for Private Key Downloads

The setting to control whether simple or strong passwords are required for private key downloads. The default is No.

Private Key PBE (password-based encryption) algorithm

This setting applies to private keys that are downloaded using the PEM format. Options include: Insecure but good system compatibility, Insecure but better system compatibility (SHA1 3DES), High security but low system compatibility (SHA256 AES256), The default is High security but low system compatibility (SHA256 AES256). You should not change it unless you have an incompatible system that cannot be upgraded.

For more information, see Using PBE (password-based encryption) algorithms to secure private keys.

NOTE  The algorithms used to derive the protection key and encrypt the private key are not supported by all applications. Generally, the more secure the protection key and algorithm, the fewer applications will support it.

Renewal Window

Number of days prior to expiration that Trust Protection Platform begins the renewal operation.

The default and recommended value is 30 days.

Validation

The purpose of Network Validation is to confirm that the certificate is functional and to verify that the correct certificate is being used. Network Validation requires network access to the server where the application is installed.

Disable SSL/TLS Validation

Disables Network Validation, including all related notifications, for subordinate Certificate objects.

Network Port

Port that the Validation Manager uses to connect to the server where the application is installed.

The Validation Manager uses an SSL connection to validate the application’s associated certificate. The default port is 443.

Use certificate's Common Name

Require validation scans to use a DNS lookup to resolve the certificate Common Name. Validation occurs on the certificate at every IP address returned from the DNS lookup. The default is Yes.

Use certificate's DNS Subject Alternative Names

Require validation scans to validate DNS Subject Alternative Names (SANs) of the certificate, if any. The default is No.

Validate the chain returned by the hosting server

Validate the chain returned by the hosting server to the chain that Trust Protection Platform builds using its internal algorithm to ensure a match. The default is yes, meaning chain validation is enabled and it affects the SSL/TLS validation result.

Approved Certificate Authorities

Available only in the Root Policy object.

Approved for Issuance

Available only in the Root Policy object. Select certificate authorities (CAs) you want to be considered trusted and approved issuers.

This list is useful in identifying certificates issued by unapproved CAs. You can configure the Critical Alerts widget in the product dashboard to identify certificates that do not match your approved CA list.

Active Directory Certificate Authentication

Device, user, server, and certificates policy settings related to Active Directory certification authentication and SID (security identifier).

Allow certificates with AD Security Identifier (SID)

The default is No.

If set to No, Trust Protection Platform will not allow certificates with an SID extension.

Allow security identifiers outside of connected identities

The default is No.

Controls whether Trust Protection Platform allows unknown SID (security identifier). If set to No and Trust Protection Platform cannot find the provided SID value in AD, the certificate request is rejected.

Automatically include requester identity

The default is Yes.

Applies to WebSDK. If set to Yes, the WebSDK requester identity is set as the AD security identifier (SID) identity, unless provided with the request. If Trust Protection Platform cannot resolve objectSid from the WebSDK requester identity, it is ignored. If the resolved SID value doesn’t match the policy settings, then the request is rejected.

AD Security Identifier source

Choose between:

  • Look up SID from AD Identity. Resolves SID from the provided AD identity.

  • Enter SID manually. Manually-specified SID. Supports macros. Main use case for macros is to set a setting on a policy and lock it. If a macro is provided with the request, the Allow security identifiers outside of connected identities setting must be set to Yes.