Configuring a Provisioning Bot

Provisioning Configuration:

The Provisioning Configuration section defines how a certificate will be issued, generated, and deployed to a target server. This page brings together all required inputs such as deployment mapping, certificate authority selection, CSR handling, key store details, validation settings and provisioning controls. It allows users to either use automatically detected deployment information or manually configure values based on their environment. The configuration is designed to simplify certificate deployment by using information already collected from the system where the Bot is installed. If deployment details are available from the initial system scan, they are automatically suggested to the user. These values can be accepted as is or overridden manually if a different setup is required.Provisioning Logic

During Bot installation, a system level scan is automatically performed regardless of whether the Bot is installed for Discovery mode or Provisioning mode. This initial scan is a standard step and is used to understand the environment in which the Bot is deployed.

The scan uses system level inspection methods along with filtering techniques to identify supported servers present on the host machine. System commands and grep based checks are used to evaluate running processes and active services. These checks help determine which server components are currently installed and operational.

The detection logic focuses only on servers that are actively running at the time of installation. By filtering process and service level information, the system differentiates between applications that are installed and those that are actually in use. Only servers confirmed to be active are considered valid targets for provisioning.

Once identified, the platform maps these detected servers to supported provisioning workflows. The collected information is stored and later used to automatically populate deployment details when configuring certificate provisioning. This is why the Deployment Details section shows that values have already been detected and can be used directly or modified manually. In environments where the Bot and the certificate are associated with the same host or IP address, the system can automatically suggest the appropriate Provisioning Bot and available server types. This reduces manual selection and ensures that provisioning is mapped to the correct machine.

Provisioning Configuration Page

Step 1: Deployment Details

The Deployment Details section defines the deployment target and the Bot that will perform provisioning actions on the target system. This section also determines which server-specific configuration fields are required.

Deployment Type

• Automatic → Select Automatic when deployment details have been detected by the Bot installation scan. In this mode, the platform uses the detected mapping as the suggested configuration for the certificate deployment target.

• Manual → Select Manual when the detected values are not correct or when the certificate must be deployed to a different target than the one detected. Manual mode is used when deployment mapping must be explicitly configured by selecting the required server and entering the correct values.

Provision Bot

Select the provisioning Bot that will execute the provisioning workflow for the selected certificate. The selected Bot must have access to the deployment target. For agent-based deployments, this is typically the Bot installed on the same machine where the server is running. For agentless deployments, this is the Bot that has network connectivity and permissions to reach the remote target.

Agentless Server

Use this field when the deployment target is configured as an agentless endpoint. An agentless endpoint is a target that is provisioned remotely without installing a Bot on that target machine. When an agentless server is selected, the platform uses the selected Bot to connect to the remote endpoint and perform provisioning using the configured integration or remote access method.

Server Type

Server Type defines the platform where the certificate will be deployed. Selecting a server type determines which additional configuration fields are required. The fields displayed below this selection change based on the chosen server type. Each server requires different configuration inputs.

Available server types include:

• Windows Store

• Tomcat

• Apache HTTP

• IIS

• JBoss

• Jetty

• WebLogic

• Nginx

• Kubernetes

• F5 BIG-IP

• F5 BIG-IQ

• Imperva Cloud

• Imperva On-Prem

• Akamai Cloud

• FTP

• SFTP

Each server type requires different configuration fields. Once a server type is selected, additional input fields appear based on that platform.

Examples:

If Apache HTTP is selected:

• Apache HTTP Path must be provided

• Keystore path must be provided

If Tomcat is selected:

• Tomcat home path must be provided

• Keystore details must be configured

If F5, Imperva, or Akamai is selected:

• API connection details and deployment targets are required

The fields shown on screen change based on the selected server type. Fill all required fields specific to that platform.

Fig: Deployment Details

Step 2: Certificate Authority

This section defines which Certificate Authority will issue the certificate.

• CA → Select the Certificate Authority from the available list.

• CA Connector Name → Select the connector associated with the selected CA. This connector is responsible for sending the CSR, retrieving the issued certificate and handling renewals.

Fig: Certificate Authority

Step 3: Certificate Signing Request Configuration

This section defines how the certificate request is generated and what identity and cryptographic details will be used for certificate issuance. The values configured here directly determine how the certificate will be created by the Certificate Authority and how it will be installed on the target server.

Users must choose one of the following CSR configuration modes based on the provisioning objective.

Option 1: Use Existing Certificate CSR

Select this option when rotating, renewing, or replacing an existing certificate without changing the identity details.

Use this when:

• The Common Name remains the same

• SAN entries remain the same

• The certificate is being renewed or reissued

• No cryptographic changes are required

In this mode, the system extracts CSR details from the existing certificate already installed on the server.

Fields to configure:

• Key Store Type → Select the keystore format where the certificate and private key will be stored. Example: PKCS12

• Key Store Password → Enter the password that protects the keystore file and private key. This is required for deployment and future renewal operations.

• SANs (Comma Separated) → Add additional domains if needed. If left empty, existing SAN values are reused.

• Common Name → Enter the primary domain name. This should match the existing certificate identity.

This mode is recommended for standard certificate rotation where no configuration changes are required.

Fig: Use Existing Certificate CSR

Option 2: Partial Override

Select this option when some certificate parameters need to be updated while keeping the base identity information.

Use this when:

• Changing certificate type (DV, OV, EV)

• Updating SAN entries

• Changing cryptographic strength

• Updating signing algorithm

• Adjusting key size

Fields available for configuration:

• Certificate Type → DV, OV, EV, Existing

  • Select DV for basic domain validation.

  • Select OV or EV for higher validation levels.

• Signature Algorithm → Example: SHA1WithRSA

  • This defines how the certificate will be signed.

• Key Algorithm → Example: RSA

  • Defines the encryption method used to generate the private key.

• Key Size

  • Select the required key strength.

  • Higher values increase security but may impact performance.

• Key Store Details

  • Key Store Type → Select the format for storing the certificate. PKCS12 is commonly used.

• Key Store Password

  • Required to protect access to the private key.

• SANs (Comma Separated)

  • Enter all additional domains that must be covered by the certificate.

• Common Name

  • Enter the primary domain.

Partial Override keeps the original CSR foundation but allows controlled modifications.

Fig: Partial Override CSR

Option 3: Full Override (Select Certificate Profile)

Select this option when creating a completely new certificate request with a fresh configuration.

Use this when:

• Issuing a new certificate

• Changing the domain identity

• Moving to a new server

• Applying a different CSR template

• Creating a new key pair

Fields available:

• Certificate Type → DV, OV, EV, Others

• Existing or New CSR

  • Select Existing if reusing a template

  • Select New to generate a fresh request

• CSR Template → Select a predefined template that contains certificate configuration settings such as:

  • Key type

  • Key size

  • Subject structure

  • Cryptographic rules

• Key Store Details

  • Key Store Type → Example: PKCS12

• Key Store Password → Required to secure the keystore.

• SANs → Enter all domains to be covered.

• Common Name → Enter the primary domain.

This mode provides full control over certificate creation and is used for new deployments or major configuration changes.

Fig: Full Override CSR

Step 4: Domain Control Validation (DCV)

This section defines how domain ownership will be verified before the certificate is issued by the Certificate Authority. Domain validation is a mandatory step for DV, OV and EV certificates. The configuration here determines whether validation will be completed automatically by the Bot or manually by the user.

Attempt DCV using Filename at location

Enable this option to allow the platform to perform automatic file based validation using the Provision Bot. When this option is enabled, the system will create a validation token file and place it in the specified directory on the server. The Certificate Authority checks for this token file through the public domain to confirm ownership.

DCV Path

Enter the exact directory path on the server where the validation file should be placed.

The DCV path must meet the following conditions:

• The path must exist on the target server

• The Provision Bot must have write access to this path

• The server must expose this path through the domain being validated

• The validation file must be accessible publicly via the domain

This path is typically the web root directory of the application server.

Automatic DCV Flow

When DCV is enabled and a valid path is configured, the validation process is completed automatically through the following sequence:

• The certificate request is created and submitted to the CA.

• The system generates a DCV token file.

• The Provision Bot writes the token file to the configured DCV path.

• A getDCV trigger is initiated from the platform.

• The getDCV pulse instructs the Bot to verify and expose the validation file.

• The Certificate Authority attempts to access the validation token through the domain.

• Once the CA confirms the token, domain ownership is validated.

• Certificate issuance proceeds automatically.

The getDCV trigger is a system driven validation signal that initiates the domain verification step after the token is placed. This ensures the CA checks for the file at the correct time.

Automatic DCV succeeds only when:

• The domain resolves to the server where the Bot is installed

• The validation file is correctly written to the specified location

• The file is reachable through HTTP or HTTPS using the domain

• The Bot has the required permissions

If the token file cannot be placed, accessed, or verified, automatic validation will not complete.

Manual DCV Flow

If automatic DCV is not enabled or if validation cannot be completed automatically, the process shifts to manual validation.

Manual DCV occurs in the following cases:

• The DCV option is not selected

• The DCV path is invalid or inaccessible

• The server is not publicly reachable

• The Bot does not have write permissions

In manual mode:

• After the certificate request is submitted, the user receives a Track Order email from the CA.

• The email contains instructions for completing domain validation.

• The user must follow the instructions provided by the CA to complete validation manually.

• Once validation is completed, certificate issuance continues.

Manual validation may involve placing a file manually, validating via email approval, or completing DNS based verification depending on CA requirements.

Fig: Domain Control Validation (DCV)

Step 5: Provisioning Schedule

This section controls how provisioning failures are handled, when certificates are renewed, and when new certificates are deployed to the server. These settings ensure continuous certificate lifecycle management without service interruption.

Enable roll back if provisioning fails

When this option is enabled, the system protects service continuity during deployment failures.

If a provisioning attempt fails:

• The system automatically restores the previously active certificate

• The server continues operating with the last known working configuration

• Service downtime is prevented

This setting is strongly recommended for production environments where certificate deployment errors must not impact live applications.

Enable Renewal

This option enables automatic certificate renewal before expiration. When enabled, the system continuously monitors the certificate validity period and triggers renewal based on the configured conditions.

How to trigger renewal

Two trigger methods are available.

Days before expiry → Select this option to renew the certificate automatically a defined number of days before it expires. Renew when within → Enter the number of days before expiry when renewal should begin. Example: Entering 30 means renewal starts when the certificate has 30 days remaining.

On a specific date → Select this option to trigger renewal on a fixed calendar date. Date → Select the date on which renewal should begin.

Renewal Frequency

Defines how often the platform checks whether the certificate is due for renewal.

Available options:

• Daily → The system checks every day.

• Weekly → The system checks once a week.

• Monthly → The system checks once a month.

More frequent checks ensure timely renewal and reduce the risk of expiration.

Time

Defines the exact time when the renewal check process runs. This allows alignment with maintenance windows or low traffic periods. Time zone selection ensures the renewal trigger runs according to the intended regional time.

Fig: Provisioning Schedule

Enable Deployment

This setting controls when the newly issued certificate will be installed on the target server after successful renewal. If this option is not enabled, the certificate will be issued but not deployed automatically.

When to deploy

Two deployment trigger options are available.

• Immediately after successful renewal → The certificate is deployed to the server as soon as it is issued. This is the recommended option for fully automated environments.

• On a specific date → Deployment is scheduled for a defined date and time. This is useful for environments that require controlled rollout during approved maintenance windows.

Deployment Date and Time

If deployment on a specific date is selected:

• Date → Select the deployment date.

• Time → Set the exact deployment time.

• Time zone → Select the appropriate time zone for execution.

Deployment Frequency

Defines how often deployment jobs run when scheduled.

Available options:

• Daily

• Weekly

• Monthly

This is used in scheduled deployment scenarios where rollout is controlled.

Fig: Deployment Frequency

End to End Provisioning Lifecycle with Scheduling

When renewal and deployment are both enabled:

• The system continuously monitors certificate validity.

• Renewal is triggered based on the configured rules.

• CSR is generated using the selected configuration.

• DCV validation is triggered automatically if configured.

• The CA issues the certificate.

• Deployment is triggered based on deployment settings.

• If deployment fails, rollback restores the previous certificate.

This configuration enables a fully automated certificate lifecycle with validation, issuance, deployment, and failure protection handled automatically.

Final Step: Certificate Lifecycle Management Actions After Provisioning Configuration

Once all provisioning configuration steps are completed and saved successfully, the selected Provision Bot becomes mapped to the certificate. At this stage, the certificate transitions from a discovered state to a managed state under the Certificate Lifecycle Management workflow.

From the Provisioning Dashboard, users can now perform lifecycle operations directly on individual certificates or on multiple certificates together. These actions are available through the Select Action menu for each certificate entry.

This section explains each available operation and when it should be used.

Each certificate entry includes an Action menu that exposes the available lifecycle controls. The sections below explain each operation, its purpose, when it should be used, and what happens when it is executed.

[1] Certificate Initiation

Purpose → Initiates the provisioning workflow for a discovered certificate that has not yet been formally enrolled or managed by the platform.

This operation should be used when a certificate has been identified during discovery but has not yet entered the managed provisioning lifecycle. It is typically the first step in converting a discovered certificate into a managed certificate.

This is commonly used in the following scenarios:

• Initial onboarding of servers into CLM

• Bringing legacy certificates under centralized management

• Preparing a certificate for renewal automation

• Starting the issuance workflow for a discovered endpoint

When Initiate Certificate is triggered:

• The selected provisioning configuration is applied

• The mapped Provision Bot is linked to the certificate

• CSR preparation begins based on the configured CSR mode

• Domain Control Validation workflow is prepared

• The certificate moves into the issuance pipeline

This step prepares the certificate for ordering and deployment without immediately replacing the existing certificate.

[2] Certificate Ordering

Purpose → Submits a certificate request to the configured Certificate Authority.

This operation is used when a new certificate must be issued for a server, application, or endpoint.

Typical use cases include:

• Deploying a certificate on a new server

• Replacing an existing certificate nearing expiration

• Issuing a certificate for a newly onboarded domain

• Migrating to a new CA

When Order Certificate is triggered:

• CSR data is generated or reused based on CSR configuration

• CA and connector settings are applied

• The request is transmitted securely to the CA

• DCV validation begins if required

• The certificate enters the CA issuance workflow

The certificate is not deployed at this stage. It is only requested and issued.

[3] Certificate Deployment

Purpose → Installs the issued certificate onto the target system using the mapped Provision Bot.

This operation is used when the certificate has already been issued and must be installed on the server.

Typical scenarios include:

• Installing a newly issued certificate

• Completing a provisioning workflow

• Deploying a renewed certificate

• Updating keystores on production systems

When Deploy Certificate is triggered:

• The Provision Bot connects to the target system

• The certificate and private key are transferred securely

• The certificate is stored in the configured keystore location

• Server configuration files may be updated

• Services may be restarted if required by the platform

This step completes the provisioning cycle by placing the certificate into active use.

[4] Certificate Deletion

Purpose → Removes the certificate entry from lifecycle tracking within the platform.

This should be used only when the certificate is no longer required to be managed.

Typical scenarios:

• Certificate added incorrectly

• Decommissioned systems

• Test or temporary certificates

• Cleanup of unused entries

When Delete Certificate is triggered:

• The certificate record is removed from the system database

• Lifecycle tracking stops

• Renewal and deployment automation is disabled

This action typically does not remove the certificate from the server unless explicitly configured through additional workflows.

[5] Certificate Pinning Verification

Purpose → Validates that the certificate deployed on the server matches the expected certificate stored in the platform.

This operation is used for compliance validation and security assurance.

Typical scenarios:

• Verifying deployment success

• Checking certificate integrity after manual changes

• Confirming pinned certificate consistency

• Security audit validation

When Re-check Pinning is triggered:

• The system scans the target endpoint

• The currently deployed certificate is retrieved

• The certificate fingerprint is compared with the platform record

• Mismatches are reported

This ensures the correct certificate is installed and trusted.

[6] Certificate Rotation

Purpose → Replaces an existing certificate with a newly issued one while maintaining continuity.

This operation is used for planned replacement of certificates as part of lifecycle maintenance.

Typical scenarios:

• Certificate nearing expiration

• Routine lifecycle refresh

• Migration to stronger cryptographic settings

• Compliance driven replacement cycles

When Rotate is triggered:

• A new CSR is generated

• A new certificate is issued from the CA

• The new certificate is deployed to the server

• The existing certificate is replaced

• Service continuity is maintained

Rotation ensures uninterrupted service while updating the certificate.

[7] Certificate Rekey

Purpose → Generates a new private key and issues a new certificate tied to that key.

This operation is used when cryptographic security needs to be strengthened or a key compromise is suspected.

Typical scenarios:

• Security policy requiring periodic key replacement

• Key compromise incidents

• Transition to stronger cryptographic standards

• Compliance driven key lifecycle controls

When Rekey is triggered:

• A completely new key pair is generated

• A new CSR is created using the new key

• A new certificate is issued by the CA

• The new certificate is deployed to the server

This ensures that both the key and certificate are replaced together.

[8] Certificate Revocation or Suspension

Purpose → Immediately invalidates a certificate at the CA level.

This is a critical security operation and should be used in high risk scenarios.

Typical scenarios:

• Private key compromise

• Unauthorized certificate usage

• System breach

• Decommissioned domain or service

When Revoke or Suspend is triggered:

• A revocation request is sent to the CA

• The certificate is added to the revocation list

• Systems performing revocation checks will stop trusting the certificate

This operation prevents further trust in the certificate across all systems.

Fig: CLM Actions after Provisioning

Bulk Configure and Batch Configure

When multiple certificates are selected in the Provisioning Dashboard, two configuration options become available at the bottom of the screen: Bulk Configure and Batch Configure. These options are designed to help administrators manage and provision certificates at scale without repeating the same steps individually for each certificate.

Although both options operate on multiple certificates, they serve different purposes. One is used to apply configuration settings, and the other is used to execute provisioning actions.

Bulk Configure

Purpose → Bulk Configure is used to apply the same configuration settings to multiple certificates at once. It helps standardize how certificates are issued, validated, renewed, and deployed across a large number of servers or applications. This option does not perform provisioning actions. Instead, it updates the configuration that will be used when provisioning or renewal occurs.

Bulk Configure should be used when multiple certificates must follow the same policy or configuration.

Common scenarios include:

• Onboarding a large number of servers into the platform

• Migrating certificates from one CA to another

• Applying a new cryptographic standard across the environment

• Standardizing renewal schedules and deployment settings

• Assigning the same CSR profile to multiple certificates

• Enforcing consistent SAN naming formats

• Updating key algorithms or key sizes for compliance

This is typically the first step in large scale provisioning projects.

When Bulk Configure is selected:

• A common certificate profile can be applied to all selected certificates

• CSR settings such as key size, key algorithm, and signature algorithm can be standardized

• Renewal rules can be applied uniformly

• CA connector mappings can be aligned

• Provisioning policies can be made consistent across all selected endpoints

These settings will be used later when certificates are issued, renewed, or rotated.

How to Use

1. Select multiple certificates from the provisioning dashboard using the checkboxes.

2. Click Bulk Configure.

3. Apply the required configuration settings such as CSR profile, renewal policy, and deployment rules.

4. Save the configuration.

After saving, all selected certificates will use the same provisioning configuration moving forward. This ensures consistency across environments and reduces manual errors.

Practical Example

An organization needs to enforce a new security standard requiring RSA 3072 keys and a one year validity period across 500 servers.

Using Bulk Configure:

• All 500 certificates are selected

• The new key size and validity settings are applied once

• The configuration is saved

From that point onward, all selected certificates follow the same security policy.

Batch Configure

Purpose → Batch Configure is used to perform provisioning operations on multiple certificates at the same time. Unlike Bulk Configure, which applies settings, Batch Configure executes actions. This is used to run lifecycle operations across many certificates simultaneously.

Batch Configure should be used when multiple certificates need to be processed operationally.

Common scenarios include:

• Enrolling certificates on multiple servers

• Performing mass renewals before expiration

• Deploying certificates across multiple endpoints

• Rotating certificates as part of lifecycle maintenance

• Rekeying certificates after a policy change

• Installing certificates across clusters or infrastructure groups

This is typically used after Bulk Configure has been completed.

When Batch Configure is selected:

• CSR generation can be triggered for all selected certificates

• Certificate enrollment requests are sent to the CA

• Issued certificates are deployed to mapped servers

• Renewals can be executed in parallel

• Installation tasks run across multiple systems

This allows provisioning operations to run at scale without manual repetition.

How to Use

1. Select multiple certificates from the provisioning dashboard.

2. Click Batch Configure.

3. Choose the lifecycle action to execute, such as enroll, deploy, renew, rotate, or rekey.

4. Submit the operation.

The platform then performs the selected action across all chosen certificates.

Practical Example

An environment has 300 certificates that are nearing expiration within the next 30 days.

Using Batch Configure:

• All 300 certificates are selected

• Renewal is triggered in one operation

• The platform generates CSRs, submits requests, and deploys renewed certificates

This avoids renewing each certificate individually.

Fig: Bulk Configure

Fig: Batch Configure

Fig: Configuration Settings

Certificate Lifecycle Management Flow - Overview

This diagram illustrates how CERTInext enables end-to-end certificate lifecycle management by connecting discovery and provisioning into a continuous automated process. The workflow begins with the installation of the CERTInext Bot, which can be configured for discovery, provisioning, or both based on deployment requirements. During discovery, the bot scans the environment to identify active servers, applications, and existing certificates. It supports both agentless and agent-based approaches, allowing organizations to collect configuration details and build a centralized certificate inventory. These discovered details are automatically stored and later used to simplify provisioning configuration.

On the provisioning side, the provisioning bot uses the discovered deployment information to automate certificate issuance and installation. The process includes integration with CA connectors, CSR handling, domain validation and scheduling, followed by automated deployment of certificates to target systems.

The discovery inventory acts as the foundation for provisioning by providing accurate system and certificate visibility. After certificates are deployed, CERTInext performs continuous rediscovery to validate installations, update inventory records and maintain lifecycle accuracy. This creates a closed-loop process where discovery feeds provisioning, and provisioning updates discovery, ensuring certificates remain consistently managed, tracked and renewed across the environment.