Automation Failures

This section addresses issues related to automated certificate issuance, renewal, and deployment within CERTInext. Automation failures typically occur during provisioning workflows involving CA connectors, DCV validation, provisioning bots, or deployment configurations.

Identifying and resolving automation failures quickly is critical to preventing certificate expiry, service disruption, or policy violations.

Common Automation Symptoms

Automation failures may present as:

• Certificate status stuck at Configuration Pending

• Deployment Failed in Provisioning Dashboard

• Renewal not triggered within expected window

• DCV status showing failed or pending

• Provisioning bot active but no deployment executed

• CA connector validation errors

Step 1: Verify Provisioning Bot Status

Navigate to: Certificates → Provisioning → Bots

Confirm:

• Bot status is Active

• Last Bot Update timestamp is recent

• Bot token has not expired

• Bot purpose includes Provisioning

If inactive:

• Restart bot service

• Revalidate network connectivity

• Confirm activation window has not expired

Step 2: Check CA Connector Health

Navigate to: Integrations → CA Connectors

Verify:

• Connector status is Active

• API endpoint is reachable

• Credentials are valid

• Template mapping exists

If connector test fails:

• Validate API keys or service account

• Confirm CA Web Enrollment (for AD CS) is accessible

• Ensure network firewall rules allow communication

Step 3: Review CSR and Template Configuration

Common issuance failures result from CSR mismatch.

Validate:

• Subject fields align with CA template requirements

• SAN entries are correctly formatted

• Key size and algorithm meet CA policy

• Selected certificate type (DV/OV/EV) is supported

Template mismatches may cause rejection at the CA level.

Step 4: Validate DCV (Domain Control Validation)

For public certificates:

• Check DCV method selected (HTTP-01 / DNS-01 / TLS-ALPN-01)

• Confirm DNS records propagated (for DNS-01)

• Ensure challenge file path is accessible (for HTTP-01)

• Verify port 443 accessibility (for TLS-ALPN-01)

DCV failures prevent certificate issuance.

Step 5: Check Deployment Configuration

If certificate is issued but deployment fails:

Review:

• Server Type configuration

• Keystore path permissions

• Service restart permissions

• WinRM / SSH access credentials

• Port bindings and service name

File permission or process ownership issues commonly cause deployment errors.

Step 6: Review Provisioning Logs

Navigate to:

Certificates → Provisioning → Bots → View Details

Review:

• Deployment logs

• Renewal trigger timestamps

• CSR submission logs

• Error messages

Logs typically indicate:

• Authentication failure

• Network timeout

• Keystore write failure

• Restart or reload failure

Step 7: Confirm Renewal Schedule

If renewal did not trigger:

Check:

• Renewal window configuration (e.g., 30 days before expiry)

• Frequency and execution time

• Time zone configuration (UTC)

• Bot availability during scheduled execution

Inactive bots during scheduled windows may cause missed renewals.

Step 8: Retry Operation

After correcting configuration:

• Re-run deployment

• Trigger manual renewal

• Re-initiate certificate order

• Restart bot service if required

CERTInext allows manual override for most automated tasks.

When to Escalate

Provide the following details:

• Certificate CN / SAN

• Provisioning Bot name

• CA connector name

• Error message from logs

• Renewal schedule configuration

• Recent infrastructure changes

Structured information accelerates resolution.

Best Practices

• Use a 30–45 day renewal window

• Enable rollback protection

• Regularly monitor Deployment Failed metrics

• Keep service accounts and credentials updated

• Test CA connector after infrastructure updates

Issue Examples

Please find the common Issue Examples related to 'Discovery' to troubleshoot:

ISSUE EXAMPLE-1 – Certificate Renewed in CERTInext but Not Updated on Server

Title

Certificate Renewed in CERTInext but Server Still Shows Old Certificate

Issue Description

• A certificate renewal order is completed, and the renewed certificate is visible in CERTInext.

• When accessing the website or service, the old certificate (with old expiry) is still presented.

• Renewal-linked provisioning bot shows “Stopped”.

Possible Causes

• Provisioning bot was never triggered after renewal (no post-renewal automation rule or misconfigured link).

• Provisioning bot completed with errors that were not reviewed.

• Service reload/restart step failed, leaving the process bound to the old certificate.

Resolution / Fix

1. Check Renewal bot and Linked Provisioning

   1. Open the renewal order in CERTInext and look for linked provisioning bot.

   2. Confirm whether a Provisioning bot was triggered.

2. Manually Trigger Provisioning for the Renewed Certificate

   1. If no Provisioning bot exists, create one using the updated certificate and relevant automation profile.

   2. Run the bot and monitor its status.

3. Verify Service Reload/Restart Logic

   1. Confirm the provisioning profile includes commands or actions to reload/restart web/application services as required by the target stack (IIS, Apache, NGINX, etc.).

   2. Validate that these commands work when executed manually on the target host.

4. Re-test Endpoint from another Browser

   1. After successful provision, clear browser cache or use another browser.

   2. Use a TLS inspection tool or openssl s_client -connect <host>:443 to verify the new certificate.

Validation / Confirmation

• Endpoint presents the renewed certificate with the new expiry date.

• CERTInext shows the certificate as deployed for that endpoint.

ISSUE EXAMPLE-2 – Deployment bot Stuck in “Deployment Pending” status

Title

Deployment bot Stuck in “Deployment Pending” status

Issue Description

• An Provisioning bot remains in “Deployment Pending” state much longer than typical deployment time.

• No clear success or failure is reported.

• Target system may or may not be updated.

Possible Causes

• Target system is slow or unreachable, causing long timeouts (network latency, firewall, or routing issues).

• Automation script or command on the target host is hanging (for example, waiting for user input).

• Resource constraints on the target host or provisioning bot (CPU/memory bottlenecks).

Resolution / Fix

1. Check Typical Provisioning Duration

   1. Compare the current bot duration with similar historical bots for the same target/profile.

   2. If significantly longer, proceed with deeper checks.

2. Inspect Bot Logs for Timeouts or Long Steps

   1. Download bot logs and look for steps that never complete or show repeated retries.

3. Verify Target Connectivity and Load

   1. From the provision bot host, test connectivity to the target service (if separate).

   2. Check CPU/RAM on the target host and ensure it is not overloaded or swapping heavily.

4. Review and Test Provision Commands Manually

   1. Identify the commands/scripts used in the Provision/Deployment profile.

   2. Execute them manually on the target host to see if they hang or prompt for interaction.

5. Cancel and Re-run with Reduced Scope

   1. Cancel the pending bot.

   2. Re-run automation for a smaller set of targets or simplified profile to isolate the failing step.

Validation / Confirmation

• New provisioning bot completes within normal time window and shows “Certificate Deployed”.

• Target system reflects the correct certificate and configuration.