時刻ずれによる証明書・ビルドエラー - clock skew の解決

2026-06-06 読了時間: 約10分 難易度: 中級

この記事で解決できること

• make の 「Clock skew detected」 警告と、TLS の 「certificate is not yet valid」 が同じ原因であることが分かる
• 時計のずれが原因かどうかを date / openssl で 即切り分け できる
• 時計を正し、ビルドと証明書検証を 正常化する手順 が身につく

clock skew とは何か？なぜ証明書とビルドが壊れるのか

結論: clock skew は system clock が実時刻からずれた状態。ビルドはファイル mtime が未来に、証明書は有効期間（notBefore）が未来に見えるため、どちらも「未来の時刻」として弾かれる。

clock skew（クロックスキュー）とは、マシンの system clock が正しい時刻からずれている状態を指す。ずれの方向で症状が変わる。

• 時計が遅れている（過去） → 取得したばかりの証明書が「まだ有効になっていない（not yet valid）」と判定される
• 時計が進んでいる（未来） → 生成したファイルの mtime が「未来」になり、ビルドツールが警告を出す

一見無関係なビルドエラーと証明書エラーが、**同じ「時刻の食い違い」**から生まれる点がこの問題の本質。証明書は notBefore（有効開始）/ notAfter（有効終了）という時刻の窓を持ち、make はファイルの新旧を mtime で比較する。どちらも「現在時刻」を基準にするため、基準そのものが狂うと連鎖的に壊れる。

まず時計がずれているかをどう確認するか

結論: timedatectl で同期状態、date -u で現在の UTC を確認し、信頼できる外部時刻と比較する。数十秒以上ずれていれば clock skew が原因。

最初の診断は同期状態と現在時刻の確認。

$ timedatectl

               Local time: Sat 2026-06-06 12:00:00 JST
           Universal time: Sat 2026-06-06 03:00:00 UTC
                 RTC time: Sat 2026-06-06 03:00:00
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: no
              NTP service: active

System clock synchronized: no は未同期のサイン。次に外部の信頼できる時刻と突き合わせる。HTTP レスポンスの Date ヘッダは手軽な基準になる。

$ date -u
$ curl -sI https://www.google.com | grep -i '^date:'

2 つの時刻が数十秒〜数分以上ずれていれば clock skew が原因と判断してよい。タイムゾーンの違い（JST と UTC）と取り違えないよう、比較は date -u（UTC）で行うのが安全。

ビルドの「Clock skew detected」をどう直すか

結論: 時計を正した後、未来 mtime のファイルを find . -newermt now で洗い出し touch で現在時刻に直す。make clean で作り直すのが最も確実。

make 実行時に次のような警告が出るのが典型。

make: Warning: File 'main.o' has modification time 9876 s in the future
make: warning:  Clock skew detected.  Your build may be incomplete.

これはソースやオブジェクトファイルの mtime が、現在の system clock より未来になっているために起きる。make は mtime の新旧で再ビルド要否を判断するため、未来のファイルがあると依存解決が壊れ、ビルドが不完全になる恐れがある。

手順は「①時計を正す → ②未来 mtime を直す」の順。先に時計を直さないと、touch しても再びずれた現在時刻が刻まれる。

# 1. 時計を正す（詳細は後述の #fix-clock）
$ sudo timedatectl set-ntp true

# 2. 未来 mtime のファイルを検出
$ find . -newermt now -type f

# 3. 現在時刻に揃える
$ find . -newermt now -type f -exec touch {} +

最も確実なのは中間生成物を捨てて作り直す方法。

$ make clean && make

証明書の「not yet valid / expired」をどう直すか

結論: openssl x509 -noout -dates で notBefore/notAfter を確認し、現在時刻が窓の外なら時計を疑う。時計を正せば証明書を再発行せずに解消することが多い。

時計が狂うと、正常な証明書でも検証に失敗する。ツール別の典型的なメッセージは次の通り。

# curl
curl: (60) SSL certificate problem: certificate is not yet valid

# git clone (https)
fatal: unable to access '...': server certificate verification failed

# Go 製ツール
x509: certificate has expired or is not yet valid

# apt update
E: Release file for ... is not valid yet (invalid for another 5h 30min ...)

apt の「is not valid yet」は clock skew の分かりやすい証拠。証明書側の有効期間を openssl で確認する。

# ローカルの証明書ファイル
$ openssl x509 -in cert.pem -noout -dates

# 接続先サーバの証明書
$ echo | openssl s_client -connect example.com:443 2>/dev/null \
    | openssl x509 -noout -dates

notBefore=Jun  5 00:00:00 2026 GMT
notAfter=Sep  3 23:59:59 2026 GMT

現在の UTC（date -u）が notBefore より前なら「not yet valid」、notAfter より後なら「expired」。どちらも証明書自体は正常で、時計を正せば解消する。

時計を正しく直すには？

結論: timedatectl set-ntp true で NTP 同期を有効化し、chronyc makestep で即時補正。再起動後も維持するため hwclock --systohc で RTC へ書き戻す。

NTP 同期を有効化するのが基本。

$ sudo timedatectl set-ntp true
$ timedatectl   # System clock synchronized: yes を確認

大きくずれている場合、chrony は安全のため徐々に補正する。即時に合わせたいときは makestep を使う。

$ sudo chronyc makestep
$ chronyc tracking   # オフセットが 0 付近に収束したか確認

再起動でまた時刻がリセットされる（RTC 電池切れなど）場合は、正した system clock をハードウェアクロックへ書き戻す。

$ sudo hwclock --systohc

NTP 同期の仕組み・systemd-timesyncd と chrony の使い分けは サーバ時刻ズレの対処（NTP 同期） で詳しく扱う。

再発させないためのチェックリスト

結論: NTP 常駐・RTC 書き戻し・VM/NFS の時刻同期を恒久設定にすれば、clock skew 由来のビルド・証明書エラーはほぼ防げる。

# 同期状態・UTC・外部時刻を一括確認
timedatectl; echo "--- local UTC ---"; date -u; \
  echo "--- remote ---"; curl -sI https://www.google.com | grep -i '^date:'