Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. NetBackup™ Security and Encryption Guide
  3. Section II. Encryption of data-in-transit
  4. NetBackup CA and NetBackup certificates
  5. About host ID-based certificates
  6. Implication of clock skew on certificate validity
NetBackup™ Security and Encryption Guide

Implication of clock skew on certificate validity

When a primary server issues a certificate, it determines for how long the certificate will be valid for the host to use. The primary server sets the validity of the certificate based on its own time, recording two timestamps: Not before and Not after. The certificate is valid only between these two timestamps.

The clock on the primary server and the clock on the host that will receive the certificate should be in sync so that the certificate is valid for as long as is expected, given the timestamps.

The hosts can reside in different time zones, as long as the clock on each host is set to the correct time for that host's timezone. As a general practice, it is recommended using a service such as Network Time Protocol (NTP) to automatically keep all clocks on all hosts in the NetBackup domain synchronized.

If the clocks are not in sync, the difference can result in the following consequences:

  • If the host clock is ahead of the primary server, the validity period of the certificate will be less than expected on that particular host. If the difference is extreme and the clocks vary by more than the certificate's validity period, it is possible that if the primary server issued a fresh certificate, it could be treated as expired.

  • If the host clock is behind the primary server, a fresh certificate issued by the primary server could be considered as unusable by the host because the host considers the certificate as not yet valid.

To determine whether the primary server clock and the host clock are in sync

  1. Run the following command on the host to determine whether the host clock is in sync with the primary server clock:

    nbcertcmd -checkClockSkew -server primary_server_name

  2. The command returns one of the following results:

    • If both clocks are in sync, the following displays:

      The current host clock is in sync with the master server.

    • If the current host is behind the primary server, the command reports the difference in seconds:

      The current host clock is behind the master server by 36 seconds(s).

    • If the current host is ahead of the primary server, the command reports the difference in seconds:

      The current host clock is ahead of the master server by 86363 second(s).

    • If the command is run on the primary server, the command skips the check and displays the following:

      Specified server is same as the current host. Clock skew check is skipped.

    If the clock skew on the host is causing a problem with the certificate validity, take corrective actions as necessary.

Feedback

Was this page helpful?
Previous

Deploying host ID-based certificates in an asynchronous manner

Next

Setting up trust with the master server (Certificate Authority)

Feedback

Was this page helpful?