topic Re: FPR-2110 Time Synch in Network Security

FPR-2110 Time Synch

davparker — Wed, 28 Jan 2026 23:52:05 GMT

On the FPR-2110 we may be experiencing an issue with time synchronization that might be preventing SAML auth.
In system support diagnostic-cli the clock appears to be several minutes off.
When I show time from a regular cli prompt, time shows correct.
Time is set to sync via NTTP from Management Center, which looks to be correct

> show time
UTC - Wed Jan 28 23:01:35 UTC 2026

> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.

PPFTD-01> en
Password:
PPFTD-01# show clock
22:54:31.228 UT

Health Monitor shows the following faults:
Platform Faults
Jan 28, 2026 4:49 PM
2 Major Events
Code - F0853; Occurrence - 1; Time - 2025-03-12T00.18.45.390; Description - FDM Keyring's certificate is invalid

We are attempting to enable SAML auth against Azure. It fails. Below is debug output from:
debug webvpn saml 255

Jan 28 22:21:22 [SAML] get_validity: Assertion validity: NotBefore:2026-01-28T22:24:19.244Z NotOnOrAfter:2026-01-28T23:29:19.244Z
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Processing time values:
raw NotBefore: 22:24:19 UTC Jan 28 2026
raw NotOnOrAfter: 23:29:19 UTC Jan 28 2026
clock skew: 0
timeout: 0
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Effective time values :
adjusted NotBefore: 22:24:19 UTC Jan 28 2026
adjusted NotOnOrAfter: 23:29:19 UTC Jan 28 2026
current time: 22:21:22 UTC Jan 28 2026
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Assertion not yet valid.
Current time: 22:21:22 UTC Jan 28 2026
adjusted NotBefore: 22:24:19 UTC Jan 28 2026
Jan 28 22:21:22 [SAML] consume_assertion: assertion is expired or not valid
[saml] webvpn_login_primary_username: SAML assertion validation failed
saml_get_ac_token_data: Passed SAML token is NULL

Basically, it appears that time drift is preventing SAML auth? I also can't figure out why time doesn't agree depending upon how I check it.

Re: FPR-2110 Time Synch

Mark Elsen — Thu, 29 Jan 2026 07:32:45 GMT

- @davparker Review these bug reports : https://bst.cloudapps.cisco.com/bugsearch?pf=prdNm&prdNam=Cisco%20Firepower%202110%20Security%20Appliance&kw=FDM%20Keyring%27s%20certificate%20is%20invalid%20F0853%20certificate%20is%20invalid&bt=custV&sb=anfr

Re: FPR-2110 Time Synch

Cristian Matei — Thu, 29 Jan 2026 11:51:29 GMT

Hi,

@davparker Can you ensure the timezone is UTC, as validity time seen in the assertion is in UTC:

https://www.cisco.com/c/en/us/support/docs/interfaces-modules/catalyst-6500-series-7600-series-asa-services-module/223564-troubleshoot-common-problems-with-saml.html#toc-hId-350712260

You perform changes via Platform Settings:

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/device-config/710/management-center-device-config-71/interfaces-settings-platform.html

Thanks,

Cristian.

Re: FPR-2110 Time Synch

davparker — Thu, 29 Jan 2026 17:59:29 GMT

When I ssh into FTD and issue "show time" it shows the correct current time in UTC format. The Platform settings do specify CST-6 for the FTD appliance. When I test auth to VPN it shows the validity period beginning several minutes into the future and not the 6 hour offset. When I 'connect fxos' and 'show clock' the time is UTC but the time is offset by what looks like the same several minutes behind as shown in the same debug webcpn saml 255 outut. Weird. I could try changing the Timezone. I'm not sure what impact that will have. We don't currently have any time based rules.

debug webvpn saml 255
Jan 28 22:21:22 [SAML] get_validity: Assertion validity: NotBefore:2026-01-28T22:24:19.244Z NotOnOrAfter:2026-01-28T23:29:19.244Z
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Processing time values:
raw NotBefore: 22:24:19 UTC Jan 28 2026
raw NotOnOrAfter: 23:29:19 UTC Jan 28 2026
clock skew: 0
timeout: 0
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Effective time values :
adjusted NotBefore: 22:24:19 UTC Jan 28 2026
adjusted NotOnOrAfter: 23:29:19 UTC Jan 28 2026
current time: 22:21:22 UTC Jan 28 2026
Jan 28 22:21:22 [SAML] saml_util_check_expiration: Assertion not yet valid.
Current time: 22:21:22 UTC Jan 28 2026
adjusted NotBefore: 22:24:19 UTC Jan 28 2026
Jan 28 22:21:22 [SAML] consume_assertion: assertion is expired or not valid
[saml] webvpn_login_primary_username: SAML assertion validation failed
saml_get_ac_token_data: Passed SAML token is NULL

Re: FPR-2110 Time Synch

davparker — Thu, 29 Jan 2026 18:04:33 GMT

We are actually close to replacing this firewall. Doing some MFA testing in the meantime. Trying to avoid upgrading unless necessary.

Re: FPR-2110 Time Synch

davparker — Thu, 29 Jan 2026 19:49:02 GMT

Hey Mark,

I did check out the bugs. This device is managed by FMC.

According to bug CSCvk26612

For FMC: The fault do not cause any impact.

Re: FPR-2110 Time Synch

davparker — Fri, 30 Jan 2026 14:53:28 GMT

So, I did try changing the Timezone to UTC. It didn't change anything. After extensive t-shooting with TAC it appears that the LINA side is experiencing a time drift. It is odd. Logging into FTD and inputting show clock shows correct time. Connect fxos and show clock displays correct time. Connecting to system support diagnostic-cli and show clock displays time that is behind. Time is set to sync from FMC which is on current time. No other firewalls are impacted. TAC couldn't figure out why the LINA side is out of sync. We may just put this on the back burner since we are close to migrating that firewall to new hardware.

Re: FPR-2110 Time Synch

Cristian Matei — Fri, 30 Jan 2026 20:29:10 GMT

Hi,

@davparker Thanks for reaching back, obviously a bug. Before closing, ask TAC to open a bug on this, ideally get RCA and possible WA's attached to the bug.

Thank you,

Cristian.

Re: FPR-2110 Time Synch

davparker — Wed, 18 Feb 2026 15:48:21 GMT

You know I tried but they just wanted me to do the workaround, rebooting and failing over. That did work for now. Azure MFA is working. We are working towards replacing the 2110s with 3105s so this hopefully will become a non-issue.