Nine hours off: the certificate error was the clock

The Entra Connect installation stopped at the same point every time, with a message that left little room for interpretation.

Microsoft Entra Connect could not configure application based
authentication for this server. Setup cannot continue.

In the event log, the line underneath was even more explicit.

AADSTS700027: The certificate with identifier used to sign the client
assertion is expired on application.
[Found key 'Start=08/20/2026 22:28:10, End=11/18/2026 22:28:10']

An expired certificate. Except the end date was three months away, in the future. A certificate that expires in ninety days is not expired.

Two clocks on the same line

The answer was in the same event, a few lines further down. There were two timestamps, and they did not agree.

MSAL  (VM clock)              : 2026-08-20 22:28:41Z
Entra (Microsoft's clock)     : 2026-08-20 13:28:43Z

The seconds nearly matched. The hours did not: exactly nine apart. The machine was generating certificates and signed assertions with dates that, measured against real time, were not yet valid — or already past, depending on which way you looked at them. Entra rejected them, using the only message it had: invalid certificate.

Nine was not an arbitrary number. It is the difference between Italian time and Pacific time.

The real cause

For guests with ostype Windows, Proxmox presents a virtual clock expressed in the host’s local time, not in UTC. The host read 15:17 Italian time and handed the VMs exactly that value.

The VMs were configured for Pacific Standard Time. They read “15:17” and concluded, correctly given what they knew, that UTC was nine hours ahead. Every signed operation from that point carried a date nine hours wrong.

The detail that made this treacherous: the fault came back at every reboot. Windows reads the virtual clock at boot. Any manual correction to the time lasted until the next shutdown, which made the problem look intermittent when it was in fact perfectly deterministic.

The fix is to align the guests’ time zone with the host’s.

Set-TimeZone -Id "W. Europe Standard Time"

What broke while fixing it

Correcting the time broke other things, and it is worth knowing before you find yourself in the middle of it.

Kerberos

Kerberos tolerates at most five minutes of difference between machines. At nine hours, remote PowerShell, WinRM and the Exchange Management Shell simply stopped working — precisely the tools being used to do the work.

Recovery meant discarding the accumulated tickets on each machine:

klist purge

and in some cases a reboot, because service tickets do not all live in the interactive session.

The DAG

The database availability group reacted immediately: copies in DisconnectedAndResynchronizing, Active Manager in an inconsistent state, and a message that blamed Active Directory for something that was not its fault.

Could not find server 'LAB-MBX02' in Active Directory

The server was there. It all resolved by aligning the time, rebooting the node, and restarting the MSExchangeRepl service on both nodes — not just the one complaining.

The three lessons

An error that talks about certificates can be a clock. Authentication, signatures, tokens, certificates: everything with a validity window breaks the same way when the time is wrong, and none of those components says “check the clock”. They say “invalid”, which is true and useless.

The fastest check is inside the same event. When a remote service rejects something signed, look for its timestamp in the message and compare it with yours. If the log puts them side by side, the diagnosis takes three seconds. That is far quicker than any theory about certificates.

A fault that returns at every reboot is not intermittent. It is deterministic, and the thing determining it happens at boot. That narrows the field considerably: the clock, services, start order, whatever the machine reads from its hypervisor.

Lab built with the support of Ilie.