In the end of the SAML authentication process, the user gets one of the following error messages: 

SAML version 6.x.x

"message" : "Could not validate timestamp: not yet valid. Check system clock."

"message" : "Reading SAMLResponse failed: 19: Could not validate timestamp: not yet valid. Check system clock."

SAML version < 6.x.x

"SAML-message with NotBefore XXX is not valid yet"

"SAML-message with NotOnOrAfter XXX is no longer valid"


This issue occurs if there is a difference between the clock on the Identity Provider and the Atlassian Data Center or Server application (Jira/Confluence/Bitbucket/Bamboo). Mostly this issues happen after application updates or migration processes, by which the clock times of your systems get mixed up.

To fix this issue quickly: Disable the Enforce response validity dates function (Service Provider section -> under Security).

Turning this function off permanently is not recommended, because it will disable one of the security mechanisms that built in to avoid replay attacks. While this may only be a very small risk, you should re-enable it as early as possible as a best practice. Use it as a valuable workaround while you troubleshoot your environment.

Sync timing in the Atlassian Data Center  / Server app and the Identity Provider to solve the main issue

Try to adjust the Atlassian Data Center or Server application and Identity Provider time clocks, so they get synchronized. To edit the system time for Atlassian applications, the java timezone needs to be adjusted: Setting-the-timezone-for-the-java-environment. For changing the time of the Identity Provider, please check the Identity Provider's documentations.

If changing the system times didn't solve the issue, try to increase the Time Skew (Seconds) field (Service Provider section → under Security) higher than 60 seconds (recommended values: 120 up to 180 seconds). To find an appropriate value, please get in contact with our support and attach an authentication tracker of the failed authentication.