Application link communication errors due to invalid system time

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Problem

There are OAuth errors and invalid timestamp warnings in the log, although the application links seem to be working correctly. In some cases, the JIRA issues macro will not display JIRA issues and the following will appear in the UI:

The following errors appear in the atlassian-confluence.log

2014-06-30 08:41:40,399 WARN [ajp-bio-8009-exec-6303] [serviceprovider.internal.servlet.RequestTokenServlet] logOAuthProblem Rejecting OAuth request for url
"https://<your_server_URL>/plugins/servlet/oauth/request-token" due to invalid timestamp ({oauth_problem=timestamp_refused,
oauth_acceptable_timestamps=1433162200399-1433162800399}). This is most likely due to our system clock not being synchronized with the consumer's clock.
2014-06-30 08:26:25,197 WARN [ajp-bio-8009-exec-6330] [auth.trustedapps.filter.TrustedApplicationFilterAuthenticator] authenticate Failed to login trusted
application: jira:2660899 due to: com.atlassian.security.auth.trustedapps.CertificateTooOldException: Certificate too old. Application: jira:2660899 Certificate
Created: Mon Jun 30 08:05:44 EDT 2014 Timeout: 10000

Cause

Servers do not have the correct system time, or are not updating with a network time server regularly. This can also happen after a server restart, if it has not synced to NTP yet. Validations between different servers (e.g. Confluence and JIRA) are also based on timestamps, and if the discrepancy is too big then they will not talk to each other.

Workaround

  • Run the following commands on Linux:

    $ sudo apt-get install ntp (use 'yum install ntp' for CentOS or Redhat)
    $ sudo service ntp stop
    $ sudo ntpdate -s time.nist.gov (we can use any other server from here.
    $ sudo service ntp start

 

  • Run the following command on MacOS X:
    $ sudo ntpdate -u time.apple.com

     

  • Do the following on Windows:
    - Click on your date/time in the bottom right -> Change date and time settings... -> Update now
    - The default server is set to time.windows.com

Resolution

For a more permanent fix, we want to make sure that our server is set up to sync with a network time server regularly. Here are a few different ways to do this in multiple Operating Systems.

Linux:
$ sudo service ntp stop

  • Edit your /etc/ntp.conf file to contain the servers you'd like to sync with (examples can be found here.
  • This is usually already configured. Sometimes when a server is restarted the system time might not sync. If that is the case then a manual one-time sync should resolve this.

$ sudo service ntp start
$ sudo ntpq -p

  • This will show you the delay, offset, and jitter for your ntp servers listed in the configuration file.


MacOS X:
$ sudo systemsetup -getnetworktimeserver
$ sudo ntpdate -u <time_server you want to use>


Windows:
Click on your date/time in the bottom right -> Change date and time settings...

  • Ensure 'Synchronize with Internet time server' is checked
  • Ensure you have a valid server selected 
  • Test your sync by clicking update now

Last modified on Mar 30, 2016

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.