Skip to content

ONVIF auth fails with clock drift

You are adding an ONVIF camera, the credentials are correct (you tested them in the camera’s own web UI moments before), but discovery or the auth step rejects them. This page is for installers on-site walking the ONVIF pairing flow.

Symptom

The add-camera flow returns one of:

  • Authentication failed -- check username and password
  • Clock sync failed -- check camera NTP settings
  • A generic Unauthorized from the gateway log

The credentials themselves work when you log into the camera’s HTTP interface — this rules out a bad password.

Likely causes

  1. Camera clock is more than 5 seconds off the gateway clock. ONVIF’s WS-Security UsernameToken Digest auth hashes a timestamp into the digest. If the camera and the gateway disagree on the current time by more than the tolerance, the digest never matches and the camera rejects the request as unauthorized. The NovaVMS gateway code logs a warning when the offset exceeds 5 seconds.
  2. Camera has no NTP configured. After a reboot or factory reset the camera’s real-time clock returns to an epoch like 2000-01-01. Every ONVIF request then fails until NTP syncs the clock.
  3. Camera timezone is misconfigured and reported as local time, not UTC. Some camera firmwares advertise their local time in GetSystemDateAndTime without a TimeZone block. If the gateway is on UTC and the camera is on GMT+08, the apparent offset is 8 hours — enough to fail.
  4. Daylight-saving transition misapplied by the camera. Cameras that apply DST without a DaylightSavings flag in their time response drift by an hour twice a year.

Fixes

Compare clocks first

On the gateway, run:

Terminal window
date -u

Open the camera’s own web UI and note its system time. For many camera vendors the time is at Configuration -> System -> Date & Time. Compare:

  • The two UTC times must be within 5 seconds of each other.
  • If the camera reports local time, convert it to UTC first before comparing.

If the camera has no NTP

  1. In the camera’s web UI, enable NTP.
  2. Set the NTP server to pool.ntp.org (or a server reachable from the camera’s VLAN). Corporate networks often require you to use the site’s internal NTP server because pool.ntp.org egress is blocked.
  3. Save and reboot the camera.
  4. Re-check date -u on the gateway vs the camera’s system time.

If the camera is on local time, not UTC

  1. In the camera’s web UI set the timezone explicitly (not “Auto”).
  2. Enable NTP so the camera re-syncs to UTC on the next interval.
  3. Retry the add-camera flow from the NovaVMS installer console.

If the camera has no NTP support at all

A small number of low-end cameras have no NTP client. You are stuck setting the clock manually each time the camera boots — this is a long-term operational hazard. Mark the camera for replacement at the next refresh cycle.

Verify the fix

  1. date -u on the gateway and the camera’s reported UTC time match within 2 seconds.
  2. The gateway log no longer emits camera clock offset exceeds 5s warnings on the Validate call.
  3. The add-camera flow completes past the auth step and transitions the camera to pending.
  4. The camera transitions to online within 30 seconds.

Still stuck?