Anda membuka klien, memilih profil yang sudah Anda gunakan berbulan-bulan, dan klien berhenti dengan "certificate is not yet valid". Tidak ada yang berubah pada proses masuk Anda, dan penyimpanan kepercayaan mungkin baik-baik saja: sertifikat yang disajikan dalam jabat tangan membawa jendela validitas yang mulai lebih lambat daripada saat yang digunakan pemeriksa. Tiga situasi berbeda menghasilkan pesan yang sama persis, dan masing-masing memerlukan tindakan berbeda. Urutan di bawah memberi tahu Anda mana yang Anda hadapi sebelum menyentuh jam atau berkas sertifikat.

Penyebab mana dari ketiganya yang Anda lihat

Penyebab pertama bersifat lokal: perangkat yang melakukan pemeriksaan memegang jam yang lebih awal daripada tanggal mulai sertifikat. Anda melihatnya pada perangkat keras dengan baterai CMOS mati, pada mesin virtual yang dipulihkan dari snapshot lama, pada peralatan yang cukup lama dimatikan hingga kehilangan waktu, dan pada jaringan tempat NTP keluar diblokir dan tidak ada yang menyadarinya. Sertifikat bisa sepenuhnya valid dan tetap gagal dengan cara ini.

Penyebab kedua milik penerbit, karena sertifikat memang dimulai di masa depan: diterbitkan lebih awal, dibuat dengan waktu mulai eksplisit, atau ditandatangani sebagai bagian dari langkah aktivasi yang belum dijalankan. Penyebab ketiga paling banyak membuang waktu, karena sertifikat daun masih berlaku sementara sertifikat lain dalam rantai yang disajikan tidak, sehingga galat menyebut materi yang tidak pernah Anda pasang.

Satu pertanyaan memisahkan ketiganya. Apakah kegagalan mengikuti perangkat atau layanan? Dua mesin di jaringan yang sama yang berperilaku berbeda menunjuk ke jam. Setiap klien gagal dengan cara yang sama menunjuk ke jendela sertifikat dan rantai di belakangnya.

Baca jendela dari sertifikat yang benar-benar disajikan

Jangan memeriksa berkas PEM sisa dari penerapan sebelumnya; mintalah rantai yang dikirim layanan sekarang. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts mencetak setiap sertifikat dalam rantai. Simpan blok yang Anda perlukan dan jalankan openssl x509 -noout -subject -issuer -dates; yang terakhir mencetak notBefore dan notAfter, dan kedua nilai itulah yang menentukan. Di Windows, dialog sertifikat untuk koneksi dan certutil -dump pada berkas yang diekspor menampilkan bidang yang sama.

Baca kedua ujung jendela, bukan hanya awalnya. Sertifikat yang terbuka dalam dua jam dan yang menutup dalam dua jam gagal dengan pesan berbeda dan melibatkan tim berbeda. Catat sertifikat mana yang disebut galat — daun, perantara, atau akar — karena itu menentukan apakah ada yang bisa diperbaiki di sisi klien sama sekali.

Anda juga dapat menguji jendela tanpa menunggunya. Verifikasi menerima waktu eksplisit: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem mengevaluasi rantai pada stempel waktu itu. Jalankan dengan waktu saat ini untuk mereproduksi kegagalan, lalu dengan waktu mulai sertifikat untuk memastikan rantai yang sama lolos begitu jendela terbuka. RFC 5280 mendefinisikan bidang validitas dan aturan bahwa sertifikat tidak boleh digunakan di luarnya, dan itulah aturan yang baru saja ditegakkan klien Anda.

Jam Anda, atau jam mereka

Bandingkan jam perangkat dengan awal sertifikat dalam UTC, dari sumber yang Anda percaya. date -u memberi saat itu, dan timedatectl status pada host systemd juga melaporkan apakah jam tersinkronisasi. Di Windows, w32tm /query /status menampilkan sumber saat ini dan sinkronisasi terakhir yang berhasil. Zona waktu yang tampil di baki adalah pilihan tampilan, bukan jam yang salah; pemeriksa membandingkan saat UTC.

What you seeMost likely readingNext step
Clock behind, one device affectedLocal time faultResync time, keep validation on, retest
Clock correct, window opens soonCertificate staged earlyWait for the window or follow the cutover plan
Clock correct, intermediate not yet validChain material mismatchOperator replaces the intermediate
Some peers pass, others do notInconsistent nodesRecord each peer's chain before changing anything

Jika jam tertinggal, sinkronkan ulang dan uji ulang sebelum mengubah materi sertifikat apa pun. Perangkat yang meleset beberapa menit atau jam menolak setiap sertifikat yang baru diterbitkan yang ditemuinya, bukan hanya satu layanan, jadi penjelasan satu layanan biasanya yang salah. Jika jam benar dan tersinkronisasi, berhentilah melihat perangkat: jendela itu milik penerbit, dan tidak ada pengaturan lokal yang boleh disesuaikan agar lolos.

Tabel itu adalah seluruh keputusan. Menggeser jam ke apa yang diharapkan sertifikat bukanlah perbaikan, dan mematikan pemeriksaan waktu juga bukan, karena keduanya menyembunyikan kondisi yang menghasilkan galat.

Mengapa rantai gagal sementara daun tampak baik

Daun yang diperbarui dan perantara pengganti biasanya dikirim bersama, dan tidak selalu tiba pada saat yang sama. Layanan dapat mengirim daun baru yang ditandatangani oleh perantara yang jendelanya sendiri mulai lebih lambat, atau terus menyajikan perantara lama di bawah daun baru. Bagaimanapun rantai gagal sementara tanggal daun itu sendiri tampak wajar.

Titik akhir dengan penyeimbangan beban mengubah ini dari rusak menjadi tidak konsisten. Jika percobaan ulang berhasil, atau satu jaringan berfungsi sementara yang lain tidak, catat peer mana yang menjawab dan rantai mana yang dikirimnya sebelum mengubah pengaturan. openssl s_client mencetak alamat yang terhubung, sehingga beberapa percobaan mengungkap apakah setiap node menyajikan rantai yang sama.

Jalur perbaikan yang menjaga verifikasi tetap utuh

Masalah jam diperbaiki di perangkat dengan verifikasi tetap aktif. Masalah sertifikat diperbaiki oleh operator dengan materi yang diterbitkan untuk jendela yang sudah mencakup sekarang. Tidak ada pengaturan klien yang membuat sertifikat belum-valid menjadi valid; tanda yang melewati pemeriksaan waktu ada agar Anda mengonfirmasi diagnosis, bukan agar Anda mengirimkannya ke produksi.

Ketika sertifikat disiapkan untuk aktivasi terencana, ikuti rencana peralihan. Pasang saat jendelanya terbuka, atau gunakan prosedur tumpang tindih yang didokumentasikan penyedia, daripada memasang lebih awal dan mengajari pengguna mengklik lewat peringatan. Peringatan yang dipelajari orang untuk diabaikan lebih mahal daripada penundaan singkat.

Terakhir, uji ulang seperti kegagalan terjadi: sesi baru, klien yang sama, sumber daya yang benar-benar Anda butuhkan. Pustaka TLS dapat menyimpan rantai terverifikasi selama umur koneksi, dan sesi yang dilanjutkan belum tentu memeriksanya lagi, sehingga sesi lama dapat terus gagal setelah perbaikan atau terus berfungsi setelah regresi. Berkas yang terbuka di penampil hanya membuktikan berkas dapat dibaca; jabat tangan yang selesai membuktikan rantai tervalidasi.

Sebelum menutup tiket, konfirmasi empat hal: waktu UTC dan status sinkronisasi perangkat yang gagal, notBefore dan notAfter setiap sertifikat dalam rantai yang disajikan, rantai yang sama dari klien kedua, dan nama yang diberikan galat pada sertifikat. Jika jam benar dan jendela belum terbuka, sisanya adalah pekerjaan operator, dan langkah yang benar di pihak Anda adalah menunggu jendela alih-alih melemahkan pemeriksaan.

Artikel terkait