Apa yang diperiksa klien VPN Anda sebelum mempercayai sebuah sertifikat

Klien VPN Anda mengatakan sertifikat tidak dapat diverifikasi, dan dialognya berhenti di situ. Berkasnya ada, servernya hidup, dan profil yang sama berfungsi di laptop lain bulan lalu. Di balik peringatan satu baris itu, klien menjalankan sertifikat peer melewati empat gerbang: otoritas sertifikat yang Anda konfigurasi menjamin jalur tanda tangan, jalur itu mencapai otoritas, nama peer adalah yang Anda minta, dan sertifikat dapat dipakai sekarang untuk tujuan ini. Temukan gerbang yang tertutup dan perbaikannya biasanya satu berkas; lewati langkah itu dan Anda akan mengimpor ulang bundel sepanjang sore.

Baca dialognya sebelum menyunting profil

Pesan galat sertifikat dirumuskan oleh pustaka di bawahnya, bukan oleh produk VPN yang Anda pasang, jadi string persisnya adalah bukti pertama Anda. «Tidak dapat memperoleh sertifikat penerbit lokal» menunjuk jalur atau jangkar kepercayaan. «Sertifikat telah kedaluwarsa atau belum valid» menunjuk waktu. «Tujuan sertifikat tidak didukung» menunjuk penggunaan kunci yang diperluas. Ketidakcocokan nama memberi tahu nama mana yang diminta. Tidak satu pun dari keempatnya diperbaiki dengan memasang ulang klien.

Naikkan tingkat log sebelum mengubah apa pun. OpenVPN melaporkan kegagalan verifikasi di sekitar jabat tangan saat Anda menjalankannya dengan --verb 4, dan strongSwan mencatat keputusan identitas dan rantainya ke log charon. Lalu pastikan sertifikat mana yang Anda periksa, karena orang rutin menguji berkas di disk sementara profil menyematkan salinan yang lebih lama. Saat profil menyematkan blok PEM, sertifikat yang disematkan itulah yang diuji.

Otoritas sertifikat menandatangani identitas, bukan izin

Otoritas menyimpan sebuah nama dan kunci penandatanganan. Ia menerbitkan sertifikat yang mengikat kunci publik ke nama itu menurut kebijakannya sendiri, dengan jendela masa berlaku dan batasan penggunaan terlampir. Klien Anda hanya perlu sertifikat otoritas untuk mengenali penerbit; ia tidak pernah perlu kunci penandatanganan, dan mengirim kunci itu ke klien akan memberi mereka kemampuan mencetak identitas apa pun yang dipercaya oleh penerapan.

Mempercayai otoritas membuat setiap sertifikat yang ditandatanganinya menjadi kandidat, bukan peer yang tepat. Sertifikat server web dari CA internal yang sama juga kandidat. Itulah sebabnya gerbang nama dan tujuan ada, dan sebabnya kunci CA yang terekspos lebih penting daripada server tunggal mana pun: ia menjangkau setiap identitas yang pernah diterbitkan otoritas. Terbitkan sertifikat klien per perangkat, sehingga laptop yang hilang menjadi satu pencabutan alih-alih penggantian kunci seluruh penerapan.

Bangun ulang jalur yang coba dibangun klien

Jalur berjalan dari sertifikat peer, melewati nol atau lebih sertifikat perantara, ke akar di penyimpanan kepercayaan Anda. Sertifikat perantara yang hilang adalah kegagalan rantai paling umum, dan dari sisi klien tampilannya persis sama dengan akar yang tidak tepercaya. Baca daunnya dulu, lalu biarkan OpenSSL membangun jalur dari materi yang hendak Anda kirim.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Status keluar nol berarti jalur berhasil dibangun dari berkas-berkas itu; kegagalan menyebutkan sertifikat yang tidak dapat dicapainya. Jika openssl verify berhasil sementara klien masih menolak, perbedaannya ada pada apa yang sebenarnya dikirim server atau pada berkas kepercayaan mana yang dimuat profil. Di OpenVPN, sertifikat perantara dapat ikut dalam berkas sertifikat server atau disediakan terpisah dengan --extra-certs, dan bundel berisi dua akar di bawah nama subjek yang sama akan mengirim salah satu klien Anda ke cabang yang salah.

Nama dan tujuan adalah gerbang terpisah

Pembangunan rantai tidak pernah menanyakan apakah nama itu milik Anda. OpenVPN memeriksanya hanya saat profil menyetel --verify-x509-name, dan kebiasaan lama mencocokkan hanya nama umum rusak pada sertifikat yang identitasnya hidup di subjectAltName. Penerapan IKEv2 mencocokkan identitas yang dikonfigurasi dengan entri SAN atau dengan nama terbedakan, tergantung kliennya, dan nilai wildcard atau %any diam-diam mematikan perbandingan yang Anda kira Anda miliki.

Berikutnya waktu dan tujuan. Laptop yang jamnya beberapa jam lebih cepat menolak sertifikat yang belum valid, dan sertifikat perantara yang kedaluwarsa menggagalkan jalur sementara daunnya masih berlaku. Kegagalan tujuan berasal dari sertifikat tanpa serverAuth dalam penggunaan kunci yang diperluas, atau dengan keyUsage yang tidak mengizinkan tanda tangan jabat tangan, yang dilaporkan OpenSSL sebagai tujuan sertifikat tidak didukung. Terbitkan ulang dari templat yang benar; tidak ada apa pun dalam pesan itu yang menjadi alasan mematikan verifikasi.

Pencabutan hanya berjalan jika seseorang mengonfigurasinya

CRL atau respons OCSP tidak diperiksa secara otomatis. Di server OpenVPN, sertifikat klien dicocokkan dengan daftar hanya saat --crl-verify menunjuk ke salah satunya. Pemeriksaan sertifikat server di sisi klien bergantung pada implementasi dan sering kali tidak ada. strongSwan memerlukan plugin pencabutan dan kebijakan sebelum melihat CRL untuk peer.

Itu menjelaskan tiket yang akhirnya Anda terima: sertifikat klien yang dicabut tetap tersambung, dan semua orang menyimpulkan pencabutan rusak. Tidak ada yang memeriksa. Terbitkan dan segarkan CRL, atau jaga sertifikat klien cukup singkat sehingga pencabutan yang basi hanya penting sebentar, dan latih jalur pencabutan pada sertifikat laboratorium sebelum Anda membutuhkannya saat insiden.

Urutan perbaikan yang menjaga verifikasi tetap aktif

Urutkan menurut gejala sebelum menyentuh berkas, karena setiap baris tabel mengirim Anda ke objek yang berbeda.

Telusuri daftar dalam satu kali jalan: pastikan berkas yang dimuat profil, bangun jalurnya sendiri, periksa bahwa server mengirim sertifikat perantara, bandingkan jam, baca SAN, baca EKU, lalu sambungkan ulang dan lihat baris log yang sama menghilang. Jika sebuah perangkat sama sekali tidak dapat diberi CA, penyematan adalah alternatif yang jujur, karena OpenVPN 2.6 menerima --peer-fingerprint dan mempersempit kepercayaan ke satu kunci alih-alih menghapus pemeriksaan. RFC 5280 adalah rujukan untuk arti setiap bidang itu.