Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
TLSDATE(1)			 User Manuals			    TLSDATE(1)

       tlsdate - secure	parasitic rdate	replacement

       tlsdate	   [-hnvVstlw]	   [-H	  [hostname]]	 [-p	[port]]	   [-P
       [sslv23|sslv3|tlsv1]]	[--certdir    [dirname]]     [-x     [--proxy]

       tlsdate is a tool for setting the system	clock by hand or by communica-
       tion with the network. It does not set the Real Time Clock. It  is  de-
       signed  to be as	secure as TLS (RFC 2246) but of	course the security of
       TLS is often reduced to whichever CA racket you believe is trustworthy.
       By  default,  tlsdate trusts your local CA root store - so any of these
       companies could assist in a  MITM  attack  against  you	and  you'd  be

       This  tool is designed to be run	by hand	or as a	system daemon. It must
       be run as root or otherwise have	the proper caps; it will not  be  able
       to  set	the  system time without running as root or another privileged

       -h | --help
	      Print the	help message

       -s | --skip-verification
	      Skip certificate verification

       -H | --host [hostname|ip]
	      Set remote hostname (default: '')

       -n | --dont-set-clock
	      Do not set the system clock to the time of the remote server

       -p | --port [port]
	      Set remote port (default:	'443')

       -P | --protocol [sslv23|sslv3|tlsv1]
	      Set protocol to use when	communicating  with  server  (default:

       -C | --certdir [dirname]
	      Set the local directory where certificates are located (default:
	      '/etc/ssl/certs')	This allows for	certificate or certificate au-
	      thority  (CA)  pinning. To ensure	that signatures	are only valid
	      if they are signed by a specific CA or certificate, set the path
	      to a directory containing	only the desired certificates.

       -x | --proxy [proxy-type://proxyhost:proxyport]
	      The  proxy argument expects HTTP,	SOCKS4A	or SOCKS5 formatted as

	      The proxy	support	should not leak	DNS requests and  is  suitable
	      for use with Tor.

       -v | --verbose
	      Provide verbose output

       -V | --showtime [human|raw]
	      Show  the	time retrieved from the	remote server in a human-read-
	      able format or as	a raw time_t.

       -t | --timewarp
	      If the local clock is before  RECENT_COMPILE_DATE;  we  set  the
	      clock  to	 the  RECENT_COMPILE_DATE. If the local	clock is after
	      RECENT_COMPILE_DATE, we leave the	clock alone. Clock setting  is
	      performed	 as  the  first	 operation and will impact certificate
	      verification. Specifically, this option is helpful if  on	 first
	      boot, the	local system clock is set back to the era of Disco and
	      Terrible	    Hair.      This	 should	     ensure	  that
	      not encountered because of a broken RTC or the lack of  a	 local
	      RTC;  we	assume	that tlsdate is	recompiled yearly and that all
	      certificates are otherwise considered valid.

       -l | --leap
	      Normally,	the passing of time or time yet	to come	 ensures  that
	      SSL  verify  functions  will fail	to validate certificates. Com-
	      monly, X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EX-
	      PIRED  are  painfully  annoying  but  still very important error
	      states. When the only issue with the certificates	in question is
	      the  timing information, this option allows you to trust the re-
	      mote system's time, as long as it	is  after  RECENT_COMPILE_DATE
	      and  before  MAX_REASONABLE_TIME.	 The  connection  will only be
	      trusted	   if	    X509_V_ERR_CERT_NOT_YET_VALID	and/or
	      X509_V_OKX509_V_ERR_CERT_HAS_EXPIRED are the only	errors encoun-
	      tered. The SSL verify function  will  not	 return	 X509_V_OK  if
	      there  are any other issues, such	as self-signed certificates or
	      if the user pins to a CA that is not used	by the remote  server.
	      This  is useful if your RTC is broken on boot and	you are	unable
	      to use DNSEC until you've	at least had  some  kind  of  leap  of
	      cryptographically	assured	data.

       -w | --http
	      Run  in web mode:	look for the time in an	HTTP "Date" header in-
	      side an HTTPS connection,	rather than in the TLS connection  it-
	      self.  The provided hostname and port must support HTTPS.

       It's likely! Let	us know	by contacting

       Note that tlsdate(1) is in Beta,	and may	not work as expected.

       Jacob Appelbaum <jacob at appelbaum dot net>

       tlsdate(1), tlsdate-helper(1), tlsdated(8), tlsdated.conf(5)

Linux				 OCTOBER 2012			    TLSDATE(1)


Want to link to this manual page? Use this URL:

home | help