Provisioning a Certificate

The Provision Certificates module in CERTInext enables organizations to automate the issuance, renewal and deployment of certificates across servers, applications, load balancers and user endpoints. Using provisioning bots and Certificate Authority (CA) integrations, CERTInext ensures that certificates are securely delivered to target systems and maintained throughout their lifecycle.

Provisioning works in conjunction with certificate discovery and inventory, allowing enterprises to move from visibility to full automation. Whether managing a small set of certificates or operating at enterprise scale, the Provisioning module simplifies certificate operations while reducing manual effort and deployment risk.

The module allows administrators to configure end-to-end provisioning workflows by selecting the issuing CA, defining key and certificate parameters, and mapping deployment bots to target systems. Once configured, certificates can be automatically issued, renewed, and securely deployed to designated servers, load balancers, and applications without manual intervention.

Provisioning Dashboard

The Provisioning Dashboard provides a centralized view of all certificate provisioning activity. It allows administrators to monitor bot health, certificate readiness, deployment progress and S/MIME provisioning status from a single interface.

To access the dashboard, navigate to:

Certificates → Provisioning

The dashboard is designed to support both operational monitoring and troubleshooting by presenting real-time metrics and direct navigation into detailed views.

Provisioning Overview

At the top of the dashboard, a brief overview describes the scope of provisioning within CERTInext. This section highlights that provisioning automates:

• Certificate issuance and renewal using public or private CAs

• Secure certificate deployment to configured target systems

• Ongoing lifecycle management through provisioning bots

This overview establishes the provisioning workflow before users interact with detailed metrics.

Fig: Provisioning Certificates Dashboard

Provisioning Certificates Dashboard Overview

Bot Overview

The Bot Overview section provides visibility into the status of all provisioning bots configured for the account. Provisioning bots are responsible for executing certificate deployment and renewal actions within target environments.

The following metrics are displayed:

• Total Bots → All provisioning agents deployed to automate certificate deployment. These intelligent agents automatically install, update and manage certificates on your servers and applications, reducing manual work and human error

• Active → Provisioning agents currently working on certificate deployments. These bots are actively installing certificates, monitoring for updates, and ensuring systems maintain secure, up-to-date encryption.

• Pending → Provisioning agents awaiting setup or configuration. These bots are registered but need to be configured with deployment targets and policies before they can begin automating certificate management.

• Stopped → Provisioning agents that have been paused or disabled. These bots are not currently managing certificates. Review this list to ensure critical systems maintain active automation coverage.

Each metric on the dashboard is clickable. Selecting any tile, such as Total Bots, Active, Pending or Stopped, filters the bot list to display only the bots in that category, allowing administrators to quickly review their status.

Create Bot → Allows administrators to create and register a new provisioning bot. Provisioning bots are used to automate certificate deployment, renewal, and installation across servers, applications, and load balancers. Once registered and configured, these bots securely deliver issued or renewed certificates to designated target systems and enforce lifecycle automation across the infrastructure.

Fig: Provisioning Bot Overview

Provisioning Configuration Summary

This section provides a consolidated snapshot of certificate readiness and server availability for provisioning.

Note: Throughout the Provisioning dashboard, information icons (ℹ️) are available next to key metrics. Hovering over these icons provides contextual explanations to help users quickly understand what each metric represents and what actions may be required.

Provisioning Results

Certificates

The certificate summary reflects how certificates are progressing through the provisioning lifecycle.

• Total Certs → Total certificates available for provisioning. This list is directly populated from the discovery dashboard.

• Bot Unassigned → Certificates ready for deployment but not yet assigned to an automation agent. These certificates have been ordered or generated but need to be assigned to a provisioning bot to automate their installation on target systems

• Configuration Pending → Certificates that are awaiting further deployment configuration details. These certificates need additional information (like target servers, installation paths, or binding configurations) before they can be automatically deployed.

• Deployment Pending → Certificates fully configured and queued for installation. These are ready to be deployed to your servers. The provisioning bot will install them according to the scheduled deployment plan.

• Deployment Failed → Certificate deployments that encountered errors during installation. These failed deployments need investigation. Common issues include permission problems, connectivity issues, or incompatible certificate formats. Action required to resolve.

Each metric is clickable and opens a filtered view of the corresponding certificates, enabling administrators to quickly review their status and take necessary actions.

Server

The Server summary reflects the status of agentless server connections configured for provisioning. These servers are remote systems that are accessed by the CERTInext Bot using secure protocols to perform certificate deployment operations.

• Total → Total number of servers added for agentless provisioning. These are the servers configured using IP address, credentials, and server type details for remote deployment.

• Mapped Servers → Servers that have been successfully associated with a provisioning bot. Mapping ensures that the selected bot is responsible for handling certificate deployment to those specific systems.

• Active → Servers that are reachable and ready for certificate deployment. These systems are available for provisioning actions such as installation, renewal, rotation and updates.

Fig: Certificates - Provisioning Configuration Summary

S/MIME Provisioning

The S/MIME Provisioning section focuses on certificate provisioning for enterprise email users. This module integrates with Azure Active Directory to discover users and automate S/MIME certificate issuance, deployment and configuration. This capability enables organizations to roll out secure email encryption and digital signing at scale.

Secure enterprise email with S/MIME by discovering users via Azure Active Directory and automating certificate issuance, deployment, and setup. This ensures encryption, digital signatures, and message integrity for Outlook users across the organization.

Displayed metrics include:

• Total Users → All employees in your Azure Active Directory eligible for email security certificates.

• Awaiting Orders → Employees ready for S/MIME certificates but orders not yet submitted. These users have been identified for email security but their certificates haven't been requested from the Certificate Authority yet. Initiate orders to enable secure email for these users.

• Provisioned → Employees successfully equipped with S/MIME email security certificates.

The Connect to Azure AD option is used to establish or manage the directory integration required for S/MIME provisioning.

Fig: S/MIME Provisioning overview

Provisioning Orders

Provisioning Orders provide visibility into certificate issuance and deployment requests generated by provisioning workflows.

This section displays:

• Total Orders → All S/MIME certificate requests submitted to the Certificate Authority. This tracks your organization's email security certificate orders from initial request through final issuance, providing complete visibility into the provisioning process.

• CSR Pending → Certificate orders awaiting Certificate Signing Request (CSR) submission. The CSR contains the user's public key and identity information. These orders need CSR creation and submission to the Certificate Authority before certificates can be issued.

• Certificate Issued → Successfully issued S/MIME certificates ready for distribution. The Certificate Authority has approved and issued these certificates. They can now be distributed to users, enabling secure, signed, and encrypted email communication.

These metrics help administrators track provisioning progress from request creation through certificate issuance.

Fig: Provisioning Orders

Manage Provisioning Bots Dashboard

The Provisioning Bots dashboard enables administrators to manage bots used for certificate provisioning activities. These bots execute certificate issuance, renewal and deployment tasks across configured environments and target systems.

All provisioning-capable bots are listed in a centralized view, providing administrators with visibility into bot health, configuration status and operational readiness.

Navigation Path

Certificates → Provisioning → Bots

Selecting Total Bots, Active, Pending or Stopped from the Provisioning Dashboard opens this Bots listing view.

Provisioning Bots Overview

The Bots page displays all provisioning bots associated with the account. Each bot represents a deployed agent installed within a specific network, environment, or location.

From this dashboard, administrators can:

• Create new provisioning bots

• Review bot connectivity and operational status

• Filter and search bots using key attributes

• Customize visible columns for focused analysis

• Export bot data for audits and reporting

• Perform bot configuration and lifecycle actions

Bots Table Overview

Each row in the table represents a single provisioning bot and displays key operational metadata.

Bot Attributes

• Bot Name → A unique identifier assigned during bot creation. Used to distinguish bots across environments such as production, staging, or regional deployments.

• IP Address → The network address of the system where the bot is installed. Helps validate network placement and troubleshoot connectivity issues.

• Description → An optional field used to capture purpose, environment or regional context.

• Status → Indicates the current operational state of the bot:

  • Active

  • Pending

  • Stopped

  • Inactive

  This allows administrators to quickly identify bots that require attention.

• Last Bot Update → Timestamp of the most recent communication between the bot and the CERTInext platform.

• Bot Version → Displays the installed bot software version. Useful for upgrade tracking and version consistency.

• Purpose → Indicates whether the bot is configured for:

  • Provisioning

  • Discovery

  • Discovery and Provisioning

• Group → Logical grouping used to organize bots across teams, environments or business units.

• Bot Token → A unique authentication token generated during bot creation. Used by the bot to securely communicate with CERTInext.

• OS → The operating system on which the bot is installed (for example, Microsoft Windows or Linux).

• Created Date → The date and time when the bot was created in CERTInext.

• Created By → The user who created the bot.

• Tags → User-defined key-value tags used for classification, filtering and reporting purposes.

Fig: Provisioning Dashboard (Bots)

Filtering and Search

The Provisioning Bots dashboard supports advanced filtering to quickly locate specific bots based on operational, administrative, or organizational attributes.

Each filter consists of three components:

• Column → The attribute to filter on

• Operator → The condition applied to the selected column

• Value → The value used for comparison

Multiple filters can be combined to refine the results.

Supported Filter Columns

Administrators can filter bots using the following attributes:

• Bot Name

• Status

• Purpose

• Group

• Bot Version

• Bot Token

• Created Date

• Created By

• Last Bot Update

• Tags

Supported Operators

The available operators depend on the selected column type.

Text-Based Columns

(Example: Bot Name, Group, Created By, Tags, Bot Token)

Supported operators:

• Contains

• Equals

These operators match bots based on partial or exact text values.

Status and Purpose Columns

Supported operators:

• Equals

Supported values include:

For Status:

• Active

• Pending

• Stopped

• Inactive

• Pending Activation

For Purpose:

• Provisioning

• Discovery

• Discovery and Provisioning

Date-Based Columns

(Example: Created Date, Last Bot Update)

Supported operators:

• Before

• After

These operators allow administrators to filter bots based on a specific date or time range.

Examples:

• Last Bot Update Before 05-Feb-2026

• Created Date After 01-Jan-2026

Filter Values

The Value field defines the comparison input for the selected filter.

• For text and status-based filters, values are selected or entered directly.

• For date-based filters, a date/time value is selected.

• The value “All” can be used to include all possible values for a selected column, effectively removing restriction for that attribute while retaining other applied filters.

Example Filter Scenarios

• Display all active provisioning bots: Status = Active AND Purpose = Provisioning

• Identify bots that have not communicated recently: Last Bot Update Before 01-Feb-2026

• Locate bots created after a specific rollout date: Created Date After 15-Jan-2026

Customize Columns

Administrators can tailor the table view by selecting which columns are displayed.

Default Columns

• Bot Name

• IP Address

• Description

• Status

• Last Bot Update

• Bot Version

Additional Columns Available

• Group

• OS

• Created Date

• Created By

• Tags

This flexibility supports operational troubleshooting, compliance audits, inventory reporting, and lifecycle tracking.

Fig: Customize Columns

Export Options

The Provisioning Bots dashboard supports exporting bot data directly from the interface. Exported data reflects the currently applied filters and column selections.

• Export to Excel Used for compliance reporting, audits, inventory tracking, and operational analysis.

• Export to PDF Used for offline documentation, management summaries, and external reporting.

Actions Menu

Each bot row includes a Select Action menu that provides lifecycle controls.

Available Actions

• Configure Bot Allows administrators to modify bot configuration attributes such as purpose, grouping or metadata.

• Delete Bot Removes the bot record from CERTInext. This should be performed only after the bot has been decommissioned from the host system.

These actions allow administrators to manage provisioning bots throughout their lifecycle from a single interface.

Provisioning Certificates Page

The Provisioning Certificates page provides a centralized view of certificates discovered by provisioning bots and allows administrators to initiate, configure, deploy, rotate, or manage certificates as part of the automated provisioning lifecycle. This page acts as the operational bridge between discovery and active certificate lifecycle management, enabling administrators to move certificates from a discovered state into managed, issued, and deployed states.

Accessing the Page

Navigate to: Certificates → Provisioning → Provisioning Certificates

Page Overview

The Provisioning Certificates page displays a tabular view of certificates that are eligible for provisioning actions. These certificates are typically discovered by provisioning bots, imported into the provisioning workflow, and prepared for issuance, deployment, renewal, or rotation. The page provides operational visibility into certificate ownership, location, expiry timelines, issuing authority, and provisioning readiness, allowing administrators to manage certificate lifecycle activities from a single interface.

Each row in the table represents one certificate entry detected within the environment and provides contextual information required to assess and manage provisioning operations.

Fig: Provisioning Certificates

Certificate List View - Column Details

• CN / SAN Name → Displays the certificate identity, showing the Common Name or the primary Subject Alternative Name associated with the certificate. This helps identify the system, application, or domain where the certificate is used.

• Discovery Bot → Indicates the bot that originally detected the certificate in the environment, providing traceability into where the certificate was discovered.

• Provisioning Bot → Shows the bot assigned to perform lifecycle operations such as issuance, deployment, renewal, and rotation. If not assigned, it may appear as “Not Mapped.”

• Issuer CA → Identifies the Certificate Authority responsible for issuing the certificate, helping distinguish between internal enterprise CAs and public CAs.

• CA Type → Indicates whether the certificate belongs to a Public CA or a Private CA environment, which is important for governance and policy alignment.

• Certificate Location → Displays where the certificate was detected, typically represented as a hostname/IP and port combination (for example, domain:443 or IP:port).

• Signature Algorithm → Shows the cryptographic signature algorithm used by the certificate, such as SHA256RSA or SHA384RSA, useful for security validation.

• Expires On → Displays the certificate expiration date and time, helping administrators plan renewal activities.

• Expires Within → Shows the remaining validity duration in days, allowing quick identification of certificates nearing expiration.

• Order ID → Represents the CA order reference number associated with the certificate if it has been issued through a CA integration.

• Organization → Displays the organization mapping associated with the certificate within the platform.

• Tags → Shows metadata labels assigned to the certificate, useful for classification, grouping, and ownership tracking.

• Status → Indicates the current lifecycle state of the certificate, such as Discovered, Initiated, Issued, Deployed, Rolled Back, or Order Pending.

• Batch Name → Displays the batch identifier if the certificate is part of a bulk provisioning operation.

• Scan IP Address → Indicates the IP address from which the certificate was detected during discovery (visible through column customization).

• Scan Port → Displays the network port on which the certificate was identified (visible through column customization).

• Issued On → Shows the date on which the certificate was issued by the Certificate Authority.

• Last Provisioned On → Displays the most recent timestamp when a provisioning action was performed on the certificate.

• Validation Status → Indicates the validation state of the certificate where applicable.

• DCV Status → Displays the Domain Control Validation status associated with the certificate issuance process.

• Deployment Type → Indicates how the certificate is deployed, such as automated provisioning or manual deployment.

• Serial Number → Displays the unique serial number assigned to the certificate.

• Vulnerable → Indicates whether the certificate is flagged as weak, outdated, or non-compliant based on policy checks.

Per-Certificate Action Menu

Each certificate row includes a Select Action dropdown that provides certificate-specific lifecycle operations.

• Configure → Opens the provisioning configuration screen for the selected certificate, allowing administrators to define CA mapping, provisioning bot assignment, deployment targets, and lifecycle parameters before initiating provisioning.

• Download Certificate → Allows administrators to download the certificate file in the supported format for backup, inspection, or manual deployment purposes.

• Certificate Details → Displays a detailed metadata view of the certificate, including issuer information, validity period, key size, serial number, thumbprint, and certificate constraints for validation and troubleshooting.

• View Certificate → Presents the certificate in a decoded, readable X.509 format showing subject, issuer, validity, signature algorithm, and public key details for inspection.

• Ignore → Excludes the certificate from provisioning workflows without deleting it from the inventory, useful when certain discovered certificates are not intended to be managed.

• Delete → Removes the certificate entry from the provisioning inventory, preventing it from appearing in provisioning workflows or operational views.

Server Configuration

The Add Server section allows administrators to register application servers for agentless provisioning. This configuration enables CERTInext to remotely connect to target servers, locate certificate stores, and perform lifecycle operations such as deployment, renewal, and rotation.

In an agentless model, the CERTInext Bot is installed on a central system and remotely manages certificates on application servers by identifying certificate locations, deploying new certificates, replacing expiring certificates and triggering service reloads.

To perform these lifecycle operations, CERTInext connects to configured servers using secure remote access protocols based on the target system’s operating system.

Communication Mechanism Used in Agentless Provisioning

CERTInext uses standard operating system protocols to securely access remote servers depending on the platform type. The connection method varies for Windows and Linux-based systems.

Windows Servers - SMB Based Connection

For Windows-based environments, CERTInext connects using SMB (Server Message Block), a standard Windows protocol for secure file and directory access. SMB allows the provisioning bot to securely access remote directories, copy certificate files and interact with configuration locations on Windows servers. Using the credentials provided during server configuration, the bot authenticates to the target system and performs the following operations:

• Access certificate storage directories

• Copy new certificate and key files

• Replace existing certificates

• Update configuration locations where applicable

• Restart or reload application services using the defined service name

This method is commonly used for IIS, Tomcat, Apache and other application servers running on Windows systems.

Linux Servers - SSH Based Connection

For Linux and Unix-based environments, CERTInext connects using SSH (Secure Shell). SSH provides secure command-line level access to remote systems. Using the configured username and password, the provisioning bot establishes a secure session with the server and performs certificate deployment tasks.

Through SSH, the bot can:

• Navigate to application installation directories

• Locate SSL configuration files

• Copy certificate and key files to defined paths

• Update configuration references

• Restart or reload application services

This method is used for servers such as Nginx, Apache HTTP, Tomcat, JBoss, Jetty and WebLogic running on Linux systems.

To establish this connection, administrators must register each server using the Add Server form by providing IP address, credentials, server type and application path details. Once configured, the provisioning bot can remotely access the system, locate the required configuration files and perform certificate installation and updates.

Below is a detailed explanation of each field available in the Add Server form.

Common Fields (Applicable to All Server Types)

• Description → A user-defined name to identify the server entry. This helps distinguish environments such as Production, UAT, Load Balancer Node, etc.

• IP Address → The IP address of the target server where the application is hosted. CERTInext connects to this system for certificate deployment and lifecycle operations.

• Username → The login username used to authenticate to the server remotely.

• Password → The password associated with the provided username for secure access.

• Server Type → Specifies the application server installed on the system. Based on this selection, CERTInext prompts for server-specific path details.

• Key Store Folder Path → Directory where certificates/keystores are stored on the server. Used during deployment and replacement operations.

• Version → Version of the selected server (for example: Apache 2.4, Tomcat 9, Nginx 1.18). Helps ensure compatibility with deployment logic.

• Ports → Port numbers used by the application server for SSL communication (for example: 443, 8443).

• Service Name → System service name used to restart or reload the application after certificate deployment.

Server-Specific Path Fields

Tomcat

• Tomcat Path → Root installation directory of the Tomcat server (for example: /opt/tomcat or C:\Program Files\Apache Tomcat). This path is used to locate SSL connector configurations and keystore references within server.xml and related configuration files.

Apache HTTP

• Apache HTTP Path → Installation/configuration directory of Apache HTTP Server (for example: /etc/httpd/, /usr/local/apache2/, or C:\Apache24). CERTInext uses this path to locate SSL configuration files (httpd.conf, ssl.conf) and identify certificate deployment locations.

Nginx

• Nginx Path → Base installation or configuration directory of Nginx (for example: /etc/nginx/). Used to locate nginx.conf and SSL certificate/key references for deployment and replacement.

IIS

• Key Store Folder Path (Primary field for IIS) → For IIS, certificates are typically managed through the Windows Certificate Store. This path points to the location where certificate files or export artifacts are stored if applicable. IIS bindings are updated during deployment.

JBoss

• JBoss Path → Installation directory of the JBoss server (for example: /opt/jboss/ or domain/server configuration path). Used to identify SSL configuration files and keystore references within the JBoss configuration structure.

Jetty

• Jetty Path → Root directory of the Jetty server installation. CERTInext uses this path to locate SSL connector configurations and keystore definitions inside Jetty configuration files.

WebLogic

• WebLogic Path → Domain or installation directory of WebLogic. Used to locate keystore configurations and SSL settings associated with managed servers and admin servers.

Fig: Add Server Details

S/MIME Provisioning

The S/MIME Provisioning module enables secure enterprise email communication by issuing and deploying user-level S/MIME certificates. It integrates with identity sources such as Azure Active Directory to discover users and automate certificate provisioning, ensuring encryption, digital signatures, and message integrity across the organization.

Administrators can manage provisioning through:

• Automated user discovery

• Manual user import

• Profile-based configuration using Azure AD credentials

• Lifecycle tracking through the dashboard

Certificates → Provisioning Dashboard → Provisioning

This screen displays all users identified for S/MIME certificate provisioning.

S/MIME Provisioning List

The S/MIME Provisioning List presents a structured list of users for whom S/MIME certificates can be issued, tracked, and managed. Each row represents one user account mapped for certificate provisioning.

• Name → Displays the full name of the user identified for S/MIME provisioning.

• Email → Primary email address associated with the user. This email is used as the certificate identity for secure mail encryption and signing.

• Status → Indicates the current provisioning stage of the user’s S/MIME certificate lifecycle.

Common values include:

• Awaiting Order

• CSR Pending

• Certificate Issued

• Certificate Installed

• Ignored

This provides quick visibility into provisioning progress.

• Designation → Displays the user’s role or job title as received from the identity source or manual entry. Helps in identifying ownership and business context.

• Source → Indicates how the user was discovered or added.

Examples:

• Azure AD Test

• Manual Import

This helps distinguish automated discovery from manually added users.

• Expiry Date → Displays the certificate expiry date once a certificate has been issued. If provisioning has not started, this may appear blank.

• Action → Provides user-specific operational controls.

Primary action:

• Ignore Email → Excludes the selected user from provisioning workflows.

Fig: S/MIME Provisioning

Filter Capability

The dashboard supports filtering to locate specific users. Filters allow administrators to narrow results based on attributes such as:

• Name

• Email

• Status

• Designation

• Source

Filters support structured operators:

• Contains

• Equals

For status filtering, the Value dropdown allows selection of lifecycle states such as:

• Awaiting Order

• CSR Pending

• Certificate Issued

• Certificate Installed

• Ignored

This enables precise identification of users at specific provisioning stages.

Import Manually

Administrators can manually add users for S/MIME provisioning when they are not available through directory integration.

Access Path

Click Import Manually on the dashboard.

Form Fields:

• Name → Full name of the user to be provisioned.

• Email ID → Primary email address that will be used to generate the S/MIME certificate.

• Designation → User’s role or department identifier. Helps with organizational classification and reporting.

Actions

• Save → Adds the user to the provisioning dashboard and marks them ready for certificate processing.

• Reset → Clears all entered values.

This method is typically used for:

• External users

• Pilot testing

• Non-directory environments

Fig: Import Manually

Create a New Profile

Profiles are used to integrate with Azure Active Directory for automated user discovery and provisioning.

Access Path

Click Create a new profile

Purpose

Profiles store secure credentials required to connect to Azure AD and retrieve user details. Once configured, users from Azure AD appear automatically in the dashboard.

Form Fields:

• Client ID → Azure application client identifier used for authentication.

• Client Secret → Secure key associated with the Azure application.

• Tenant ID → Azure directory identifier representing the organization.

• Description → Profile name or identifier used to distinguish integrations (Example: Azure AD – Production).

Actions

• Save → Creates and activates the profile, enabling automated user discovery.

• Reset → Clears all entered values.

Fig: Create a New Profile

CA Connectors

CA connectors (Certification Authority connectors) are software or middleware components that allow systems, applications, or services to integrate with Certification Authorities (CAs) for the management and automation of digital certificates within an organization’s IT infrastructure.

A Certification Authority (CA) is a trusted entity responsible for issuing, validating, renewing, and revoking digital certificates. These certificates are used to establish secure communication, verify identity, enable encryption, and support digital signing across systems, users, applications, and devices. CAs form the backbone of a Public Key Infrastructure (PKI), ensuring that identities and systems can be trusted within secure environments.

In enterprise environments, organizations typically work with both private and public CAs.

Private CA → Private CAs are used internally to issue certificates for enterprise applications, internal domains, user authentication, devices, VPNs and internal services. They provide full control, policy enforcement and customization.

Public CA → Public CAs are used to issue publicly trusted certificates for external-facing services such as websites, public APIs, and internet-facing platforms. Certificates issued by public CAs are trusted by browsers and operating systems globally.

The CA Connectors section in CERTInext allows administrators to integrate the platform with different Certification Authorities so that certificate issuance, renewal, and lifecycle operations can be automated from a single interface. Once a CA connector is configured, CERTInext can directly communicate with the CA to request, renew and manage certificates without manual intervention.

The platform supports multiple CA integrations, including emSign, emCA, AD CS, and DigiCert. emSign and emCA are eMudhra-specific Certification Authorities. emSign is primarily used as a public CA offering publicly trusted certificates, while emCA is used as a private PKI solution for enterprise environments. AD CS is Microsoft’s private CA solution used within Active Directory environments. DigiCert is a globally trusted public CA used for external certificate issuance. Each connector allows CERTInext to securely authenticate with the respective CA and perform certificate lifecycle operations such as issuance, renewal, rotation, and provisioning.

Fig: CA Connectors

Types of Certification Authorities Supported

[1] emSign CA (Public CA - eMudhra)

emSign is a globally trusted public Certification Authority from eMudhra that issues publicly trusted SSL/TLS and enterprise certificates. It is used for securing internet-facing applications, APIs, websites, and external services that require globally recognized trust across browsers, operating systems, and devices.

[2] emCA (Private CA - eMudhra Enterprise PKI)

emCA is eMudhra’s enterprise-grade private PKI solution used for internal certificate issuance and lifecycle management. It enables organizations to issue and manage certificates for internal domains, users, devices, applications, and services, while maintaining full control over policies, identity validation, and trust frameworks. emCA supports enterprise-scale deployments requiring centralized governance and secure internal trust models.

[3] AD CS (Private CA - Microsoft Active Directory Certificate Services)

AD CS is Microsoft’s native enterprise PKI solution integrated with Active Directory. It is commonly used for domain-based certificate issuance such as user certificates, machine authentication, internal TLS certificates, and enterprise identity validation.

[4] DigiCert (Public CA)

DigiCert is supported as a public CA integration for organizations that use DigiCert for issuing certificates for external-facing applications, websites, and services.

Why CA Connectors Are Required

CA connectors act as a bridge between CERTInext and the Certification Authority. Without configuring a CA connector, provisioning workflows cannot request certificates from a CA.

They enable:

• Automated certificate issuance

• Secure communication with the CA

• Centralized certificate lifecycle management

• Renewal and rotation automation

• Policy-driven provisioning

Once configured, the connector can be used in provisioning workflows to request and deploy certificates automatically.

Adding a CA Connector

Each CA type has its own configuration form because authentication methods, policies, and integration mechanisms differ.

[1] emSign Connector

This page allows you to configure the connection between CERTInext and emSign. By providing the required API URLs and authentication details, you can enable secure communication and renew certificates directly through emSign before they expire.

emSign Connector - List Page

This page displays all configured emSign connectors.

Columns available:

• Name → Displays the configured connector name.

• Base URL → Shows the emSign API endpoint used for certificate operations.

• Status → Indicates whether the connector is active.

• Actions → Provides management controls for the connector:

  • Edit Template → Allows modification of connector details.

  • Disable Template → Temporarily disables the connector.

  • Delete Template → Permanently removes the connector configuration.

Use the + Create button to add a new CA connector. This connector enables integration with the emSign public CA using API-based communication.

Add Connector - Field Details

• Name → A unique identifier for the connector. This helps administrators distinguish between multiple connectors such as sandbox and production environments.

• emSign API Base URL → The API endpoint used to communicate with the emSign system. This URL is environment-specific and must point to the correct emSign service.

• emSign Account Number → The customer account identifier assigned by emSign. This links certificate requests to the correct account.

• emSign AccessKey → The authentication key used to securely access emSign APIs. This acts as the credential for API communication.

• Full Name → The profile name associated with the connector identity. Typically represents the administrative or service identity.

• Email → The email linked with the connector profile for identification and record tracking.

Purpose of this connector: Allows CERTInext to request, issue, and renew publicly trusted certificates from emSign.

Fig: Create emSign Connector

[2] emCA Connector Configuration

This page allows you to configure the connection between CERTInext and emCA. By providing the required API URLs and authentication details, you can enable secure communication and renew certificates directly through emCA before they expire.

emCA Connector - List Page

This page displays all configured emCA connectors.

Columns available:

• Name → Displays the configured connector name.

• Base URL → Shows the emCA API endpoint used for certificate operations.

• Status → Indicates whether the connector is active.

• Actions → Provides management controls for the connector:

  • Edit Template → Allows modification of connector details.

  • Disable Template → Temporarily disables the connector.

  • Delete Template → Permanently removes the connector configuration.

Fig: emCA Connector

Use the + Create button to add a new CA connector. This connector integrates CERTInext with emCA, the private enterprise PKI solution from eMudhra.

Add Connector - Field Details

• emCA Version → Specifies the version of emCA deployed in the environment. This ensures compatibility with the correct API format.

• Name → Friendly name used to identify the connector configuration.

• Base URL → The emCA API endpoint where certificate requests will be sent.

• Username → Service account username used to authenticate with emCA.

• Issuing CA → The name of the issuing CA within the emCA hierarchy that will sign the certificates.

• Subscriber ID → The organization-specific identifier provided in the emCA portal that maps requests to the correct tenant or account.

• Password → The password for the service account used to authenticate with emCA.

• Upload File → A required file used for establishing secure communication or validation as part of the emCA integration configuration.

Purpose of this connector: Used for internal enterprise certificate issuance, policy-controlled deployments, and private PKI management.

Fig: Create emCA Connector

[3] AD CS Connector Configuration

This page allows you to configure the connection between CERTInext and AD CS. By providing the required API URLs and authentication details, you can enable secure communication and renew certificates directly through AD CS before they expire.

AD CS Connector - List Page

This page displays all configured AD CS connectors.

Columns available:

• Name → Displays the configured connector name.

• Base URL → Web service URL used to communicate with AD CS

• Status → Indicates whether the connector is active.

• Actions → Provides management controls for the connector:

  • Edit Template → Allows modification of connector details.

  • Disable Template → Temporarily disables the connector.

  • Delete Template → Permanently removes the connector configuration.

Use the + Create button to add a new CA connector. This connector integrates CERTInext with Microsoft Active Directory Certificate Services.

Fig: AD CS Connector

Add Connector - Field Details

• Name → Identifier for the AD CS connector configuration.

• Base URL → The web service endpoint for the AD CS enrollment service, typically pointing to the certsrv path.

• CA Setup Type → Specifies whether the CA is a Standalone CA or an Enterprise CA.

• Standalone CA → Used when the CA operates independently without domain integration.

• Enterprise CA → Used when the CA is integrated with Active Directory and uses domain authentication.

• Username → Required when Enterprise CA is selected. Represents a domain service account used for authentication.

• Password → Password for the service account used to access AD CS services.

Purpose of this connector: Allows CERTInext to request and manage internal domain-based certificates in Windows enterprise environments.

Fig: Create AD CS Connector

[4] DigiCert Connector Configuration

This page allows you to configure the connection between CERTInext and Digicert. By providing the required API URLs and authentication details, you can enable secure communication and renew certificates directly through Digicert before they expire.

DigiCert Connector - List Page

This page displays all configured DigiCert connectors.

Columns available:

• Name → Displays the configured connector name.

• Base URL → Web service URL used to communicate with AD CS

• Status → Indicates whether the connector is active.

• Certificate Validity → Default validity period configured.

• Actions → Provides management controls for the connector:

  • Edit Template → Allows modification of connector details.

  • Disable Template → Temporarily disables the connector.

  • Delete Template → Permanently removes the connector configuration.

Use the + Create button to add a new CA connector.

This connector enables integration with DigiCert’s public CA services.

Fig: DigiCert Connector

Fields:

• Name → Identifier for the DigiCert connector configuration.

• DigiCert API Base URL → Endpoint used to communicate with DigiCert services.

• DigiCert API Key → Authentication key used to securely connect to DigiCert APIs.

• Server Platform ID → Identifier representing the server platform mapping in DigiCert.

• Organization ID → The organization identifier in the DigiCert system used to map certificate orders.

• Container ID → The container within DigiCert where certificate products are managed.

• Certificate Validity → Defines the validity period for issued certificates based on policy and allowed limits.

• Payment Type → Specifies how certificate issuance charges are handled.

• Balance → Uses available account balance for certificate issuance.

• Profile → Uses a configured billing profile for payment handling.

Purpose of this connector: Used for automated issuance and renewal of publicly trusted certificates from DigiCert.

Fig: Add DigiCert Connector