Configuring Bots
Setting up scan targets involves specifying the locations, systems or assets that automated bots will scan to identify and assess digital certificates. This ensures that certificates across your infrastructure are valid, up-to-date and correctly configured. The scan targets define which servers, applications or networks will be monitored. This section explains how to configure a CERTInext Bot for certificate discovery by defining where the Bot should scan (scan targets) and how often it should scan (scan schedule). This is the exact flow you follow from the UI: Discovery Bots → Action → Configure.
Open the Bot Configuration Page
• Navigate to Certificates → Discovery Bots. • Locate the Bot you want to configure. • Click Select Action → Configure.
When you open Configure, you will see two major portions:
• Bot Information: confirms the bot identity, OS, purpose, and whether it is currently online/usable. • Scan Targets: where you configure each source type (Web/App servers, AWS, Cloudflare, F5, etc.) that the Bot will scan to discover certificates.
Bot Information
The Bot Information section is not just a “summary”. It tells you whether the Bot you selected is the correct one, whether it can run discovery and what capabilities it has based on its purpose and platform.
[1] Bot Name
• This is the unique name of the Bot instance that was registered to CERTInext. • It usually reflects the host machine name / identifier (example shown in the screenshot: LAP443-1401261638).
[2] Bot Version
• This is the agent version installed on the Bot machine (example shown: 2.4.0.0).
[3] OS
• Displays the operating system running the Bot (example shown: Microsoft Windows 11).
[4] Purpose (Required Field)
• The Bot is configured with a specific purpose; your screenshot shows Discovery and Provisioning.
[5] Status
• This indicates whether the platform currently sees the Bot as usable (example shown: Active).
Configure Scan Targets
The Configure Scan Targets section defines where the CERTInext Bot will look for SSL/TLS certificates: servers, network devices, cloud platforms, directories and hardware modules.
Scan Scheduling
For every scan type, CERTInext lets you control when and how often SSL/TLS scans run on the configured targets.
• You can run a scan immediately (On Demand). • Or you can schedule scans to run automatically at Daily, Weekly or Monthly intervals. • Advanced Settings (when enabled) allow finer control of timing and recurrence.
Each configuration panel has a Scan Frequency section with the following options:
• On Demand • Daily • Weekly • Monthly
[1] Web / App Servers
Scan SSL/TLS certificates exposed on web and application servers.
Required Details
Field (as in UI)
Description
Enter FQDN, IP address or IP address range
Target host(s) to be scanned for certificates. Accepts FQDNs, single IPs, IP ranges or CIDR blocks.
Port Type
Choose Default ports or Custom TCP port for SSL/TLS discovery.
TCP Port
When Port Type is Custom, specify the TCP port to scan (for example 443, 8443).
Action (+)
Add multiple hosts/ranges into a single scan configuration.
Example Format
You can define targets in any of the following forms:
• Single IP: 192.168.10.25 • IP Range: 192.168.10.25-192.168.10.60 • Subnet (CIDR): 192.168.10.0/24 • Fully Qualified Domain Name (FQDN): app.example.com
Example configuration:
Enter FQDN, IP address or IP address range:
app.example.com Port Type: Custom TCP Port: 8443
[2] File System
Scan local or network-mounted file systems for certificate files.
Required Details
Field
Description
File System Path (optional)
Directory path to scan for certificate files (for example C:\certs or /var/certs). Can be left blank to scan default paths (depending on Bot configuration).
Scan Subfolders
When enabled, scans all subdirectories recursively under the specified path.
File Type*
One or more file extensions / categories to include (for example All, *.cer, *.pem, *.pfx, *.jks, *.crt).
Action (+)
Add multiple paths with different filters.
Example Format
File System Path: C:\certificates\ Scan Subfolders: [✓] File Type: All
[3] Remote File System
Scan remote shared folders using network credentials.
Required Details
Field
Description
IP Address*
IP of the remote file server hosting the share.
Share Path*
UNC or absolute path to the shared folder (for example \\fileserver\certshare or /mnt/share/certs).
Username*
Account used to authenticate against the remote share.
Password*
Password for the specified user.
File Type*
File formats to include in the scan.
Action (+)
Add multiple remote shares per bot.
Example Format
IP Address: XX.XX.X.XX Share Path: \file-srv01\ssl-certs Username: cert_example Password: fileexample File Type: All
[4] SSH
Discover and manage certificates stored on remote servers via SSH.
Required Details
Field
Description
Example
Host
Server IP address or hostname
XXX.X.XXX.XX
Username
SSH login username
Root
Password
SSH login password
MyServerPass123
Remote Directory
Path to certificate files
/etc/ssl/certs/
Where to Get These Details
Host
• The IP address or hostname of your server • Same address used for SSH access
Username & Password
• SSH credentials for the server • Recommend creating a dedicated service account
Remote Directory
• The directory path where certificates are stored • Common locations:
Path
Description
/etc/ssl/certs/
System certificates
/opt/cert/
Custom certificates
/var/www/ssl/
Web server certificates
Example Configuration
Host: XXX.X.XXX.XX Username: root Password: MyServerPass123 Remote Directory: /etc/ssl/certs/
[5] Remote Desktop (RDP)
Target Windows servers accessed via Remote Desktop (RDP) for certificate discovery.
[6] Certificate Store
Scan software-based certificate stores (for example system stores, browser stores) on the Bot machine or connected endpoints.
Required Details
This configuration does not require host-specific fields. It uses known certificate store locations.
[7] FortiGate
Discover certificates on FortiGate firewalls.
Required Details
Field
Description
IP Address*
Management IP / hostname of the FortiGate device.
FortiGate AuthToken*
API token generated from FortiGate for CERTInext access.
Action (+)
Add additional FortiGate devices.
Example Format
IP Address: fortigate-01.example.internal FortiGate AuthToken: FGTA2****************************…
[8] Cloudflare
Discover certificates for domains managed by Cloudflare.
Required Details
Field
Description
Email*
Cloudflare account email.
Auth Key*
Cloudflare Global API Key used for access.
Action (+)
Add multiple Cloudflare accounts if required.
Where to get these details
• Your Cloudflare login email address.
Auth Key (Global API Key)
• Login to Cloudflare Dashboard: https://dash.cloudflare.com • Navigate to My Profile → API Tokens • Under API Keys, find Global API Key • Click View → Enter password → Copy the key.
Zones & Certificates
• After saving credentials, CERTInext automatically fetches:
o All accessible Cloudflare zones. o Associated certificate configurations.
Example Configuration
Email: [email protected] Auth Key: 082d1e6*****************************...
[9] Palo Alto
Discover and manage certificates on Palo Alto firewalls using the API key.
Required Details
Field
Description
IP Address*
Management IP or hostname of the Palo Alto firewall.
PaloAlto AuthToken*
API key used for certificate discovery.
Action (+)
Add additional Palo Alto firewalls.
Where to Get These Details
IP/Host
• This is the firewall management interface address. • It is the same IP or hostname used to log in to the admin UI. • Example URL: https://pa.example.com
AuthToken (API Key)
Option 1: Generate via Web Interface
• Log in to Palo Alto firewall web UI. • Go to Device → Administrators. • Select your admin user. • Click Generate API Key. • Copy and store the key.
Option 2: Generate via API URL
https://<firewall-ip>/api/?type=keygen&user=<username>&password=<password>
The response contains:
<key>YOUR_API_KEY</key>
Example Configuration
IP/Host: pa.example.com AuthToken: LU**************************************…..
[10] F5 BIG-IP
Discover SSL/TLS certificates from F5 BIG-IP load balancers.
Required Details
Field
Description
IP Address*
Management IP of the F5 BIG-IP device.
Port
HTTPS/API management port (for example 443, 8443, or 7443).
Username*
F5 administrator / API user.
Password*
Password for the specified user.
Action (+)
Add multiple F5 devices.
Where to Get These Details
IP Address & Port
• The IP and port used to access the F5 BIG-IP web interface o Example URL: https:// XXX.XXX.XX.XXX:8443 o IP: XXX.XXX.XX.XXX o Web UI Port: 8443 o API Port: Usually 443 or 7443
Username & Password
• Your F5 BIG-IP administrator credentials • The account must have Administrator role
Virtual Server
• Log into F5 BIG-IP web interface • Navigate to Local Traffic > Virtual Servers > Virtual Server List • Note the name of your virtual server
Example Configuration
IP Address: XXX.XXX.XX.XXX Port: 7443 Username: admin Password: Admin@123 Virtual Server: vs-app-prod Web Interface URL: https://F5.net.example
[11] Akamai
Discover certificates deployed through Akamai using API client credentials.
Required Details
Field
Description
URL*
Akamai API base host (for example akab-xxxx.luna.akamaiapis.net).
Access Token*
Access token for API calls.
Client Token*
Client identifier token.
Client Secret*
Secret for signing Akamai API requests.
Group ID*
Numeric Group ID defining scope.
Contract ID*
Contract identifier (format W-XXXXXX).
Action (+)
Add multiple Akamai configurations.
Where to Get These Details
• Log into Akamai Control Center: https://control.akamai.com • Navigate to Identity & Access Management > API Users • Click Create API Client (or select existing client) • After creation, you'll see all credentials.
Important: Save the Client Secret immediately - it's only shown once.
Group ID & Contract ID
• Go to Account > Contract Management • Contract ID is displayed next to your contract (format: W-XXXXXX) • Click on your Group to see the Group ID
Example Configuration
Host: abcd.net Client Secret: uy**************** Access Token: access-example Client Token: client-example Group ID: 123456 Contract ID: W-123456 Verification URL: https://akamai_example.com (to verify deployment)
[12] Cloud Providers (AWS Certificate Manager)
Discover and manage certificates from AWS Certificate Manager (ACM).
Required Details
Field
Description
Access Key*
AWS IAM Access Key ID for the account used.
Secret Key*
AWS IAM Secret Access Key.
Role to Assume (Optional)
ARN or role name to assume for discovery (cross-account or delegated access).
Regions*
AWS region(s) where ACM discovery should run (for example us-east-1, ap-south-1).
Action (+)
Add additional AWS accounts / region sets.
Where to Get These Details
Region
• Found in the top-right corner of AWS Console
Access Key & Secret
• Log into AWS Console: https://console.aws.amazon.com • Go to IAM > Users > Select your user • Click Security credentials tab • Under Access keys, click Create access key • Save both values.
Access Key ID: AKIAIOSFODNN7EXAMPLE Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLE
Important: The Secret Access Key is only shown once!
Example Configuration
Region: us-east-1 Access Key: AKIAIOSFODNN7EXAMPLE Access Secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLE Username: aws-cert-discovery
[13] Kubernetes
Discover TLS certificates stored as Kubernetes Secrets in clusters.
Required Details
Field
Description
Example
Master URL*
Kubernetes API server endpoint (for example AKS/managed cluster API URL).
https://aks-demo-cluster:443
oAuth Token*
Bearer token for authenticating against the API server.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.sampletoken123...
Kubernetes Configuration Files (Upload / View)
Optionally upload a kubeconfig file that defines clusters, contexts and users.
(Upload kubeconfig)
AccessPoint (checkbox)
Marks this configuration as an access point to be used for discovery.
[✓]
Action (+)
Add multiple clusters.
—
Authentication Methods Supported
The CERTInext Kubernetes connector supports two independent authentication methods:
Token-Based Authentication (Master URL + Token)
• Requires:
o Master URL o Bearer Token
• CA Certificate is optional
Suitable for:
o Azure Kubernetes Service (AKS) o Other managed Kubernetes services o ServiceAccount token–based access
• When only the Master URL + Token are provided, the connector will automatically use token-based authentication.
Certificate-Based Authentication (mTLS)
• Requires:
o Master URL o CA Certificate o Client Certificate o Client Key
• All three certificate components are mandatory. Suitable for:
o Self-managed clusters o Security-hardened Kubernetes environments (e.g., clusters requiring mTLS client authentication)
Where to Get These Details
• URL (API Server Endpoint)
From Azure AKS: o Go to Azure Portal → Kubernetes services o Select your cluster o Find API server address in the Overview section
Example: https://aks-demo-cluster:443
From kubectl: kubectl cluster-info
• OAuth Token (Service Account Token)
To generate a bearer token for API access:
o Create service account
kubectl create serviceaccount demo-sa
o Create role binding (Cluster Admin used as example)
kubectl create clusterrolebinding demo-admin \ --clusterrole=cluster-admin \ --serviceaccount=default:demo-sa
o For Kubernetes 1.24+, manually create token secret
kubectl apply -f - <<EOF apiVersion: v1 kind: Secret metadata: name: demo-sa-token annotations: kubernetes.io/service-account.name: demo-sa type: kubernetes.io/service-account-token EOF
o Retrieve the bearer token
kubectl get secret demo-sa-token -o jsonpath='{.data.token}' | base64 -d
Example Configuration
URL: https://aks-demo-cluster:443 Key: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.sampletoken123... Namespace: ingress-nginx AccessPoint: [✓]
[14] HSM (Hardware Security Module)
Discover and validate certificates and keys that are stored in HSMs.
Required Details
Field
Description
HSM Configuration*
HSM configuration file or connection definition (uploaded or pasted).
HSM Password*
Password / PIN used to open the HSM slot.
Certificates (checkbox)
Include certificates during discovery.
Keys (checkbox)
Include cryptographic keys in the scan scope (if allowed).
Status
Shows current connection state (for example Pending).
Action (+ / …)
Add or manage HSM entries.
Example Format
HSM Configuration: [Uploaded configuration file] HSM Password: hsm_example Certificates: [✓] Keys: [✓] Status: Pending
[15] LDAP / Active Directory
Discover certificates stored in LDAP or Active Directory directories.
Required Details
Field
Description
LDAP URL*
LDAP or LDAPS URL including host and port (for example ldap://X.XX.XXX.XX:389).
Container*
Base DN where certificates or objects are located (for example dc=example,dc= example,dc= example).
Admin DN*
Bind DN or domain\user used for authentication (for example_admin ).
Password*
Password for the Admin DN user.
No. of threads*
Multi-threading configuration defining parallel discovery threads.
Status
Shows connection state (for example Pending).
Action (+)
Add or test multiple LDAP directories.
Example Format
LDAP URL: ldap://X.XX.XXX.XX:389 Container: dc= example, dc= example ,dc= example Admin DN: example_admin Password: ******** No. of threads: 5 Status: Pending
[16] Database
Discover certificates associated with database servers.
Required Details
Field
Description
Enter FQDN, IP address or IP address range*
Database host (single IP, FQDN or range).
TCP Port*
Database listener port (for example 1433, 1521, 3306).
DB Name*
Database name or instance identifier.
Action (+)
Configure multiple database targets.
Example Format
Enter FQDN, IP address or IP address range: sql-prod-01.example.internal TCP Port: 1433 DB Name: CertinextDB
[17] ADCS
This section configures discovery through AD CS. This discovery is directly done through the issuing CA. You need to create a CA connector to fetch and discover certificates from ADCS.
Field
Description
CA Connector Select Option*
ADCS Connector
Action (+)
Configure multiple database targets.
Add Certificate
This section explains how certificates can be manually added into CERTInext for discovery and inventory purposes. Certificates can be added either by creating a new certificate record or by importing an existing certificate.
From the UI, navigate to:
Certificates → Discovery Dashboard → Add Certificate
The Type field provides two options:
• Create • Import
Create
The Create option is used to manually create a certificate record within CERTInext when a physical certificate file is not available. This method allows users to define the certificate identity and basic attributes for tracking and inventory purposes.
Fields
• Common Name (Required) → The primary domain name or identifier for the certificate. • Subject Alternative Name (Optional) → Additional identities associated with the certificate: • IP Address • DNS Name
These values are stored as certificate metadata and help in associating the certificate with the correct hosts or services. Once the required details are entered, clicking Add creates the certificate record in CERTInext.
Import
The Import option is used to onboard certificates that already exist in the environment. This allows organizations to bring external certificates into CERTInext for visibility, monitoring and audit purposes without performing automated discovery scans. The Selection Type field determines the import method.
Selection Types
The following import methods are supported:
[1] Certificate
This option allows you to import a single certificate file.
You must: • Select Certificate as the Selection Type • Upload a certificate file
Supported file formats:.cer, .crt, .pem, .der, .p7b
This method is used when the certificate is available as an individual file.
[2] Certificate Data
This option allows you to import a certificate by pasting its contents directly.
You must:
• Select Certificate Data as the Selection Type • Paste the Base64-encoded certificate content into the input field
This method is useful when the certificate is available in text format, for example copied from a server or configuration file.
[3] Key Store
This option allows you to import certificates from a keystore file.
You must:
• Select Key Store as the Selection Type • Upload a keystore file • Enter the keystore password
Supported file formats: .pfx, .p12, .pkcs12, .jks, .keystore, .jceks
This method is commonly used for Java keystores or PKCS#12 bundles that contain certificates and private keys.
[4] Bulk Import
CERTInext provides the ability to bulk import certificates into the Discovery module using Excel or CSV templates. This feature is useful when certificates already exist in your environment and need to be tracked, monitored or audited within CERTInext without running an automated discovery scan. All successfully imported certificates are visible in the Discovery Dashboard and are clearly marked as imported.
Supported Import File Formats
CERTInext supports bulk certificate import using the following file formats: • .xlsx • .xls • .csv
The file must follow the CERTInext import template structure.
Certificate Import Template Format
The import file must contain certificate data in a structured format. Each row represents a single certificate.
Certificate Content (Base64) - This is a required column This column must contain the full Base64-encoded certificate content.
Note: The certificate content may include the BEGIN CERTIFICATE and END CERTIFICATE headers or may be provided as plain Base64 content. Both formats are supported for Excel and CSV templates.
The following fields are optional and can be used to enrich certificate metadata:
CN (Optional) DNS (Optional) IP (Optional) Port (Optional)
If these values are provided, CERTInext associates them with the imported certificate. If left empty, the certificate is still imported successfully.
Note: If a row in the import file is completely blank, CERTInext automatically ignores and skips that row during processing.
How to Import Certificates
• Navigate to Certificates → Discovery→ Add Certificate • Select Import as the certificate type • Choose Bulk Import as the selection type • Upload the completed Excel or CSV file • Click Add to start the import process
CERTInext validates each row in the file and processes the certificates accordingly.
Note: The recommended maximum number of certificates per import file is 500. Files containing more than 500 certificates can also be uploaded; however, very large files may take longer to process depending on system performance.
During processing, system messages are displayed on the same screen indicating:
• Successfully imported • Already exists • Failed to import (with reason)
These messages act as processing logs for the operation.
Import Result Summary
After completion, CERTInext displays a summary showing:
• Number of certificates imported successfully • Number of certificates that already exist • Number of certificates that failed to import
Row-level results are also displayed for troubleshooting.
Import Outcome Scenarios
Successful Import
When a certificate is valid and does not already exist in CERTInext:
• The certificate is imported successfully • A success message is displayed • The certificate appears in the Discovery inventory
Certificate Already Exists
When a certificate being uploaded already exists in CERTInext:
• The certificate is not duplicated • The import result indicates that the certificate already exists • The existing certificate remains unchanged
Invalid Certificate Format
When the Base64 certificate content cannot be parsed or is invalid:
• The certificate import fails for that row • The reason for failure is clearly displayed • Other valid certificates in the file continue to be processed
Mixed Import Results
In a single bulk import, different certificates may produce different outcomes:
• Some certificates are imported successfully • Some are skipped because they already exist • Some fail due to invalid format or content
CERTInext provides a consolidated summary along with row-level details explaining each outcome.
Add CA Certificate
This section allows you to add and track certificates that are issued by a specific Certificate Authority (CA) within CERTInext. From the UI, navigate to:
Certificates → Discovery Dashboard → Add CA Certificate
Select the CA panel and click Add CA Cert.
CA Name
The CA Name field allows you to select the Certificate Authority to which the certificate belongs.
The following options are available:
• Private PKI by emCA → Used for certificates issued by an emCA-managed private PKI. • Let’s Encrypt → Used for certificates issued by Let’s Encrypt. • AD CS → Used for certificates issued by Microsoft Active Directory Certificate Services. • Others → Used for certificates issued by any external or third-party CA not explicitly listed.
Selecting a CA ensures that the certificate is correctly associated with its issuing authority for classification, reporting, and lifecycle tracking.
Selection Type
The Selection Type field determines how the CA certificate will be added into CERTInext.
The following options are available:
• Certificate
This option allows you to upload a CA certificate file directly.
You must:
o Select Certificate o Upload the CA certificate file
Supported formats include: .cer, .crt, .pem, .der, .p7b
This method is used when the CA certificate is available as a file.
• Certificate Data
This option allows you to add a CA certificate by pasting its contents directly.
You must:
o Select Certificate Data o Paste the Base64-encoded CA certificate content into the input field
This method is useful when the CA certificate is available in text format.
Add
Once the CA Name and Selection Type are selected and the required certificate data is provided, click Add to register the CA certificate. The CA certificate is then added to CERTInext and becomes visible in the CA inventory. It is included in certificate counts and can be used for reporting, monitoring, and trust chain analysis.
Last updated