Problem: Time sync with Domain Time Server fails with the logged error "The digital signature of the object did not verify."
This article applies to Domain Time II.
Last Updated: 6 June 2012
Time sync with Domain Time Server fails with the logged error "The digital signature of the object did not verify." The full error
in the log may appear similar to "ERROR: Could not verify server response; error 2148098064: The digital signature of
the object did not verify"
Domain Time Servers and Clients have the option of using authenticated network packets to communicate. This option uses a symmetric key
method where both the time server and the time requestor have a copy of the shared key which they use to verify authenticity of the
packets they exchange. As long as both systems have the same key, communication can proceed. However, if there is a mismatch between
the keys used by the components, the authenticated communication will fail resulting in the "digital signature did not verify" error.
As of version 5.1 Domain Time offers two authentication methods: a manually-defined symmetric key process compatible with standard
NTP authentication methods, and the proprietary NT5DS-mode automated method used by Windows domains.
In most cases, symmetric key authentication must be intentionally enabled by the administrator, however, Windows Authentication is enabled by default
on Domain Time Masters and Slaves.
The Windows Authentication method uses an internal Windows security Identifier (see TechNet: How Security identifiers work)
that is supposed to be unique and automatically replicated among all domain member systems to construct the shared authentication key.
However, sometimes this RID (Relative Identifier) does not match on some domain members due to changes on the domain (possible causes
include merging domains, promoting older DCs, schema upgrades, etc.). If so, then the Windows Authentication of packets will fail.
Since Windows Authentication is enabled by default on Domain Time Masters and Slaves, you may discover this error more often on Domain Time
Slaves that cannot synchronize with the Master. Also, on older versions of the software, the inability to communicate with the Master may also
cause a machine that is attempting to be configured as a Slave may revert to being an Independent Server as a side effect of not being able to
communicate with the Master.
- If the manual Symmetric Key authentication method is enabled, then you must ensure that all systems are using the same shared key.
See the Symmetric Keys
page in the Domain Time II Documentation for details on how to configure authentication.
- If the error is caused by a mismatched domain Security Identifier when using Windows Authentication, the solution is to resolve the
replication errors among the machines on the Windows domain. How to do this in your environment is beyond the scope of our product.
Consult with Microsoft on the best way to accomplish this.
- If you encounter the Slaves that automatically revert to Independent Servers issue due to the communication error, upgrade the
Master and Slave to the latest version of Domain Time and re-set the machine to be a Slave.
Until you are able to implement the proper resolution detailed above, you can turn off authentication on your affected systems. This is
typically done on the "Obtain the time property page of the Domain Time Control Panel applet.
For Masters and Independent Servers, as well as for Clients using defined Time Sources, the setting is found in the settings for
each individual Time Source. On the "Obtain the Time" page, you may click "Edit" to change the settings for any listed time sources.
For Slaves and Clients in Automatic Discovery mode, you may uncheck the "Authenticate time samples" checkbox on the "Obtain the Time" property page itself.