tujuan sertifikat tidak didukung: mengapa CA perantara gagal

Tujuan sertifikat server tampak benar, kuncinya cocok, tanggalnya baik, dan koneksi tetap gagal dengan unsupported certificate purpose. Detail yang menyelesaikan ini biasanya ada di baris yang sama dengan galat: nilai kedalaman dan subject yang menyebut sertifikat lebih tinggi dalam rantai. Dua pengujian berbeda dijalankan, dan hanya satu yang menyangkut sertifikat daun. Membandingkannya menjelaskan mengapa mengganti sertifikat server tidak mengubah apa pun.

Sertifikat mana yang sebenarnya ditolak pemeriksa

Rantai bukan satu objek yang diulang tiga kali. Sertifikat daun membawa nama dan kunci server, sertifikat perantara menghubungkannya ke akar, dan masing-masing punya masa berlaku, batasan, dan penggunaan sendiri. Saat galat menyebut kedalaman, angka itu menandai posisi dalam rantai yang dibangun pemeriksa, dan itu mungkin bukan posisi yang Anda harapkan jika server mengirim rantai tak terduga.

Bacalah bidang sertifikat pada kedalaman itu, bukan sertifikat yang Anda anggap bersalah. Minta dua ekstensi yang membatasi penerbitan alih-alih membuang setiap bidang, karena jawabannya hampir selalu ada di salah satunya. Keluaran ekstensi aman dibagikan; kunci privat tidak pernah.

openssl x509 -in issuing-ca.pem -noout -subject -issuer -ext basicConstraints -ext extendedKeyUsage

Jika sertifikat yang disebut adalah perantara yang penggunaan kunci diperluasnya menyebut sesuatu yang tidak terkait autentikasi server TLS, sisa kegagalan mengikuti secara mekanis. Rantai tidak dapat dipakai untuk tujuan yang diminta OpenVPN.

Tujuan sertifikat daun dan kebijakan rantai adalah dua pengujian

Pengujian daun mengajukan pertanyaan sempit: apakah sertifikat entitas akhir ini mengizinkan autentikasi server untuk nama ini? Pengujian rantai mengajukan pertanyaan lebih luas: bolehkah setiap sertifikat di jalur melayani tujuan itu? Otoritas sertifikat yang hanya boleh menerbitkan sertifikat klien akan lolos pemeriksaan tanda tangannya sendiri dan tetap gagal pada pengujian kedua, karena jalur yang diizinkannya tidak memuat tujuan yang dibutuhkan aplikasi. Kedua pengujian gagal dengan kata yang sama dan punya perbaikan yang sangat berbeda.

Itulah sebabnya sertifikat daun yang baru diterbitkan, benar di setiap bidang yang terlihat, bisa langsung gagal. Itu juga sebabnya perbaikannya biasanya ada di profil otoritas penerbit, bukan di konfigurasi VPN.

EKU yang tidak ada bukan EKU yang membatasi

RFC 5280 menjadikan ekstensi penggunaan kunci diperluas opsional dan, bila ada, membatasi. Sertifikat CA tanpa ekstensi itu karenanya tidak mengatakan «tidak» pada autentikasi server, sedangkan yang hanya mencantumkan tujuan tak terkait mengatakan sesuatu yang sangat spesifik. Memperlakukan kedua keadaan itu sebagai setara menghasilkan diagnosis yang salah dan, lebih buruk, perbaikan yang salah. Perbedaan ini juga menjelaskan mengapa dua otoritas yang tampak serupa di konsol berperilaku sangat berbeda dalam sebuah rantai.

Perilaku pustaka juga tidak seragam di sini. dokumen OpenSSL tentang opsi verifikasi menjelaskan perlakuan pustaka itu sendiri terhadap pemeriksaan tujuan pada sertifikat CA, dan perlakuan itu adalah kebijakan implementasi, bukan aturan yang diikuti setiap tumpukan TLS secara identik. Jelaskan apa yang dilakukan pemeriksa Anda, lalu pastikan terhadap versi yang benar-benar Anda jalankan.

Reproduksi kegagalan secara offline sebelum menerbitkan ulang

Verifikasi offline mengeluarkan aplikasi dari persamaan. Jika rantai gagal dengan cara yang sama di bawah tujuan yang sama, sertifikatnya yang bermasalah dan tidak ada konfigurasi server yang menyembunyikannya. Jika rantai lolos secara offline sementara layanan tetap menolak, aplikasi meminta tujuan berbeda atau memakai rantai berbeda dari yang Anda uji.

openssl verify -purpose sslserver -show_chain -CAfile root-ca.pem -untrusted issuing-ca.pem vpn-server.pem

-show_chain penting karena mencetak jalur yang dibangun alat, yang sering bukan urutan berkas yang Anda berikan. Keluaran itu cara tercepat menemukan bahwa sertifikat perantara kedua ditarik dari penyimpanan kepercayaan, bahwa server mengirim varian bertanda tangan silang yang tidak Anda maksud, atau bahwa bendera tujuan yang Anda salin dari tutorial milik peran berbeda dari yang dilayani.

Perbaiki kebijakan penerbitan, bukan panggilan verifikasi

Perbaikan yang tahan lama adalah sertifikat perantara yang diterbitkan di bawah kebijakan yang mengizinkan tujuan yang harus dilayaninya, dengan batasan ditulis dan ditinjau. Menambahkan setiap tujuan ke setiap otoritas bukanlah kebijakan; itu menghapus batasan yang membuat ekstensi itu bermakna sejak awal, dan biasanya bertahan lebih lama daripada insiden yang memicunya. Catatan singkat di profil yang menjelaskan peran apa yang boleh disertifikasi otoritas mencegah penerbitan ulang berikutnya mengulang perdebatan yang sama.

Mematikan verifikasi adalah jalan pintas menggiurkan lainnya, dan itu mengubah masalah sertifikat menjadi masalah kepercayaan. Pertahankan pemeriksaan tujuan, perbaiki rantai, dan jalankan lagi verifikasi offline yang sama untuk memastikan jalur kini melayani peran yang dimaksud sebelum menyentuh layanan lagi.