IKEv2 memiliki dua tanda tangan: sertifikat dan IKE_AUTH
CA menandatangani sertifikat, dan peer menandatangani pertukaran IKE_AUTH-nya dengan skemanya sendiri. Baca masing-masing dari bidangnya sendiri, lalu catat keduanya.
Tiket Anda menyatakan sertifikatnya SHA-256 sementara log gateway menyebut algoritme tanda tangan yang berbeda, dan seseorang sudah menyusun permintaan untuk menerbitkan ulang CA. Sebelum permintaan itu pergi ke mana pun, pisahkan kedua tanda tangan: yang satu adalah cap penerbit pada kunci publik, yang lain adalah bukti peer bahwa ia memegang kunci privat yang cocok selama IKE_AUTH. Komponen yang berbeda memilihnya, dan keduanya boleh berbeda. Membaca masing-masing dari tempat tinggalnya membutuhkan dua perintah dan satu tabel.
Baca tanda tangan penerbit dari sertifikat
CA menaruh tanda tangannya pada ikatan antara identitas dan kunci. Tanda tangan itu mencatat apa yang dilakukan CA saat penerbitan, bukan apa yang akan dilakukan subjek saat terhubung, sehingga algoritmenya menggambarkan pilihan hash dan kunci CA sendiri. Kunci subjek satu jenis dapat berada di bawah kunci CA jenis lain tanpa ketidakkonsistenan apa pun, dan rotasi kunci CA adalah rutinitas, bukan kesalahan. Baca kedua bidangnya dan Anda memiliki separuh inventaris:
openssl x509 -in peer.pem -noout -text | grep -E "Signature Algorithm|Public Key Algorithm"Catat kedua label sebagai entri terpisah. Yang pertama menggambarkan CA, yang kedua menggambarkan kunci subjek, dan tidak ada yang memprediksi tanda tangan daring.
Baca tanda tangan daring dari pertukaran IKE
Selama autentikasi setiap peer menandatangani data pertukaran dengan kunci privatnya sendiri, dan sisi lain memeriksa bukti itu terhadap identitas, rantai kepercayaan, dan kebijakan sertifikat. Pada RSA, padding dan hash termasuk dalam skema daring ini, jadi kunci yang lebih panjang atau sertifikat SHA-256 baru tidak dapat dengan sendirinya memilih RSA-PSS untuk tanda tangan autentikasi. Metode yang dinegosiasikan muncul di log daemon atau di daftar koneksinya, tidak pernah di sertifikat. Tanyakan kepada setiap sisi apa yang dinegosiasikannya, karena kedua arah dapat berbeda.
ipsec statusall | grep -i "auth\|proposal"Ketika satu sisi menyebut skema yang tidak dapat dihasilkan sisi lain, Anda telah menemukan ketidakcocokan yang menjadi pokok tiket. Menerbitkan ulang CA adalah perbaikan yang salah untuk itu, karena sertifikat tidak pernah menjadi hal yang gagal.
Apa yang diubah RFC 7427, dan apa yang tidak
Metode asli diberi nomor per kombinasi algoritme dalam RFC 7296. Ekstensi tanda tangan RFC 7427 yang lebih baru menambahkan metode Digital Signature umum dengan pensinyalan dukungan hash tanda tangan, sehingga hash baru tidak lagi memerlukan nomor metode sendiri. Ini dinegosiasikan, bukan diasumsikan: peer tidak memperoleh ekstensi karena pustakanya dapat mengurai sertifikat yang sama, dan peer yang hanya menerapkan metode asli memaksa gateway mempertahankan salah satunya. Itu adalah tukar-menukar kebijakan dengan biaya kompatibilitas, bukan cacat.
Dukungan bersifat per arah dan per koneksi, jadi ujilah build yang ada di depan Anda alih-alih memercayai klaim tingkat keluarga. Matriks kemampuan yang ditulis tiga tahun lalu menggambarkan build berumur tiga tahun.
Masukkan empat baris ke dalam inventaris
Catatan yang mengakhiri perdebatan memiliki empat baris, masing-masing dibaca dari tempat berbeda dan masing-masing diubah oleh orang berbeda. Isilah sebelum memutuskan apa pun, karena baris yang salah itulah yang memilih perbaikannya.
| Objek | Dari mana dibaca | Siapa yang mengubah |
|---|---|---|
| tanda tangan penerbit sertifikat | bidang Signature Algorithm sertifikat | operator CA, saat penerbitan |
| kunci publik subjek | bidang Public Key Algorithm sertifikat | siapa pun yang menghasilkan kunci subjek |
| skema autentikasi IKE | log daemon atau daftar koneksi, notifikasi auth dan signature-hash | profil IKE pada kedua peer |
| algoritme perlindungan IKE dan ESP | daftar proposal koneksi | profil IPsec, per arah |
Setiap baris membawa konsekuensi kompatibilitasnya sendiri. Perubahan cipher ESP tidak memilih tanda tangan penerbit, dan pelonggaran validasi CA tidak menambahkan metode daring yang tidak pernah dinegosiasikan para peer. Ketika tiket mengklaim ketidakcocokan tanda tangan, baris yang benar-benar salah hampir tidak pernah yang pertama.
Selesaikan kasus lama tanpa melemahkan PKI
Peer yang lebih tua mungkin hanya menawarkan skema yang tidak lagi diizinkan kebijakan Anda. Pilihannya adalah pengecualian kompatibilitas berbatas waktu, pembaruan klien, atau pengaturan autentikasi berbeda hanya untuk peer itu. Membangun ulang PKI di sekitar tanda tangan sertifikat yang lebih lemah tidak memperbaiki keterbatasan pada pertukaran daring dan melemahkan setiap layanan lain yang memercayai CA yang sama. Catat baris mana yang Anda ubah dan kapan pengecualian itu berakhir.
Lalu jalankan ulang kedua pembacaan dari atas, karena perubahan pada satu baris dapat menggeser apa yang dinegosiasikan di baris lain. Seluruh inventaris adalah dua perintah dan satu tabel, dan pekerjaannya sama apakah peer itu router, laptop, atau perangkat.