Kesalahan sertifikat web Access Server: bundel CA kosong

Halaman masuk web yang tidak mau dimuat padahal DNS terurai dengan benar biasanya bukan masalah DNS. Jika log layanan menyebut jalur bundel sertifikat kosong atau kegagalan penguraian PEM untuk sertifikat web dan kunci privat, pendengar HTTPS tidak punya materi yang bisa dipakai dan resolusi nama tidak akan menolong. Perbaikannya ada pada tiga kunci konfigurasi dan tidak menuntut penerbitan ulang satu pun sertifikat klien VPN.

Ke mana tiga kunci itu sebenarnya menunjuk

Set sertifikat web khusus dijelaskan oleh cs.cert, cs.priv_key, dan cs.ca_bundle. Masing-masing menyimpan jalur ke berkas, dan ketiganya dipakai bersama oleh layanan web. Sertifikat dengan kunci yang salah, atau berkas rantai yang sebenarnya sertifikat daun, gagal seperti nilai kosong: pendengar tidak dapat membangun rantai yang diterima peramban.

Kunci ini milik antarmuka web Admin dan Client. Ketiganya terpisah dari PKI yang menerbitkan sertifikat bagi klien VPN, jadi penggantiannya tidak perlu menyentuh profil klien, kunci server, atau otoritas sertifikat. Menganggap gangguan TLS web sebagai alasan membangun ulang seluruh PKI adalah langkah salah termahal di sini.

Satu perbedaan menghemat waktu: nilai khusus yang kosong secara eksplisit bukan keadaan yang sama dengan tanpa penimpaan. Yang pertama memberi pengurai jalur kosong, itulah yang dikatakan baris log. Yang kedua membiarkan Access Server pada materinya sendiri, karena itu sebagian host normal setelah pemutakhiran dan sebagian tidak.

Mengapa berkas yang ada tetap gagal diurai

Pengurai membaca blok berlabel di dalam berkas, bukan nama berkas. .crt yang memuat kunci privat, rantai yang ditulis sebagai satu blok gabungan di tempat yang diharapkan satu sertifikat, atau berkas dengan baris terakhir terpotong semuanya ditolak. RFC 7468 mendefinisikan label terbaca itu karena hanya itu yang memberi tahu pembaca jenis objek berikutnya.

Periksa objeknya, bukan ekstensinya. Di host Linux, openssl x509 -noout -subject -issuer -in server.pem dan openssl pkey -noout -check -in key.pem menjawab dua pertanyaan penting, dan membandingkan modulus atau kunci publik keduanya membuktikan keduanya berpasangan. Jauhkan keluaran kunci privat dari tiket dan log obrolan; pemeriksaan perlu sidik jari, bukan kuncinya.

Jalur kosong sama mencurigakannya dengan berkas rusak, karena keduanya menghasilkan galat lanjutan yang kabur. Jika log menyebut jalur bundel kosong, baca nilai tersimpan sebelum menelusuri berkasnya.

Kembali ke cadangan secara sengaja

CLI Access Server memuat pemeriksaan validasi yang mengambil tiga jalur sebagai argumen dan melaporkan apakah set itu bisa dipakai. Jalur di bawah hanyalah contoh; ganti dengan lokasi terlindungi di host:

sacli --ca_bundle=/secure/webcerts/chain.pem \
      --cert=/secure/webcerts/server.pem \
      --priv_key=/secure/webcerts/key.pem TestWebCerts

Baca hasilnya sebelum menyentuh layanan yang berjalan, lalu impor nilainya dan terapkan lewat operasi terdokumentasi untuk versi terpasang. tutorial CLI resmi mencakup validasi, impor ke basis data konfigurasi, dan langkah penerapan, dan versinya lebih penting daripada ringkasan apa pun.

Verifikasi nama yang benar-benar diketik pengguna

Bila materi khusus rusak dan cadangan bawaan yang sah masih ada, pemulihan terdokumentasi adalah menghapus tiga penimpaan khusus dan membiarkan Access Server memakai cadangan itu. Siapkan akses konsol dan salinan konfigurasi saat ini lebih dulu, karena layanan yang akan dimulai ulang itulah yang melayani antarmuka administrasi.

sacli ConfigDel --key "cs.cert"
sacli ConfigDel --key "cs.priv_key"
sacli ConfigDel --key "cs.ca_bundle"
# then the supported apply/restart step for this version

Menghapus seluruh basis data konfigurasi bukan perbaikan sertifikat. Sasaran ketiga kunci itu, terapkan, dan pastikan antarmuka web menjawab. Berkas bertanda tangan sendiri di direktori web-ssl adalah sumber daya cadangan, bukan ruang kerja: menimpanya atau membuatnya ulang dapat menghapus satu-satunya materi yang bekerja.

Perkirakan peramban menampilkan sertifikat berbeda setelah cadangan berlaku. Itu hasil yang benar, dan jawabannya adalah memverifikasinya lewat proses administrasi tepercaya, bukan mengajari pengguna melewati setiap peringatan.

Pemulihan baru selesai setelah masuk berhasil

Pemulihan belum selesai saat pendengar TCP muncul. Validasi nama DNS, identitas sertifikat, dan rantai untuk nama itu, lalu muat antarmuka web Admin dan Client dan selesaikan proses masuk. Pemeriksaan port tidak membuktikan satu pun dari itu.

Access Server 3.1 dan setelahnya juga dapat melayani sertifikat web berbeda per nama host SNI. Bila itu dikonfigurasi, kunci bawaan dan entri khusus nama adalah set terpisah, dan pengujian lewat alamat IP mudah menampilkan sertifikat berbeda dari yang diterima pengguna. Perbaiki dan validasi set untuk nama yang gagal, lalu ulangi uji masuk sebelum menutup insiden.