Use Case

TLS certificate expiry and lifecycle tracking
treat every certificate as a finding with an SLA

Expired and misconfigured TLS certificates take production down, break customer authentication, and surface as audit findings against ISO 27001, SOC 2, and PCI DSS cryptographic controls. Run certificate lifecycle as a vulnerability discipline on the engagement record so the cert inventory, the upcoming-expiry queue, the renewal trail, and the chain-health evidence live in one place rather than in a script, a spreadsheet, and three calendars nobody owns.

Get Started Free

No credit card required. Free plan available forever.

Take certificate expiry off the shared inbox and onto the engagement record

Expired TLS certificates take production down. They break customer authentication, they block partner integrations, they trigger every browser warning the user education programme spent two years suppressing, and they surface as audit findings against every cryptographic control the security programme is graded on. Internal security teams, AppSec teams, security engineering teams, cloud security teams, and GRC teams pay the cost together when certificate lifecycle lives in a shared inbox, a renewal script nobody else can read, or a quarterly nmap report the AppSec lead runs when there is time. The first sign a certificate expired is the customer error page. The incident review identifies the missed renewal. The audit lookback finds no operating evidence of certificate lifecycle management on a controlled record. The same failure happens the next quarter on a different hostname because the underlying discipline never landed.

This is the operational layer that turns every TLS certificate into a finding with an SLA. For the broader external assessment programme this workflow runs inside, read the external security assessment workflow. For the cloud-account-bound certificate slice, read the cloud security assessment workflow. For the SLA discipline the certificate findings inherit, read the vulnerability SLA management workflow. For the structured exception flow that handles internal CA and short-lived workload certificates, read the vulnerability acceptance and exception management workflow. For background reading on related TLS issues that surface alongside expiry, the TLS/SSL misconfiguration page and the weak cryptography page cover the underlying findings the lifecycle queue manages alongside expiry.

Six certificate sources and how the workflow reconciles them on one record

Certificates arrive from six places in a real estate. Each source has a healthy lifecycle (the certificate lives on an engagement record with the issuance source, the renewal cadence, the named owner, and the post-renewal scan evidence) and a default failure (the certificate lives only inside the system that issues it, ages there, and expires without surfacing on a controlled record). The split below is the starting point for an operational model AppSec, security engineering, and cloud security can run against together.

Source	Healthy lifecycle	Default failure
Public CAs issuing through ACME automation (Let's Encrypt, ZeroSSL, Buypass)	ACME-issued certificates renew on a documented automation cadence (typically thirty to sixty days). The engagement record holds the automation source, the renewal cadence per asset, the script or controller that runs the renewal, the last successful issuance timestamp, and the post-renewal scan that confirms the live chain. Continuous external scans verify the renewed certificate landed on production rather than only inside the issuance log.	The renewal script lives on a single host that nobody on the security team has access to. When the script breaks (rate-limit hit, domain validation drift, expired ACME account key), nothing surfaces until customers report TLS errors. The certificate is renewed in theory, expired in production, and the only person who knows the script lives there has left the company.
Public CAs issuing through commercial renewal (DigiCert, Sectigo, GlobalSign, Entrust)	Each commercial certificate carries an explicit owner, a documented renewal window, a procurement ticket reference, and a designated approver on the engagement record. The renewal calendar lives on the platform finding queue with a stepped SLA (ninety, sixty, thirty, seven days) rather than in a finance system the security team cannot see. The post-renewal external scan attaches as evidence on the finding.	Commercial certificates renew off a shared inbox where the renewal reminders compete with vendor newsletters. The cert expires because nobody recognised the procurement ticket as a security obligation. The customer-facing edge goes down, the incident review identifies the missed renewal, and the audit lookback finds no operating evidence of certificate lifecycle management.
Cloud-provider managed certificates (AWS ACM, GCP managed certs, Azure App Service)	Each cloud-managed certificate is registered against the cloud account engagement. The renewal automation is documented, the account-level alerting for renewal failure is captured, and the verified-domain external scan confirms the negotiated chain matches the cloud provider issuance. When the cloud provider rotates the certificate, the change lands as a state event on the engagement with the previous and new fingerprint.	Cloud-managed certificates are assumed to renew automatically forever. The DNS validation drifts during a domain provider migration, the cloud provider quietly stops renewing, and the next certificate cycle silently fails. The cloud-team console shows the renewal failure; the security team never sees it because the alert lives inside the cloud console, not on a tracked finding record.
Internal CA issuing for mutual-TLS, service mesh, and workload identity	Internal CA certificates ride on a separate engagement that records the issuance authority, the rotation cadence (often hours or days for workload identity, months for service-to-service mTLS), the renewal automation, and the recovery path when an internal CA loses trust on a downstream service. The mTLS chain is excluded from the public expiry SLA but tracked on its own cadence so internal trust drift surfaces before workloads start failing authentication.	The internal CA renewal cadence is documented in a wiki page three teams ago, nobody owns the root certificate rotation, and the first sign of trouble is when a service mesh sidecar refuses connections. The security team cannot trace which workloads trust which root because the trust map only exists in head memory.
Customer-pinned certificates and partner mutual-TLS connections	Each customer or partner mTLS connection sits on the engagement with the counterparty, the pinned fingerprint or thumbprint, the agreed rotation cadence, the renewal contact, and the contractual SLA on advance notice before rotation. Renewals coordinate against the partner schedule through a documented handover so the cutover does not surprise either side.	A pinned certificate rotates without telling the partner. The partner integration breaks at the next API call. The incident-response thread reveals neither side had a record of the pin or the renewal SLA. The recovery is hours of forwarded emails to identify who at the partner can re-pin the new fingerprint, and the audit later asks for the change-control evidence that does not exist.
Subdomain and SAN proliferation across acquired estates, demo environments, and tenants	Subdomain enumeration on every continuous scan cycle surfaces new hostnames as they appear so the certificate inventory tracks the actual estate rather than the planned one. Each newly observed hostname routes to the engagement as a candidate for registration with a documented decision (in scope, internal only, retired demo, marketing redirect). Multi-tenant subdomains served by a wildcard certificate inherit the wildcard renewal record rather than appearing as orphaned issues.	A demo subdomain stood up two years ago for a customer meeting still serves a long-expired certificate. A marketing redirect points at a hostname whose cert lapsed last quarter. An acquired business unit brought a dozen unmanaged hostnames that nobody has inventoried. The first time the security team learns about any of them is when a researcher submits the expired cert through the disclosure programme.

Six failure modes that quietly break a certificate lifecycle programme

Certificate programmes rarely fail at the moment they go wrong. They fail at the next renewal cycle, the next outage call, the next acquisition-driven domain integration, or the next audit lookback where the cryptography control narrative does not reconcile to any operating record. The failure modes below are the patterns the workflow is designed to remove.

The certificate inventory lives in a script nobody else can read

A single SRE built a renewal script three years ago. The script works until it does not. There is no engagement record, no finding queue, and no audit-readable trail. When the script breaks, certificates expire silently and the security team finds out from customer support tickets rather than from the platform.

Renewal reminders compete with vendor newsletters in a shared inbox

Commercial CAs send renewal notices ninety, sixty, and thirty days before expiry. Those emails land in a procurement or shared finance inbox where they compete with quotation requests, newsletters, and survey invitations. The renewal becomes a missed email rather than a tracked finding with named owner, SLA, and notification cadence.

Expiry surfaces as an outage, not as a finding

The first signal a certificate expired is the customer error page. The incident review correctly identifies the missed renewal. The audit lookback notes that no operating evidence of certificate lifecycle management exists on a controlled record. The same failure happens the next quarter on a different hostname because the underlying lifecycle discipline never landed.

Chain trust, weak crypto, and protocol posture stay in separate worlds

The certificate expiry calendar lives in one place, the cipher posture lives in a quarterly nmap report nobody owns, and the chain trust review is something the AppSec lead does when there is time. The full TLS posture never reconciles to one finding queue. The audit answer requires assembling three different stories from three different places.

Rotation happens without change evidence on the record

A certificate rotates because the issuer migrated, the wildcard scope expanded for a new subdomain, or an emergency reissue followed a suspected key compromise. The new certificate lands in production. Nothing records the previous fingerprint, the rationale, the approver, or the post-rotation verification. When the auditor asks why the chain changed, the answer is reconstructed from chat threads rather than from a controlled record.

Internal CA trust drift breaks workloads before it surfaces in inventory

Service mesh sidecars, workload identity certificates, and internal mTLS chains rotate on an internal CA cadence the security team does not own. The first sign of drift is a workload that suddenly fails authentication after a sidecar update. The trust map only exists in head memory; the inventory only catches public-facing hostnames; the internal certificate estate is unmanaged until it breaks.

Six fields every certificate lifecycle record has to carry

A defensible certificate record is six concrete fields on the engagement, not a row in a spreadsheet someone forgot to update. Anything missing from the list below is a known gap in the operational discipline rather than a detail that surfaces later as an outage or as an audit finding.

Hostname or asset identifier and verified-domain reference

The canonical hostname (apex, subdomain, wildcard pattern, SAN list), the bound asset (load balancer, CDN edge, application origin, API gateway, service ingress, internal hostname), and the verified-domain record that authorises the platform to run external scans against it. Without the domain verification reference, scan execution is not lawful and the chain of evidence breaks at the first audit lookup.

Issuance source, validation method, and renewal cadence

The certificate issuer (the public CA, the internal CA, the cloud provider managed certificate authority), the validation method (DNS, HTTP, email, internal trust), the renewal cadence the asset commits to, and the named procurement or automation source. The combination is what tells the next operator whether the renewal is automated, ticketed, or manual.

Days-until-expiry, certificate fingerprint, and chain reference

The platform-canonical days-until-expiry value, the certificate SHA-256 fingerprint at the last scan, the chain length, the intermediate certificate identities, and the issuer string. The fingerprint is the identity the audit trail tracks across rotations; the days-until-expiry value is the SLA-bearing field the queue orders on.

Named owner, SLA tier, and notification chain

The named asset owner, the SLA tier inherited from the engagement registration, the deputy owner who covers leave, and the notification chain (per-user inboxes, named approvers, escalation contacts). A certificate finding without a named owner is itself a defect rather than a routing convenience.

Chain health, protocol posture, and cipher offering

Beyond expiry, the record carries the TLS protocols negotiated, the cipher suite offered, the chain trust status, the missing-intermediate signal if any, the self-signed flag, the HSTS policy reference, and the CAA record on the apex domain. Recording these alongside expiry is what turns a calendar reminder into a cryptographic-evidence record the audit can read.

Override or exception state with expiry and approver

When a finding is a documented exemption (an internal CA cert outside the public renewal SLA, a pinned customer mTLS cert on a separate cadence, a short-lived workload certificate rotated every twenty-four hours), the structured override carries the cited reason, the named approver, the targeted hostname or pattern scope, the compensating control, and the documented expiry on the exemption itself. The next external scan inherits the decision so the finding does not re-create against the exempted hostname.

Certificate lifecycle checklist

At weekly triage and at the quarterly cryptography review, the AppSec lead, the cloud security lead, the platform owner, and the GRC lead walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.

Every certificate-bearing asset (public hostname, load balancer, CDN edge, API gateway, service ingress, internal hostname) is registered on an engagement with the issuance source, the renewal cadence, the named owner, and the SLA tier before any expiry alert reaches production.
Domain verification is in place for every public hostname so external scanning can run lawfully and the scan output carries verified-domain provenance the audit lookback reads against.
Continuous monitoring runs scheduled external scans against every verified hostname so the live chain is read every cycle rather than once a quarter from a manual nmap report.
The SSL/TLS scanner module produces certificate expiry findings on graduated bands (expired, less than seven days, less than thirty days, less than sixty days, less than ninety days) so the renewal queue is a finding queue rather than a calendar reminder.
The same engagement record carries chain trust, weak crypto, protocol posture, missing intermediate, HSTS mismatch, and CAA absence findings alongside expiry so the full TLS posture reconciles on one record.
Renewal closes the finding with the new certificate fingerprint, the new validity window, the issuance method, and the post-renewal scan evidence rather than relying on automation auto-close.
Internal CA, mTLS, and short-lived workload certificates ride on a separate engagement or structured exception with a documented cadence rather than fighting the public renewal SLA.
Issuer migrations, wildcard scope changes, emergency reissues after suspected key compromise, and CA changes land as state events on the engagement with previous and new fingerprint, rationale, and approver captured.
Multi-tenant and customer-facing certificate views surface through the branded client portal so tenant owners and partners read the same record the workspace operates against.
Subdomain enumeration runs on every continuous scan cycle so newly observed hostnames are registered or marked out of scope before they accumulate as untracked certificate exposure.
AI report generation derives the certificate posture narrative from the live engagement record so the leadership read reconciles to the finding queue rather than to a parallel spreadsheet.
The activity log export is the audit trail behind ISO 27001 Annex A 8.24, SOC 2 CC6.7, PCI DSS 4 and 12.3.3, NIST SP 800-52, and NIST CSF 2.0 PR.DS as cryptographic-control operating evidence.

How the certificate lifecycle workflow looks in SecPortal

The workflow runs on the same feature surfaces the rest of the security programme already uses: the engagement record, the findings record, external scanning with the SSL/TLS check module, continuous monitoring, domain verification, structured finding overrides, the activity log, notifications, the document library, and AI report generation. The discipline is binding the certificate estate to a single record so inventory, expiry, chain health, and change events are derivable from the same surface AppSec, security engineering, and cloud security already operate against.

Domain verification authorises the scan

Domain verification proves the workspace is authorised to scan each hostname through DNS TXT, file upload, or HTML meta tag. Without a verified domain record, external scanning does not run on the hostname and the certificate cannot enter the lifecycle as a tracked record.

External scanning reads the live chain

External scanning runs the SSL/TLS check module against each verified hostname, retrieves the live peer certificate, walks the chain, and emits graduated expiry findings against the engagement. The scan is the inventory refresh; the manual cert list drifts inside a quarter while the scan reads production every cycle.

Continuous monitoring keeps cadence

Continuous monitoring schedules recurring scans so the expiry queue is always read against current state. Renewed certificates surface on the next scheduled cycle so closure is verified rather than asserted, and chain health is tracked across cycles rather than at the occasional manual audit.

Structured override and exemption register

Finding overrides hold exemptions for internal CA-issued certificates, short-lived workload identities, and customer-pinned mTLS connections with cited reason, named approver, target hostname scope, and documented exemption expiry. The next scan inherits the decision rather than re-firing the same expiry finding every cycle.

Routing through team management

Team management assigns the named owner per hostname and the deputy who covers leave. Notifications from notifications and alerts fan out to per-user inboxes so the renewal does not live in a shared queue nobody polls.

Activity log as the audit trail

Every issuance, every renewal, every override, every state event, and every retest verification lands on the activity log with timestamp and user attribution. The CSV export is the trail behind ISO 27001 Annex A 8.24, SOC 2 CC6.7, PCI DSS Requirements 4 and 12.3.3, NIST SP 800-52, and NIST CSF 2.0 PR.DS evidence.

Five views the certificate programme actually drives

The reports that drive certificate governance are not the static slide at the quarterly review. They are the live views the AppSec lead, the cloud security lead, the platform owner, and security leadership read between reviews. The five below are the ones every meaningful certificate lifecycle programme settles on, and they all derive from the live engagement record rather than from a parallel spreadsheet someone keeps locally.

Upcoming-expiry queue by SLA tier

Certificates approaching expiry banded by SLA tier (less than ninety, sixty, thirty, seven days, already expired), grouped by owner. The view that distinguishes a working renewal programme from one that lives in a calendar reminder.

Renewal velocity and SLA breach posture

Time-from-detection to renewal close per band, in-flight renewals approaching SLA breach, and breach trend by owner team. The view that catches ageing certificate findings before the calendar runs out.

Exception register and approaching exemption expiries

Active exemptions for internal CA, mTLS, and short-lived workload certificates with cited reason, named approver, target hostname or pattern scope, and exemption expiry. The view that distinguishes time-bound exceptions from silent drift.

Chain health, protocol, and cipher posture

Missing intermediates, self-signed in production, deprecated TLS protocols still negotiable, weak ciphers in the offered suite, HSTS policy mismatches, and CAA gaps. The view that turns the cryptography control narrative into operational findings.

Certificate change-event trail

Issuer migrations, wildcard scope changes, emergency reissues, and CA transitions with previous and new fingerprint, rationale, and approver. The view that reconstructs why the chain changed when the audit lookback asks.

Framework coverage and audit-trail export

Mapped cryptographic-control coverage across ISO 27001 Annex A 8.24, SOC 2 CC6.7, PCI DSS Requirements 4 and 12.3.3, NIST SP 800-52, and CIS Controls v8.1 controls 3 and 12. The view the GRC team uses to assemble assessor evidence without rebuilding the mapping per audit cycle, plus the activity-log export that is the trail behind the coverage figures.

What auditors expect from a TLS certificate lifecycle programme

Certificate evidence surfaces in audit reads whenever an external assessor reviews the cryptographic-control narrative. The frameworks below all expect the programme to show that certificates are inventoried, renewed on a controlled cadence, calibrated against the deployed protocol and cipher posture, and exception-handled on the record when deviation is deliberate. A documented cryptography policy without operational evidence on a controlled record reads as a process gap rather than as a maturity claim.

Framework	What the audit expects
ISO 27001 Annex A 8.24 (use of cryptography)	Annex A 8.24 expects a documented operating policy for cryptography including key and certificate management, with evidence that certificates are inventoried, renewed on a controlled cadence, and protected against compromise. The TLS lifecycle workflow produces the operating evidence on the engagement record: the certificate inventory by asset, the renewal cadence per issuance source, the closure trail per renewal, the exception register for legitimate exemptions, and the activity log behind every state change.
SOC 2 CC6.7 (transmission of information)	CC6.7 expects controls that protect information during transmission, including encryption in transit with documented evidence that the encryption controls operate as designed. The lifecycle workflow produces evidence the SOC 2 examiner reads as operating cryptography: scheduled external scans against verified hostnames, finding queue covering expiry and chain health, named owners with SLA tiers, and post-renewal verification evidence on every closure.
PCI DSS Requirements 4 and 12.3.3	Requirement 4 expects strong cryptography on the transmission of cardholder data across public networks, with documented evidence that the deployed configurations are not vulnerable. Requirement 12.3.3 expects a cryptographic cipher suite and protocol inventory reviewed at least once every twelve months. The workflow produces the cipher posture and chain health on every continuous scan cycle so the PCI DSS evidence is derivable from the live record rather than from a one-off audit-week scan.
NIST SP 800-52 (TLS deployment guidance)	NIST SP 800-52 sets the federal baseline for TLS implementation including approved protocols, cipher suites, key sizes, certificate validity, and renewal practice. The lifecycle workflow surfaces deviations against the NIST baseline as findings on the engagement so the deviation either remediates with evidence on the record or rides on a structured exception with named approver, compensating controls, and a documented expiry rather than as an undocumented configuration choice.
NIST CSF 2.0 PR.DS (data security)	NIST CSF 2.0 protect-function category PR.DS expects data security including data-in-transit protections. The workflow contributes to PR.DS evidence by maintaining an asset-bound certificate inventory, a continuous scan cadence that re-evaluates protection on every cycle, a closure narrative for every expiry or chain issue, and an exception register where deliberate deviations live on a controlled record rather than as silent drift.
CIS Controls v8.1 control 3 (data protection) and control 12 (network infrastructure)	CIS Controls v8.1 control 3.10 and control 12 expect documented cryptographic protection on transit data and inventoried network infrastructure including TLS termination points. The lifecycle workflow produces the named-owner evidence and the change-event evidence on the engagement record so the CIS Controls maturity claim reads against operational evidence rather than a self-assessment.

Where certificate lifecycle tracking sits in the wider security programme

The workflow composes with the rest of the security programme on the same engagement record so the cryptography layer stays connected to the per-finding, per-control, and per-release work that runs alongside it.

Upstream and adjacent

Certificate lifecycle depends on external security assessment for the broader scanning programme, cloud security assessment for the cloud-managed certificate slice, asset criticality scoring for the SLA tier decision, asset ownership mapping for the named-owner trail, and the scanner coverage and limits guide for what the SSL/TLS check module sees and where the coverage stops.

Downstream and reporting

Certificate evidence rolls into remediation tracking for the per-finding closure narrative, vulnerability SLA management for the time-bound resolution discipline, vulnerability acceptance and exception management for the structured exception flow, control mapping cross-framework crosswalks for the cryptography-control evidence package, security leadership reporting for the cadence that reads certificate posture as a leading indicator, and audit evidence retention and disposal for the long-tail evidence chain.

Pair the workflow with the framework references and vulnerability guides

The certificate lifecycle workflow is operational; the surrounding pages explain the cryptographic-control framework expectations and the TLS-related vulnerability findings the workflow surfaces alongside expiry. Pair this workflow with the ISO 27001 framework page for the Annex A 8.24 cryptography control, SOC 2 for the CC6.7 transmission control, PCI DSS for Requirements 4 and 12.3.3, NIST CSF 2.0 for the PR.DS data-security category, and CIS Controls v8.1 for control 3.10 and control 12. The related vulnerability findings the lifecycle queue manages alongside expiry include TLS/SSL misconfiguration, weak cryptography, missing security headers (the HSTS posture sibling), and subdomain takeover (the orphaned-hostname sibling that often surfaces alongside expired certificates).

Buyer and operator pairing

The certificate lifecycle workflow is the workspace AppSec teams run for application-tier certificates, security engineering teams run as the platform-side owners, cloud security teams run for cloud-managed certificates per cloud account, vulnerability management teams run for SLA discipline and the leadership posture read, and GRC and compliance teams run for the cryptographic-control framework mapping. CISOs read certificate posture, renewal velocity, exemption register, and chain-health trend as leading indicators of whether the cryptography control narrative reconciles to the deployed estate.

What a healthy certificate lifecycle programme feels like

Inventory is observed, not asserted

Continuous external scans against verified hostnames read the live peer certificate every cycle. The inventory is whatever production presents on the wire rather than a spreadsheet someone forgot to update three quarters ago.

Expiry is a finding queue, not a calendar

The renewal queue lives on the same engagement record the rest of the vulnerability programme reads against, with severity, named owner, SLA tier, and breach escalation. Renewals close with post-renewal scan evidence rather than asserted.

Chain health is a peer of expiry

Missing intermediates, deprecated protocols, weak ciphers, HSTS mismatches, and self-signed certificates in production land on the same engagement queue as expiry so the cryptography control narrative reconciles to one record rather than to three.

Change events are recorded, not silent

Issuer migrations, wildcard scope changes, emergency reissues, and CA transitions land as state events on the record with previous and new fingerprint, rationale, and approver captured. The audit lookback reads the chain history rather than rebuilding it from chat threads.

Exceptions expire instead of accumulate

Internal CA exemptions, short-lived workload identity rotation, and customer-pinned mTLS exemptions ride on structured finding overrides with cited reason, named approver, target scope, and a documented exemption expiry on the exemption itself. The next scan inherits the decision rather than re-firing the same finding.

Evidence is derivative of the work

Certificate posture, renewal velocity, exception register, chain health trend, and framework coverage derive from the live engagement record. The activity log export is the trail and the AI report is the narrative. Nobody assembles cryptography evidence the week before the audit.

TLS certificate lifecycle tracking is the operational layer that turns every certificate into a finding with an SLA. Run the workflow on the engagement record so the inventory is observed rather than asserted, expiry rides on a finding queue rather than on a calendar, chain health is a peer of expiry rather than a separate quarterly review, change events are recorded on the chain history rather than disappearing into chat threads, and the leadership posture read derives from the live record rather than from a parallel spreadsheet. For the upstream scanning programme that produces the certificate findings, pair this page with the external security assessment workflow; for the structured exception flow the workflow depends on, pair it with the vulnerability acceptance and exception management workflow; and for the leadership cadence that reads certificate posture as a leading indicator, pair it with the security leadership reporting workflow.

Frequently asked questions about the certificate lifecycle workflow

What is TLS certificate expiry and lifecycle tracking?

TLS certificate expiry and lifecycle tracking is the operational discipline that runs every TLS or SSL certificate the organisation depends on through a single managed lifecycle: inventory, renewal cadence, expiry queue, chain health, rotation evidence, and audit-readable closure trail. The discipline treats each certificate as a finding with an SLA rather than as a calendar reminder. It covers public certificates on internet-facing hostnames, cloud-provider managed certificates, internal CA-issued certificates for mutual TLS and service mesh, customer-pinned partner certificates, and short-lived workload certificates rotated by an internal issuer.

Why treat certificate expiry as a vulnerability rather than a calendar reminder?

Calendar reminders fail in three predictable ways. They live in a shared inbox where they compete with vendor newsletters. They live in a script nobody else has access to. They live in a procurement system the security team cannot see. Treating expiry as a finding puts it on the same record the rest of the vulnerability programme reads against: severity, named owner, SLA tier, named approver, change history, and audit trail. The renewal becomes a tracked closure obligation rather than a forwarded email, and the audit lookback reads the certificate lifecycle as operating evidence rather than as policy text.

How does SecPortal know about my certificates?

SecPortal does not maintain an external feed of certificates. It runs continuous external scans against verified domains and reads the live peer certificate, the chain, the negotiated protocol, and the cipher suite on every scan cycle. The certificate inventory is whatever the scheduled scans observe in production on a verified hostname. To bring a hostname into the inventory, verify the domain through the platform domain verification workflow and schedule scans against it; to take a hostname out of the inventory, retire the verified-domain record. Internal hostnames the external scan cannot reach ride on a separate engagement with the inventory captured directly.

What certificate findings does the SSL/TLS scanner produce?

The SSL/TLS scanner module produces graduated expiry findings (already expired, less than seven days, less than thirty days, less than sixty days, less than ninety days), chain trust findings (missing intermediate, self-signed in production, untrusted issuer), protocol posture findings (deprecated SSL or TLS still negotiable), cipher posture findings (weak ciphers in the offered suite), HSTS findings (policy mismatch against the certificate validity), CAA findings (missing CAA on apex), and authentication findings (mismatched certificate-host pair). Each finding carries severity, the affected hostname, the certificate fingerprint, and the evidence the next operator reads against. The CVSS calibration on the engagement converts these into the SLA tier the renewal queue runs on.

How are short-lived workload certificates and internal mTLS handled?

Short-lived workload certificates (rotated every twenty-four hours or less by an internal issuer) and internal mutual-TLS certificates live on a separate engagement with their own rotation cadence and exemption from the public-facing expiry SLA. The structured finding override workflow carries the exemption with the cited reason (rotated by internal CA, ephemeral workload identity, service-mesh sidecar), the named approver, the target hostname or pattern scope, and the documented exemption expiry. The next external scan inherits the decision so the workflow does not re-fire the expiry finding against documented exemptions. The internal cadence still tracks on its own engagement so drift surfaces as a finding rather than as an outage.

How are CA migrations, wildcard scope changes, and emergency reissues recorded?

Every certificate change that is not a routine renewal lands on the engagement as a state event. The state event records the previous fingerprint, the new fingerprint, the rationale (issuer migration, wildcard scope expansion for a new subdomain, emergency reissue after suspected key compromise, transition from DV to OV, switch from public CA to internal CA, withdrawal from a deprecated CA), the named approver, the timestamp, and the post-change external scan that confirms the new chain landed on production. Treating changes as discrete events on the record rather than as silent rotations is what makes the year-later audit lookback readable.

How does this workflow compose with vulnerability SLA and exception management?

Certificate findings inherit the SLA tier from the engagement registration and route through the same SLA management workflow the rest of the vulnerability programme uses. A critical expired-certificate finding on a customer-facing edge inherits the critical SLA tier and the same breach escalation chain. Exceptions ride on the structured finding override workflow rather than as ad-hoc suppressions inside a scanner console. The lifecycle is a peer of the rest of the vulnerability programme rather than a separate calendar that nobody on the security team owns.

How does the branded client portal surface certificate evidence to tenants?

When the certificate estate covers tenant-owned domains, customer-facing edges, or partner-operated endpoints, the branded client portal mirrors the certificate finding view scoped to the tenant. The named tenant owner sees the upcoming-expiry queue for their hostnames, the renewal closures, and the chain-health trend without needing access to the workspace. Internal certificates and other tenants are not visible. The portal becomes the shared surface for renewal coordination rather than an out-of-band email thread.

How does AI report generation summarise certificate posture?

AI report generation derives the certificate narrative from the live engagement record: the certificate inventory by asset class, the upcoming-expiry queue by SLA tier, the renewal velocity by month, the active exception register and approaching exemption expiries, the chain-health trend, the protocol and cipher posture across the estate, and the CA distribution. The named approver edits the draft instead of writing from a blank page, and the headline figure reconciles to the underlying finding count because the report is generated from the same record the team operates against.

Who runs this workflow inside a typical enterprise security team?

AppSec teams and security engineering teams typically own the certificate lifecycle for public-facing application hostnames. Cloud security teams own the cloud-managed certificates per cloud account. Platform engineering owns the internal CA and the service mesh certificate chain. Vulnerability management teams own the SLA discipline and the leadership posture read. GRC teams own the cryptographic-evidence framework mapping. CISOs read the certificate posture as a leading indicator of whether the cryptographic-control narrative reconciles to the deployed estate. The workflow runs on a shared engagement record so these functions write the contract together instead of reconciling separate trackers.

How it works in SecPortal

A streamlined workflow from start to finish.

Register every certificate-bearing asset and the renewal cadence on the engagement

Open an engagement that covers the certificate estate: the verified domains, the public-facing hostnames, the load balancer and CDN edges, the API gateway endpoints, the mutual-TLS service ingress points, and any internal hostnames that issue trust to clients. Record the owner per asset, the certificate issuance source (public CA, internal CA, ACME automation, cloud-provider managed certificate), the renewal cadence the asset commits to, the validation method (DNS, HTTP, email), and the dependent stakeholders. Without an enumerated estate, certificate expiry is a discovery problem at outage time rather than a tracked workstream.

Verify the domain and run continuous external scans against each hostname

Verify each domain through the platform domain verification workflow so external scanning can run lawfully against the hostname. Schedule continuous external scans against every verified hostname so the SSL/TLS check module retrieves the live peer certificate, walks the chain, and surfaces protocol negotiation, cipher posture, certificate validity, and chain trust on every scan cycle. The scan is the inventory refresh the workflow runs against; manual cert lists drift inside a quarter while the scan reads the production state on every run.

Convert expiry-window detections into structured findings with SLA tiers

The external scanner emits certificate expiry findings on graduated bands (already expired, less than seven days, less than thirty days, less than sixty days, less than ninety days). Each detection lands on the engagement record as a finding with severity, the affected hostname, the issuer, the days-until-expiry value, the certificate fingerprint, and the named owner. The SLA tier the finding inherits from the engagement registration converts a calendar reminder into a tracked closure obligation that breaches if the renewal slips.

Track chain trust, weak crypto, and protocol posture alongside expiry

Certificate lifecycle is not only an expiry calendar. The same engagement carries the findings the SSL/TLS scanner module produces against the rest of the negotiation: a weak signature algorithm in the chain, a missing intermediate certificate, a self-signed certificate on a production hostname, a deprecated SSL or TLS protocol still negotiable, weak ciphers in the offered suite, an HSTS policy that does not match the certificate validity, and a missing CAA record on the apex domain. Treating these as siblings of the expiry finding keeps the workflow honest: the audit answer is the same record, not three different ones.

Route renewal owners and capture the renewal evidence on the record

Critical and high certificate findings route to the named asset owner through team-based assignment with role-based access. The branded client portal surfaces the same view to tenant teams when the certificate lives on a customer-facing edge they operate. Each renewal closes the finding with the new certificate fingerprint, the new validity window, the issuance method, and the post-renewal scan evidence attached. ACME-automated renewals close with the script output and the next scan cycle confirmation. Manual renewals close with the issuance ticket reference and the verified scan. Auto-close on rotation is not enough; the closure carries the issuance trail.

Capture exceptions, internal-CA scope, and short-lived-certificate exemptions

Some certificates legitimately sit outside the standard renewal window: internal CA-issued certificates for service mesh, short-lived workload certificates rotated every twenty-four hours by an internal issuer, mutual-TLS client certificates pinned to a specific software release. The structured finding override workflow holds these exemptions with cited reason, named approver, target hostname or pattern scope, and a documented expiry on the exemption itself. The next external scan inherits the exception so the cert finding does not re-create against the documented exception rather than aging silently as an unowned alert.

Read certificate-chain change events as discrete state events on the record

Certificates change in production for reasons beyond renewal: an issuer migration from one public CA to another, a wildcard scope adjustment, a new SAN appended for a fresh subdomain, an emergency reissue after a private-key compromise, a switch from DV to OV or EV. Each change event lands on the engagement as a state event with timestamp, the previous and new fingerprint, the rationale, the approver, and the post-change scan evidence. Treating the change as a state event rather than as a silent rotation is what keeps the audit trail readable a year later when the lookback asks why the chain changed.

Produce the cryptographic-evidence pack and the leadership read from the live record

AI report generation derives the certificate posture narrative from the live engagement: the certificate inventory by asset, the upcoming-expiry queue by SLA tier, the renewal velocity by month, the exception register and approaching exemption expiries, the chain-health trend, and the protocol and cipher posture across the estate. The activity log export is the trail behind the headline figure. The narrative covers what ISO 27001 Annex A 8.24, SOC 2 CC6.7, PCI DSS Requirements 4 and 12.3.3, NIST SP 800-52, and NIST CSF 2.0 PR.DS read as cryptographic-control operating evidence rather than as a policy document with no operational trail.

Features that power this workflow

Orchestrate every security engagement from start to finish

Vulnerability management software that tracks every finding

Vulnerability scanning tools that map your attack surface

Monitor continuously catch regressions early

Verify ownership before any scan runs

Finding overrides that survive every scan cycle

Every action recorded across the workspace

Notifications and alerts for the people who carry the work

Document management for every security engagement

AI-powered reports in seconds, not days

Collaborate across your entire team

Your brand. Your portal. Your clients love it.

Map your attack surface before attackers do

Compliance tracking without a full GRC platform

Track every certificate as a finding with an SLA, not as a calendar reminder

Run TLS certificate expiry, renewal, chain health, and protocol posture on one engagement record. Continuous external scans, structured findings, named owners, and audit-ready evidence. Start free.