# 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** **Email** • Your Cloudflare login email address. **Auth Key (Global API Key)** • Login to Cloudflare Dashboard: \ • 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: \ 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: **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\://\/api/?type=keygen\&user=\\&password=\ The response contains: \YOUR\_API\_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:

**\[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: \ • 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: (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: \ • 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: 1. **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. 2. **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:\ 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 - <\\ 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** 1. 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

2. **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

3. **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

4. **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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.certinext.io/documentation/certificate-lifecycle-management/discovering-certificates/scan-using-bots/configuring-bots.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.