SAML certificates: expiry checks

Every depot on single sign-on depends on two certificates: the customer's identity provider signs each sign-in with theirs, and each depot has its own service provider certificate on our side (DepotSamlConfig). If either expires, nobody at that depot can sign in with single sign-on. Kelderby's 25 depots will mean 25 of each.

The daily check

CheckSamlCertificates runs at 06:00 in every region and looks at both certificates of every depot whose switch is on, or is set up and waiting.

Days left	What happens
60	in-app notice and email to the client's administrators
30	again, and a SUP ticket for support to follow up
7	again, and the on-call engineer is told in #ops
0	the depot's single sign-on fails: see the SAML runbook

The customer's certificate

Entra ID certificates usually last three years. When the customer renews one in Entra ID, the depot needs the new metadata.

Since 18 August the customer's administrator uploads the new metadata file in the portal (Single sign-on › the depot › Upload metadata). The portal checks the file, shows the new certificate's dates, and keeps the old one until the new one has signed a sign-in. Before that, support pasted the metadata from a SUP ticket, which took a day or two.

Our certificates

We rotate our side every two years, 30 days before expiry, with an overlap: the depot publishes both certificates for 30 days and the customer's IT updates their app in that time. Marek or the on-call engineer runs php artisan saml:rotate-sp {client} {depot}; support tells the customer the same day.

Change history

Version	Date	Who	What
3	17 Mar 2025	Marek	Checks per region
4	22 Jun 2026	Marek	Okta depots included
5	19 Aug 2026	Marek	Metadata upload by customers