SSL Certificate Renewed? Verify What Your API Actually Serves

Published September 2026 by SiteInformant Team

A certificate renewal job has finished successfully. Before closing the task, check a different question: what certificate does the public API hostname actually serve?

Issuance, deployment, and monitoring are separate steps. A new certificate can exist while a proxy still presents the previous one. A service can also have a valid certificate while returning an unexpected HTTP response. Treat renewal as complete only after verifying the public connection and leaving a working warning route for the next expiration.

This checklist is for public HTTPS endpoints. It does not assume a private-network probe, automatic certificate installation, or a monitor-management API.

Start With The Hostname Clients Use

Write down the exact hostname and route that clients call. A check of your marketing website says little about a separate API hostname.

Record four items in the renewal ticket:

• The public HTTPS hostname and the route being monitored.
• The person or team responsible for renewal and deployment.
• The component that terminates TLS, such as a reverse proxy or load balancer.
• The expected issuer and new certificate expiration date.

If there are several public hostnames, verify each one. Do not assume a successful check of one hostname proves that every listener has the replacement certificate. Keep private keys and credentials out of tickets and screenshots.

Verify The Served Certificate, Not Just A Local File

Connect to the public hostname after the certificate deployment. Inspect the certificate presented to the client, including its expiration and issuer, and confirm that it covers the intended hostname. Use a TLS client that validates the hostname and trust chain; disabling validation can hide the problem you are trying to find.

For teams already using OpenSSL, its s_client documentation describes the server-name and hostname-verification options. Treat these as diagnostic tools, not as a replacement for recurring monitoring.

If the served certificate still has the old expiration, investigate the serving configuration. Was the replacement deployed to the component that actually handles TLS? Did that component reload its configuration? Are all relevant listeners using the intended certificate?

Those are deployment questions. Reissuing another certificate without checking the serving path may leave the original problem in place.

Check HTTP Behavior Separately

A TLS handshake and an application response are different observations. Once the certificate is correct, request the intended HTTPS route and confirm its HTTP status.

For an authenticated route, an authorization error may indicate missing credentials rather than downtime. Use the response expected for that specific route. A health route returning success is useful, but it does not prove that every application workflow works.

SiteInformant records HTTP status, certificate expiration, certificate issuer details, and the negotiated TLS protocol. Public HTTP and HTTPS endpoints are checked every minute. These observations help separate a certificate change from a change in endpoint behavior; they are not a guarantee that every client or backend is healthy.

Leave Enough Time To Act On The Next Expiration

Choose a warning interval that fits your actual renewal process. Consider who owns the certificate, how deployments are approved, and whether the responsible person might be unavailable when the warning arrives.

SiteInformant's SSL warning window configures how many days before expiration warnings begin and which destinations receive them. That is separate from ordered downtime notification steps. Do not assume an unresolved SSL warning follows a downtime escalation sequence.

Monitoring reports a condition. It does not renew or deploy your certificate. The renewal runbook still needs an owner and a concrete next action.

For the product overview, see SSL monitoring for APIs.

Test The Delivery Path

A configured address is not the same as a verified delivery route. Make the notification check part of the renewal handoff:

1. Confirm that the selected destination belongs to the team responsible for the endpoint.
2. Complete email recipient confirmation before relying on email delivery.
3. Send a destination test and have the recipient confirm receipt.
4. Inspect notification delivery history if the expected message does not arrive.
5. Record a fallback contact in the team's own runbook.

SiteInformant provides reusable notification destinations and a test for each configured destination. New email recipients must accept a confirmation before operational alerts are sent to them. The Notifications History tab shows the latest 50 delivery attempts, including destination, endpoint, event, time, and delivery status.

A successful destination test checks delivery to that destination. It does not prove every warning threshold and endpoint assignment is correct. Review those settings separately.

A Renewal Handoff Checklist

Before closing the renewal task:

• Verify the public hostname serves the intended replacement certificate.
• Confirm the expected expiration, issuer, hostname coverage, and trust validation.
• Check the monitored route's expected HTTP status.
• Record who owns the next renewal and where the deployment procedure lives.
• Review the SSL warning window and destination selection.
• Confirm email recipients and test the destination.
• Record any exceptions, including hostnames still awaiting deployment.

Use the same checklist after moving a service behind a new proxy or changing its public hostname. The goal is evidence that the endpoint clients reach is correctly configured, not merely a successful renewal log.

Start With One Public Endpoint

Choose one important public HTTPS endpoint and walk through its certificate and notification settings. That is a manageable first step before expanding the inventory.

Explore SiteInformant's SSL monitoring overview and API uptime monitoring.

Your first endpoint is free. Card verification is required to prevent abuse. You will not be charged for the free endpoint.

Try SiteInformant: Try It Free