Monitor third-party certificates

Many organisations depend on certificates they do not issue or control. A CDN terminates TLS in front of your application. A WAF vendor manages the certificate on your public endpoint. Salesforce, payment gateways, and partner APIs all present certificates — and when any of them expire, your services or integrations are affected, even though the renewal is not your responsibility.

The goal is not to take over these certificates. In most cases that is not possible. The goal is to have the same visibility you have over your own managed certificates: know what exists, know when it is expiring, and have enough lead time to escalate to the right party before it becomes an incident.

Horizon supports this through monitored profiles — a dedicated profile type designed for certificates that Horizon observes but does not issue.

What counts as a third-party certificate

Any certificate presented by a system or service that your organisation depends on but does not control is worth monitoring. Common examples:

• CDN and WAF platforms that terminate TLS at the edge on your behalf
• SaaS products such as Salesforce, ServiceNow, or Workday, where your integration depends on their certificate being valid
• Partner APIs and B2B integrations, particularly those secured with mutual TLS
• Payment processors and financial gateways
• Hosted monitoring or observability tools your infrastructure talks to
• Legacy vendor systems with long renewal cycles and no automated notifications

The common pattern is that expiry of these certificates either causes your services to fail or triggers certificate errors in your clients — and the fix requires action from a party outside your organisation.

Monitored profiles

A monitored profile is a Horizon profile with no issuance capability. It holds certificates that have been imported or discovered, tracks their expiry and compliance grade, and fires notifications — but it does not connect to a CA and cannot enroll or renew certificates.

Certificates in monitored profiles do not count toward your licensed certificate holders. You can monitor an unlimited number of third-party certificates at no additional cost.

Create a profile per context

Rather than putting all third-party certificates into a single monitored profile, create one profile per vendor or category. This keeps inventories clean and lets you configure different notification lead times and recipients for each context.

Useful groupings:

• One profile per major vendor (CDN, Salesforce, payment provider)
• One profile for mutual TLS partner certificates, where each partner's certificate needs to be tracked independently
• One profile for legacy internal systems whose certificates are managed outside Horizon

Naming profiles consistently — for example monitor-cdn, monitor-salesforce, monitor-partner-mtls — makes them easy to find and report on.

Adding certificates to a monitored profile

Once a certificate has been discovered (via an automatic discovery or a manual import), the certificate can be assigned to a monitored profile using the following steps:

1. Navigate to the Registration Authority portal.
2. Go to Certificates > Search certificates.
3. Find the certificate imported, and open it.
4. Click on Action > Migrate and select the monitored profile.

Configure expiry notifications

Expiry notifications for monitored profiles work the same way as for managed profiles. Go to Notifications and create a notification for the certificate expiry event, pointed at the monitored profile.

The lead time you set should reflect how long it takes to get the vendor to act. For most third parties, waiting until 30 days is too late — the vendor may need time to process a ticket, schedule a maintenance window, and deploy the new certificate. A useful minimum:

• 90 days before expiry — first alert to the team responsible for the vendor relationship
• 60 days before expiry — escalation if no acknowledgement
• 30 days before expiry — urgent escalation, consider whether you need to trigger a contingency

Route notifications to the people who can act: the team that owns the vendor relationship, not just the PKI or security team. An expiry alert that lands only in an inbox with no authority to contact the vendor accomplishes nothing.

Apply grading policies

Attach a grading policy to each monitored profile. This gives you a compliance view over third-party certificates — not just expiry, but also weak key sizes, outdated algorithms, or missing SANs that may violate your security policy.

A certificate served by your CDN with a 1024-bit RSA key is your compliance problem even if you did not issue it. Grading surfaces these issues before an auditor does.

Use labels to record ownership and context

Labels in Horizon are key-value pairs that travel with the certificate. Use them on monitored certificates to record the information you will need when an expiry alert fires:

• The vendor or service name
• The internal team responsible for the vendor relationship
• The ticket or contract reference for the renewal process
• Any known lead time the vendor requires

This metadata is visible in the certificate detail view and appears in exported reports, so it survives staff turnover and is available to whoever picks up the alert.

Responding to an expiry alert

Because you cannot renew these certificates yourself, the response to an expiry alert is a coordination task, not a technical one. The goal is to ensure the vendor renews and deploys the new certificate before the current one expires.

When an alert fires:

1. Confirm the certificate is still the same one Horizon detected — use network discovery or fetch the exposed certificate directly to verify the vendor has not already renewed it silently.
2. If it has not been renewed, contact the vendor through the appropriate channel. Reference the expiry date and your required lead time for testing.
3. Track the ticket or request in Horizon using labels or the certificate's metadata fields.
4. After the vendor deploys the new certificate, run a discovery scan to confirm Horizon is now tracking the updated certificate and that the expiry date has extended as expected.

For critical integrations, document a contingency in advance — for example, whether you can temporarily route around a failing endpoint, or whether the integration has a fallback.