VPN証明書がまだ有効でない：三つの原因と一つの確認順序
「まだ有効でない」とは、端末の時計が遅れているか、有効期間が本当に後から始まるか、中間証明書がまだ開いていないかのいずれかです。この順序で確認してください。
クライアントを開き、何か月も使ってきたプロファイルを選ぶと、「certificate is not yet valid」で停止します。サインインに変化はなく信頼ストアもおそらく正常で、ハンドシェイクで提示された証明書には検証側が使っている時刻より後に始まる有効期間があります。まったく同じメッセージを生む状況は三つあり、それぞれ対処が異なります。以下の順序で、時計や証明書ファイルに触れる前にどれなのかを判断できます。
三つの原因のどれを見ているか
一つ目の原因はローカルです。確認を行う端末の時計が、証明書の開始日より前になっています。CMOS電池が切れたハードウェア、古いスナップショットから復元した仮想マシン、時間を失うほど長く電源を切っていた機器、外向きNTPが遮断されていることに誰も気づいていないネットワークで見られ、証明書が完全に有効でもこの形で失敗します。
二つ目の原因は発行者側にあり、証明書が本当に未来に始まります。三つ目の原因は最も時間を浪費し、末端証明書は有効なのに提示されたチェーン内の別の証明書が有効でないため、エラーは一度もインストールしていない素材を名指しします。
それを分ける問いは一つです。失敗は端末に付いて回るのか、サービスに付いて回るのか。同じネットワーク上の二台が違う挙動を示すなら時計です。すべてのクライアントが同じ形で失敗するなら、証明書の有効期間とその背後のチェーンです。
実際に提示された証明書から有効期間を読む
以前の配備から残ったPEMファイルを調べるのではなく、いまサービスが送っているチェーンを尋ねてください。openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts はチェーン内の各証明書を出力します。必要なブロックを保存して openssl x509 -noout -subject -issuer -dates を実行し、最後のものが notBefore と notAfter を出力します。この二つの値が判断を決め、Windowsでは接続の証明書ダイアログと、エクスポートしたファイルに対する certutil -dump が同じ項目を示します。
有効期間は始まりだけでなく両端を読んでください。二時間後に開く証明書と二時間後に閉じる証明書は異なるメッセージで失敗し、関わるチームも異なります。エラーがどの証明書を指すか（末端・中間・ルート）を記録してください。
有効期間を待たずに試すこともでき、検証は明示的な時刻を受け付けます。openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem はそのタイムスタンプ時点でチェーンを評価します。現在時刻で実行して失敗を再現し、次に証明書の開始時刻で実行して、期間が開けば同じチェーンが通ることを確認します。RFC 5280 は有効性フィールドと、その外で証明書を使ってはならないという規則を定めており、それはクライアントがたった今適用した規則です。
自分の時計か、相手の時計か
端末の時計を、信頼できる情報源から得た証明書の開始時刻（UTC）と比較します。date -u はその瞬間を示し、systemd ホストでは timedatectl status が時計が同期しているかも報告します。Windowsでは w32tm /query /status が現在の情報源と最後に成功した同期を示します。タスクトレイのタイムゾーンは表示上の選択であり時計の誤りではなく、検証側はUTCの瞬間を比較します。
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
時計が遅れているなら、証明書素材を変える前に再同期して再試験してください。数分や数時間ずれた端末は出会うすべての最近発行された証明書を拒否し、一つのサービスだけではないため単一サービスの説明はたいてい誤りです。時計が正しく同期しているなら端末を見るのはやめ、有効期間は発行者のものなので通すためにローカル設定を変えるべきではありません。
その表が判断のすべてです。時計を証明書の期待する値に動かすのも時刻検査を切るのも修理ではなく、どちらもエラーを生んだ状態を隠すだけです。
末端が正常に見えるのにチェーンが失敗する理由
更新された末端証明書と交換用の中間証明書は通常まとめて配備され、いつも同じ瞬間に届くわけではありません。サービスが、自身の有効期間が後から始まる中間証明書で署名した新しい末端を送ることも、新しい末端の下で古い中間証明書を提供し続けることもあります。どちらでも、末端自身の日付が妥当に見えるままチェーンが失敗します。
負荷分散されたエンドポイントは、これを「壊れている」から「一貫しない」に変えます。再試行が成功する、あるいは一方のネットワークだけ動くなら、設定を変える前にどのピアが応答し、どのチェーンを送ったかを記録してください。openssl s_client は接続先アドレスを出力するので、数回試せば各ノードが同じチェーンを提供しているか分かります。
検証を保ったままの修復経路
時計の問題は、検証を有効にしたまま端末側で直します。証明書の問題は、いまを含む有効期間に対して発行された素材で運用者が直します。クライアント設定でまだ有効でない証明書を有効にはできず、時刻検査を飛ばすフラグは診断を確認するためのもので、本番に配備するためのものではありません。
証明書が計画的な有効化のために用意されている場合は、切り替え計画に従ってください。有効期間が開いてからインストールするか提供者が文書化した重複手順を使い、早く入れて利用者に警告をクリックさせるのは避けてください。無視することを覚えられる警告は、短い遅延より高くつきます。
最後に、失敗が起きたときと同じ形で再試験してください。新しいセッション、同じクライアント、実際に必要なリソースです。TLSライブラリは接続の寿命のあいだ検証済みチェーンをキャッシュすることがあり、再開したセッションが必ず再検査するとは限らないため古いセッションは修正後も失敗し続けたり退行後も動き続けたりしますが、ビューアで開くファイルは読めることしか証明せず、完了したハンドシェイクがチェーンの検証を証明します。
チケットを閉じる前に四つを確認してください。失敗した端末のUTC時刻と同期状態、提示されたチェーン内の各証明書の notBefore と notAfter、二台目のクライアントからの同じチェーン、そしてエラーが証明書に与える名前であり、時計が正しく有効期間がまだ開いていないなら残りは運用者の仕事で、こちら側の正しい行動は検査を弱めることではなく期間を待つことです。