Sertifikat Daun Valid, Rantai Kedaluwarsa: Baca Kedalamannya

Anda memeriksa sertifikat server, melihat masih ada berbulan-bulan di jam, dan klien tetap menolak koneksi dengan pesan kedaluwarsa. Tanggal yang Anda baca milik daun, dan keluhan bisa tentang sesuatu yang lebih dalam di jalur. Verifikasi menelusuri rantai, dan sertifikat apa pun yang dipilih penelusuran ini bisa gagal di jendela validitasnya sendiri. Baca mana yang gagal sebelum memperbarui apa pun.

Kedalaman menamai sertifikat yang gagal

Dalam diagnostik OpenSSL, kedalaman 0 adalah sertifikat target dan kedalaman 1 adalah penerbit yang menandatanganinya, dengan angka lebih tinggi berlanjut menuju jangkar kepercayaan. Kedaluwarsa yang dilaporkan pada kedalaman 1 tidak dibantah oleh notAfter yang berlaku pada daun, jadi memeriksa ulang sertifikat yang terlihat tidak akan pernah menjelaskan kesalahan itu.

Catat sidik jari sertifikat yang gagal bersama subjeknya, karena sertifikat berbeda bisa membawa nama CA yang sama. Penandatanganan silang menghasilkan persis situasi itu: otoritas yang sama muncul lebih dari sekali, dengan tanggal validitas berbeda, dan verifikator memilih yang tidak Anda duga. Label yang familiar bukan pengenal, dan sidik jari adalah yang membedakan dua objek yang berbagi nama.

Perhatikan juga produk dengan lebih dari satu peran sertifikat. Di OpenVPN Access Server, sertifikat yang melindungi antarmuka web terpisah dari yang digunakan untuk koneksi VPN, jadi peramban yang membuka halaman admin tidak membuktikan apa pun tentang jalur terowongan.

Input kepercayaan bukan sama dengan kandidat rantai

Berikan kedua input itu kepada verifikator secara terpisah dan eksplisit. Berkas kepercayaan menyimpan jangkar yang Anda terima; bundel tidak tepercaya menyimpan sertifikat perantara yang ditawarkan untuk membangun jalur. Mencampurnya adalah cara orang tanpa sengaja menaikkan perantara menjadi akar lalu bertanya-tanya mengapa kesalahan yang sama mengikuti mereka antar mesin.

$ openssl verify -verbose -show_chain -purpose sslserver \
    -CAfile trusted-roots.pem -no-CApath -no-CAstore \
    -untrusted intermediates.pem server.pem

Menonaktifkan jalur dan penyimpanan bawaan dengan -no-CApath -no-CAstore menjaga pengujian tetap jujur: hasilnya lalu bergantung pada berkas yang Anda sebutkan, bukan pada apa yang kebetulan dipercaya stasiun kerja. Referensi verifikasi OpenSSL mendokumentasikan opsi ini dan diagnostik yang dihasilkannya.

-show_chain mencetak rantai yang dibangun saat verifikasi berhasil, yang berguna untuk memastikan jalur itu memang yang Anda maksud. Saat gagal, simpan kedalaman dan subjek yang dilaporkan; kedua bidang itu memberi tahu pembaca berikutnya sertifikat mana yang harus diperiksa.

Yang tidak dilakukan ini adalah mereproduksi kebijakan setiap klien. Pin, pembatasan tujuan, atau pemeriksaan identitas khusus klien hidup di klien, bukan di perintah ini. Itulah pengaturan yang harus diperiksa ketika verifikasi lolos di server dan koneksi tetap gagal. Pisahkan kedua diagnosis, atau Anda akan memperbarui sertifikat yang sehat sambil mengejar kesalahan pinning.

Apa yang dibuktikan pemeriksaan dan apa yang ditinggalkannya

Ini adalah pemeriksaan jalur dan tujuan terhadap berkas kepercayaan yang Anda sediakan. Untuk pemeriksaan nama HTTPS, tambahkan nama host yang diharapkan melalui opsi yang sesuai; untuk koneksi VPN, pertahankan pemeriksaan identitas yang dikonfigurasi klien dan gunakan materi kepercayaan yang benar-benar dibaca klien tersebut.

Yang dikirim server adalah sekumpulan kandidat, bukan jalur yang akhirnya akan dibangun klien Anda. Kepercayaan lokal dan aturan pembangunan pustaka keduanya membentuk hasilnya, itulah sebabnya respons yang sama bisa terverifikasi di satu mesin dan gagal di mesin lain. Bandingkan penyimpanan kepercayaan terkelola dan implementasi TLS klien yang gagal dengan milik klien yang berfungsi sebelum menganggap evaluasi identik. Perbedaan di sana menjelaskan banyak laporan „hanya laptop ini yang gagal“.

Untuk melihat jendela setiap sertifikat alih-alih satu per satu, cetak sebagai satu set:

$ openssl x509 -in server.pem -noout -subject -dates
$ openssl crl2pkcs7 -nocrl -certfile intermediates.pem \
    | openssl pkcs7 -print_certs -noout

Perintah kedua itu mendaftar subjek dan penerbit tanpa mendekode setiap berkas dengan tangan, begitulah Anda menemukan perantara yang tanggalnya sudah lewat sementara daun masih terlihat baik.

Perbaiki jalur tanpa melemahkan verifikasi

Ketika perantara yang kedaluwarsa atau sertifikat bertanda tangan silang yang usang disediakan, dapatkan rantai penerbit yang didukung saat ini dan terapkan melalui alur kerja sertifikat terdokumentasi layanan. Ketika klien kekurangan jangkar terkelola yang dimaksud, perbarui konfigurasi kepercayaan terkelolanya atau perangkat lunak klien. Tolak jalan pintas menandai setiap sertifikat dalam bundel sebagai akar hanya untuk membungkam pesan.

Penanganan akar layak mendapat catatan, karena ringkasan sering melebih-lebihkannya. RFC 5280 memperlakukan jangkar sebagai input yang berada di luar jalur prospektif, sedangkan OpenSSL mendokumentasikan pemeriksaan validitas yang menyertakan sertifikat CA akarnya. Kedua pernyataan benar untuk sistemnya masing-masing; menggeneralisasi perilaku kedaluwarsa akar satu pustaka ke setiap klien menghasilkan jawaban salah yang percaya diri.

Setelah perubahan, paksa autentikasi baru pada klien yang terdampak dan pastikan pesan kedaluwarsa spesifik itu hilang. Perbarui daun hanya jika daun itu sendiri tidak cocok. Menonaktifkan pemeriksaan waktu atau memulihkan sertifikat silang historis tidak menghasilkan jalur saat ini yang valid; itu hanya menunda kegagalan berikutnya.