Reference · built on requestOperator by FibricIT & reliability

Certificate Expiry

Watches every certificate you serve, from Cloudflare packs to ACM and origin hosts, and proposes the renewal before it lapses.

Request accessPricing ↗

About

An expired certificate is the outage everyone saw coming. Certificate Expiry reads the certificate packs on each Cloudflare zone with their status and expires_on date, the DaysToExpiry metric that AWS Certificate Manager publishes to Amazon CloudWatch for every certificate, and the tls.cert_expiration check that Datadog runs against the hosts you name. It knows which certificates renew themselves, which ones a person must replace, and which ACME renewals have stopped succeeding.

For each certificate inside the window you set, it proposes the renewal that fits: a restart of validation on a Cloudflare pack, a Jira issue for a custom or imported certificate that someone must upload, or a page when a renewal has already failed. You approve each one. It never uploads a key or touches a listener.

This is a reference listing. It documents what Fibric would read from Certificate Expiry and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Certificate packs per Cloudflare zone through GET /zones/{zone_id}/ssl/certificate_packs, with status, hosts, certificate_authority, validity_days, and expires_on
  • The DaysToExpiry metric in the AWS/CertificateManager namespace, published twice a day per certificate until it expires
  • CertificateIssuanceSuccess and CertificateIssuanceFailed counts for ACM ACME endpoints, so a stalled client is seen before the deadline
  • tls.cert_expiration and tls.cert_validation service checks from the Datadog TLS integration on the origin hosts you list
  • Universal SSL state on each zone, which Cloudflare issues and renews, against custom certificates, which it does not
  • Renewal tickets in Jira, so a certificate already assigned to someone is not proposed twice

Proposed actions

  • Target capability: propose restarting validation on a certificate pack through PATCH /zones/{zone_id}/ssl/certificate_packs/{certificate_pack_id}
  • Target capability: propose a Jira issue for each custom or imported certificate a person must renew and upload, with the host list and expiry date
  • Target capability: propose a PagerDuty alert event when an ACME issuance has failed or a certificate is inside the final days you set
  • Target capability: propose a comment on the open Jira issue when the new certificate is observed serving and the old one can be retired

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Restart a stuck Cloudflare validation

    A certificate pack sits in pending_validation with expires_on inside your window. The operator proposes restarting validation on that pack and posts the hosts it covers for the zone owner to approve.

    With Cloudflare

  • Ticket the imported certificate nobody owns

    DaysToExpiry for an imported ACM certificate crosses the threshold. Because ACM will not renew it, Certificate Expiry proposes a Jira issue naming the ARN, the domains, and the date.

    With Amazon CloudWatch, Jira

  • Page when the ACME client stops working

    CertificateIssuanceFailed climbs on an ACME endpoint and Datadog's tls.cert_expiration turns to WARNING on the same host. The operator proposes a PagerDuty alert to the on-call before the certificate lapses.

    With Amazon CloudWatch, Datadog, PagerDuty

Requirements

  • A Cloudflare API token with Zone Read and SSL and Certificates Read on each zone, plus Edit if validation restarts are to be applied
  • Amazon CloudWatch read access to the AWS/CertificateManager namespace in each Region where certificates are issued
  • The Datadog TLS integration configured on an Agent that can reach each origin host, with days_warning and days_critical set
  • A Jira project for renewal work and a PagerDuty service with an Events API v2 integration key
Authentication
The operator authenticates nowhere itself. Cloudflare, CloudWatch, Datadog, Jira, and PagerDuty are read and written through their own connectors, with the scopes you granted each one.

Limits

  • ACM renews only certificates it issued that are in use or exported. Imported certificates and ACME-issued ones are never renewed by ACM.
  • DaysToExpiry stops the day a certificate expires. A certificate that has already lapsed is seen through the Datadog check, not through ACM.
  • Datadog's TLS check reads the leaf certificate only. Intermediate and root expiry is not covered.
  • It proposes tickets, alerts, and pack validation. It does not generate keys, upload certificates, or change what a listener serves.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Certificate Expiry ↗

Questions and answers

What is a person asked to approve?
One proposal per certificate inside the window: a validation restart on a Cloudflare pack, a Jira issue for a manual renewal, or a page for a failed renewal. Each shows the hosts, the issuer, the expiry date, and why that action was chosen.
What does it keep for the audit?
A receipt for every certificate it tracked: the expiry it read, the source it read it from, the proposal, who approved it and when, and the observation that the new certificate was serving. Reports can be pulled by zone or by Region.
Will it ever renew or upload a certificate itself?
No. It reads expiry from Cloudflare, CloudWatch, and Datadog and writes only through approved proposals to Cloudflare validation, Jira, and PagerDuty. Private keys never pass through it and it holds no CA account credentials.
Ask about Certificate Expiry

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy