Jadikan pembaruan sebagai tugas kesinambungan layanan
Memperbarui sertifikat HTTPS untuk MTA-STS host kebijakan selesai hanya ketika sertifikat yang benar benar-benar disajikan pada titik akhir yang diperlukan dan klien yang memvalidasi dapat mengambil kebijakan tersebut. Pemberitahuan penerbitan yang berhasil tidak menentukan penerapan, kelengkapan atau ketersediaan rantai kepercayaan. Atur pekerjaan berdasarkan layanan yang sedang berjalan, bukan urutan sertifikat.
Panduan ini mengusulkan kontrol pembaruan dan tinjauan kegagalan fiktif. Itu tidak menerbitkan sertifikat, memeriksa kunci pribadi, memodifikasi hosting atau terhubung ke domain pelanggan. Sertifikat asli dan observasi HTTP masih diperlukan. Pemilik harus menyetujui prosedur penerapan dan pengembalian yang disetujui sebelum operator menyentuh layanan tersebut.
Inventarisasi kedua permukaan sertifikat
Sertifikat host kebijakan mengautentikasi nama seperti mta-sts.example.com selama pengambilan HTTPS. Server SMTP penerima memberikan sertifikat terpisah untuk nama host MX -nya. Layanan tersebut dapat memiliki pemilik, sistem perpanjangan, dan tanggal kedaluwarsa yang berbeda. Memperbarui yang satu tidak memperbaiki yang lain, meskipun keduanya dikelola oleh penyedia hosting yang sama. RFC 8461 bagian 3.3 dan 4.2
Catat nama host kebijakan, tim yang bertanggung jawab, platform penerapan, sidik jari sertifikat publik saat ini, interval validitas, dan mekanisme pembaruan yang dimaksudkan. Sertakan setiap alamat atau tingkat layanan yang dapat menjawab titik akhir. NotBefore dan notAfter sertifikat membatasi masa berlakunya, sedangkan validasi jalur juga bergantung pada batasan dan kepercayaan sertifikat lainnya. Tampaknya tanggal kedaluwarsa di masa depan saja bukanlah hasil validasi yang berhasil. RFC 5280 bagian 4.1.2.5 dan 6
Verifikasi identitas dan rantai sebelum penerapan
Host kebijakan harus menunjukkan sertifikat yang belum kedaluwarsa dan valid untuk identitas DNS yang diperlukan dan dirantai ke akar yang dipercaya oleh pengirim MTA. Mendelegasikan hosting melalui a CNAME tidak membuat sertifikat untuk nama host penyedia cukup. Pertahankan nama host kebijakan asli dalam pengujian validasi dan dokumentasikan rantai publik mana yang diharapkan dikirimkan oleh server. RFC 8461 bagian 3.3 dan 8.2
Gunakan nama alternatif subjek sertifikat saat menilai identitas layanan yang dimaksud. RFC 9525 adalah spesifikasi identitas layanan umum saat ini dan RFC 6125 yang sudah usang, yang dikutip RFC 8461 . Jaga agar aturan ID DNS khusus aplikasi MTA-STS tetap eksplisit daripada secara diam-diam mengganti perilaku aplikasi yang tidak terkait. Nama umum yang dapat dibaca manusia bukanlah alasan untuk mengesampingkan ketidakcocokan nama host. RFC 9525 bagian 2 dan 6
Rencanakan waktu yang cukup untuk pulih dengan aman
Pilih tenggat waktu perpanjangan internal yang menyisakan waktu untuk kegagalan penerbitan, kesalahan penerapan, dan verifikasi. Margin yang sesuai bergantung pada masa pakai sertifikat dan kepemilikan operasional; tidak ada jumlah hari universal yang ditetapkan di sini. Tetapkan orang yang bertanggung jawab dan kontak cadangan. Pekerjaan terjadwal tanpa tujuan pemberitahuan atau pemilik merupakan ketergantungan yang belum terverifikasi, bukan proses pembaruan yang lengkap.
Jaga penanganan sertifikat di dalam sistem manajemen rahasia yang disetujui. Paket bukti harus berisi rincian sertifikat publik dan keluaran validasi, bukan kunci pribadi atau kredensial akun. Tentukan apa yang dapat dibatalkan oleh operator, bagaimana validitas saat ini akan diperiksa dan kegagalan mana yang memerlukan eskalasi. Memulihkan sertifikat yang kedaluwarsa karena merupakan konfigurasi yang diketahui kemarin bukanlah rencana pemulihan yang berguna.
Uji titik akhir yang disebarkan, bukan file sertifikat
Setelah penerapan resmi, pemeriksaan yang diusulkan harus mengidentifikasi nama host, alamat, waktu UTC, rantai yang diamati, hasil validasi nama, dan hasil kepercayaan yang tepat. Jika terdapat beberapa node penyajian, pertahankan cakupan yang benar-benar dicentang. Tes lokal yang sukses dari operator tidak dapat membuktikan bahwa setiap pengirim eksternal memercayai root yang sama atau mencapai node yang sama. Catat batasan tersebut alih-alih mengubah satu observasi menjadi kesiapan universal.
Kemudian verifikasi URL asli terkenal menghasilkan HTTP 200 langsung dengan kebijakan yang dimaksudkan. Pekerjaan sertifikat dapat secara tidak sengaja mengubah pemilihan host virtual, perutean, atau kontrol akses aplikasi. MTA-STS melarang pengalihan HTTP selama pengambilan, sehingga keberhasilan browser setelah pengalihan tidak memadai. Koneksi TLS yang valid dan respons HTTP yang dapat digunakan merupakan ketentuan penerimaan yang berbeda. RFC 8461 bagian 3.2–3.3
Periksa penerapan parsial fiktif
Pertimbangkan example.com fiksi, yang nama host kebijakannya dilayani oleh dua node tepi. Sistem pembaruan memperoleh sertifikat baru, tetapi hanya satu node yang memuat ulang sertifikat tersebut. Yang lainnya terus menyajikan sertifikat yang sudah kadaluwarsa. Tes yang mencapai node yang diperbarui berhasil; pengirim yang mencapai node kedua tidak dapat mengautentikasi kebijakan tersebut. Pengamatan ini dibuat-buat dan tidak menunjukkan perilaku penyedia yang sebenarnya.
Investigasi yang diusulkan membandingkan sidik jari publik dan interval validitas pada node yang melayani, diikuti dengan pengambilan yang diautentikasi pada nama host yang tidak diubah. Ini tidak dimulai dengan melonggarkan pemeriksaan sertifikat atau menghapus catatan penemuan. Pemilik remediasi akan menyelesaikan penerapan yang disetujui dan memverifikasi kedua node. Sertifikat SMTP MX masih memerlukan validasinya sendiri karena perbaikan host kebijakan tidak menjelaskan apa pun tentang statusnya.
Pahami batas cache selama pemadaman
Pengirim pendukung dengan kebijakan cache yang valid dan belum kedaluwarsa harus terus menggunakannya jika kebijakan aktif tidak dapat diambil. Pengirim tanpa kebijakan tersebut terus berlanjut seolah-olah MTA-STS tidak ada setelah kegagalan pengambilan. Oleh karena itu, masa pakai cache memberikan manfaat kontinuitas terbatas bagi beberapa pengirim, bukan izin untuk membiarkan sertifikat HTTPS kedaluwarsa. Pengirim yang berbeda dapat secara sah menempati negara bagian yang berbeda selama pemadaman yang sama. RFC 8461 bagian 3.3
ID penemuan mengidentifikasi contoh kebijakan, bukan nomor seri sertifikat. Jika hanya sertifikat yang berubah dan badan kebijakan tetap sama, jangan berasumsi bahwa ID baru diperlukan agar perpanjangan menjadi efektif. Jika kebijakannya juga berubah, ikuti perintah pembaruan isi sebelum ID dan pertimbangkan kebijakan yang di-cache. Pertahankan penerapan sertifikat dan revisi kebijakan sebagai perubahan yang dapat ditinjau secara terpisah. RFC 8461 bagian 3.1 dan 8.1
Simpan bukti untuk pembaruan berikutnya
Simpan catatan penerapan yang disetujui, detail sertifikat publik sebelum dan sesudah, hasil pengambilan yang diautentikasi, dan segala hal yang relevan TLS-RPT pengamatan. Kegagalan PKI Web kebijakan termasuk dalam penyelidikan titik akhir kebijakan; kedaluwarsa sertifikat SMTP yang dilaporkan berkaitan dengan koneksi penerima. Periksa kategori mana yang sebenarnya dilaporkan. RFC 8460 bagian 4.3
Daftar kesalahan RFC 8461 saat ini mencakup koreksi kapitalisasi yang dilaporkan tentang sertifikat MTA penerima yang kedaluwarsa; itu tidak mengizinkan sertifikat kedaluwarsa. Tidak ada bukti perpanjangan atau hosting asli yang diberikan di sini. Gerbang operasional terakhir tetap berupa demonstrasi layanan yang dikerahkan dengan stempel waktu, ditinjau oleh pemiliknya. RFC 8461 kesalahan