Renewing an Expired App Registration Certificate for GALsync and contactSync

Purpose

A certificate approaches expiry, the administrator renews it and updates it on the server and on the Entra ID application — and from that moment every policy run fails. This is a common and avoidable outage, because the natural renewal procedure is not the one these products need.

The mistake worth avoiding

Do not generate a certificate externally and paste it into the Entra application. That is how certificates are normally renewed, and it is not sufficient here. The product holds its own side of the certificate relationship, and a certificate it did not create is not one it can use.

The documented procedure is the reverse: generate the new certificate from within GALsync or contactSync, then upload it to the App Registration in Microsoft Entra ID.

If you have already renewed the certificate the other way and policies are now failing, that is the cause, and the fix is to redo it in the correct order rather than to look for a configuration fault.

Recognising an expired certificate

When an App Registration certificate has expired, the associated environment configuration and its policies are tagged with a red X in the console. The log carries a corresponding entry confirming expiry.

A red X on an environment configuration or policy is therefore worth treating as a credential or certificate problem first, before investigating the policy itself.

The renewal procedure

1. Generate the new certificate from within the product, following How to recreate an expired App registrations Certificate in the manual.
2. Upload it to the App Registration in Microsoft Entra ID.
3. Confirm the environment configuration validates — the red X should clear.
4. Run one policy manually and confirm it completes with real object counts, not merely that it starts.

Do this before the existing certificate expires wherever possible. The procedure is the same either way, but doing it under time pressure with synchronization already failing is avoidable.

Check the API permissions at the same time

Certificate renewal is a good moment to confirm the application is on the current permission model, because an application configured some time ago may still be using permissions that are being retired.

Applications still holding Exchange Web Services API permissions should be moved to Microsoft Graph. Microsoft is retiring EWS for Exchange Online, and both products have moved to Graph-based mailbox access. An environment that works today on EWS is on a path to failing.

The manuals document the migration — How to switch to Microsoft Graph to access mailboxes in Exchange Online — and it is worth doing as a planned change rather than as an outage response.

Certificate-based authentication is now the only option

For context on why this matters more than it used to:

• As of version 8.6, user-based authentication for Exchange Online has been removed. Only certificate-based authentication through a registered application is supported.
• As of 8.5.6, the option to create a new user-based credential account was removed from the environment configuration.
• Multi-factor authentication on any remaining user-based configuration will block the connection. Excluding that account from Conditional Access is a stopgap; moving to certificate-based authentication is the actual answer.

So for current versions the certificate is the credential. Its expiry is a full outage, not a warning, which makes tracking the expiry date worth doing deliberately.

Check the prerequisites while you are there

Connection problems after a certificate change are sometimes the certificate and sometimes the platform underneath it. The current requirements:

• Version 8.7: .NET Framework 4.8, Windows PowerShell 5.1, ExchangeOnlineManagement module 3.10.1 or later.
• Version 8.5 and 8.6: .NET Framework 4.8 or later, Windows PowerShell 5.1, ExchangeOnlineManagement module 3.6 or later.

Get-Module -ListAvailable ExchangeOnlineManagement | Select-Object Name, Version, ModuleBase
$PSVersionTable.PSVersion

Check the module in the context the service account runs as, not only your own — scheduled policies run as the service account, and a module installed without -Scope AllUsers is not visible to it.

When several changes are made at once

Where a certificate renewal, a version upgrade and a permissions migration are performed together, service usually returns — but which change fixed it is then unknown. If you have the option, make them one at a time and verify between each. If you do not, record what was changed, so that a recurrence can be investigated against a known starting point.

References

• contactSync 8.7 Manual p.240 — How to recreate an expired App registrations Certificate; the red X on environment configuration and policies; the log entry confirming expiry.
• contactSync 8.7 Manual p.208 — How to switch to Microsoft Graph to access mailboxes in Exchange Online.
• GALsync 8.7 Upgrade Instructions p.10 and contactSync 8.7 Upgrade Instructions p.4 — version prerequisites; removal of user-based authentication in 8.6.
• The current manuals and upgrade instructions are published by NETsec at netsec.de.