An integration runs for months and then stops one morning. The code did not change, the data did not change, the configuration is the same. The only thing that changed is the calendar.
With the first integration this is not a problem. A certificate gets installed, the call works, nobody writes the date down — a single date stays in your head on its own.
By year three the picture is different. Fifteen inbound service definitions, different counterparties, different renewal cycles. What has to be remembered is no longer a date but a calendar, and when that calendar has no owner, the first warning comes from a user.
Where the certificate setting sits in a service definition
The definition of a call to an external service is more than a URL. Method, content type, headers, parameters, body template and the authentication setting live in the same record, and authentication can be Basic, a Bearer token or an API key header. Timeout, redirect following and certificate verification settings are part of that definition too.
The difficulty here is administrative rather than technical: who watches the expiry date? The product does not renew an expiring certificate on its own. Renewal runs through your certificate management process and usually needs both parties to coordinate.
The option that switches off certificate verification
One point deserves saying out loud. The configuration includes options that can switch certificate verification off. Turned off during go-live to get past an error quickly, that setting tends to stay off in production without waiting to be turned back on.
The consequence is larger than it looks: with verification off, the call still travels over an encrypted channel, but nothing checks that the other side is who you expect. Which is why the go-live checklist deserves one line — in which service definitions is verification on?
Telling a connection error from an identity error
During an incident, the biggest time sink is looking in the wrong place. Certificate failures do not look like authorization failures; they are recorded as connection-level failures. An authentication error points you at users and tokens, a connection error at certificates and the network.
The records support that split: outbound services hold request and response entries, durations and error details, while inbound definitions can be tested before a call goes live. Do not test a renewal by waiting for the production flow to run.
The maintenance routine that works is plain:
- Write the certificate expiry date down per integration; that place can be a calendar invitation.
- Set a reminder at least a month ahead, because renewal needs both parties to coordinate.
- Test the call by hand after the renewal.
- Note in advance which record to check when it fails.
None of this is a security claim. HTTPS and certificate management do not prove a platform is secure; they keep the call on an encrypted channel and verify the other side. The gain is operational: a maintenance task with a known calendar beats an outage diagnosed at eight in the morning.
The shortest thing you can do today is list your inbound service definitions and add two columns — certificate expiry date, and whether verification is on. Filling that table in together is an hour-long session in most organizations.