Break the clock and watch authentication fail

short · 40 min · Objective 6.4

Task

Time drift presents as a security problem, which is why it consumes so much diagnostic effort. Skew a clock deliberately and observe certificate and token validation failing before anything mentions time.

Steps

  1. Establish a working TLS connection from the guest to the local service, and a working time-based one-time code: generate it in the guest with oathtool --totp -b SECRET and check it on the host with the same command. Record both in lab/net/time.md. The code is made from the CLIENT's clock, which is what skew breaks -- a token the server both issues and checks never sees the client's clock at all.
  2. Disable time synchronisation in the guest and set its clock forward by two years. Retry the TLS connection and record the exact error -- note that it blames the certificate, not the clock.
  3. Set the clock back by two years and retry. Record the different error message for the same underlying cause.
  4. Restore the clock to roughly correct but skewed by ten minutes, and compare the guest's one-time code with the host's. Record whether they match and what a verifier would say -- TOTP steps are 30 seconds, and verifiers typically accept one step either side. Kerberos, by the lesson, allows about five minutes.
  5. Re-enable synchronisation, confirm everything works, and write the diagnostic rule: what to check first when several unrelated systems fail to authenticate at once.

Verify

grep -Eci 'certificate' lab/net/time.md
grep -Eci 'not yet valid|expired' lab/net/time.md
grep -Eci 'token|skew' lab/net/time.md
grep -Eci 'check the clock|clock first|time first' lab/net/time.md

All four non-zero, with two DIFFERENT certificate errors recorded for the forward and backward skew. Both are the same cause wearing different messages, which is exactly why the fault is hard to spot.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.