Sertifikat MTA-STS dan kegagalan rantai HTTPS

MTA-STS menggunakan dua koneksi TLS yang berbeda. Seseorang mengambil kebijakan dari host kebijakan HTTPS; yang lain melindungi pengiriman SMTP ke MX yang dipilih. Sertifikat situs web yang valid tidak dapat menetapkan bahwa penerimaan SMTP sudah sesuai, dan sertifikat SMTP yang valid tidak dapat memperbaiki titik akhir kebijakan yang rusak.

Beri nama titik akhir yang gagal terlebih dahulu

Referensi: RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2.

Misalnya example.com , pengambilan kebijakan memvalidasi mta-sts.example.com . Sertifikat harus berisi identitas DNS yang cocok, belum kedaluwarsa, dan berantai ke jangkar kepercayaan yang diterima oleh pengirim MTA. A CNAME tujuan target atau pengalihan tidak secara diam-diam menggantikan nama host kebijakan dalam pemeriksaan ini.

Validasi SMTP memeriksa nama host MX yang dipilih. Konfirmasikan juga bahwa nama host cocok dengan setidaknya satu pola mx kebijakan yang diizinkan. Ini adalah perbandingan yang berbeda: diizinkan oleh kebijakan karakter pengganti tidak membuat sertifikat yang tidak terkait menjadi valid. Pertahankan nama yang dipilih, rantai yang disajikan, waktu verifikasi, dan konteks penyimpanan kepercayaan.

Diagnosis lebih dari kadaluwarsa

Referensi: RFC 8461 §7.1, RFC 6066 §3.

Kegagalan dapat disebabkan oleh daun yang kedaluwarsa, nama host yang tidak cocok, sertifikat perantara yang hilang atau salah, rantai yang tidak tepercaya, atau titik akhir yang menyajikan sertifikat default. Uji dengan Indikasi Nama Server yang disetel ke nama host kebijakan untuk HTTPS dan ke nama host MX untuk SMTP . Sebuah layanan shared hosting bisa menghadirkan rantai yang berbeda-beda tergantung SNI-nya.

Bandingkan pengamatan dari lingkungan pengirim yang terkena dampak jika memungkinkan. Toko kepercayaan yang berbeda atau perangkat lunak klien lama dapat memberikan hasil yang berbeda. Ikon browser berwarna hijau pada satu workstation adalah bukti berguna untuk browser tersebut, bukan janji bahwa semua MTA pengirim menerima rantai yang sama.

Simpan probe yang dapat direproduksi

Referensi alat: Panduan OpenSSL 3.5 s_client. Bantuan OpenSSL 3.5.7 yang terinstal mengonfirmasi opsi ini; tidak ada penyelidikan titik akhir baru yang diklaim.

Untuk host kebijakan resmi, gantikan nama host kebijakan sebenarnya untuk setiap placeholder POLICY_HOST:

openssl s_client -sambungkan POLICY_HOST:443 -nama server POLICY_HOST -verify_hostname POLICY_HOST -verify_return_error -showcerts

Jangan menjalankan placeholder secara harfiah. Sediakan penyimpanan CA tepercaya yang sesuai untuk platform bila diperlukan. Simpan stdout, stderr, versi OpenSSL dan hasil verifikasi. Kemudian ambil URL kebijakan yang tepat dengan klien HTTPS yang memvalidasi, dengan pengalihan berikut dinonaktifkan, dan konfirmasikan HTTP 200 dan badan kebijakan yang dimaksud.

Untuk MX resmi, gantikan nama host MX sebenarnya untuk setiap placeholder MX_HOST:

openssl s_client -starttls smtp -sambungkan MX_HOST:25 -nama server MX_HOST -verify_hostname MX_HOST -verify_return_error -showcerts

Gunakan penyimpanan kepercayaan yang relevan pada kedua pemeriksaan. Referensi: RFC 8461 §4.2 Dan Semantik pemeriksaan nama host OpenSSL. Pemeriksaan nama host OpenSSL yang berhasil saja bukan merupakan bukti kepatuhan MTA-STS : verifikasi nama host umum dapat dikembalikan ke Nama Umum sertifikat ketika SAN yang berlaku tidak ada. RFC 8461 §4.2 secara khusus mengharuskan sertifikat SMTP berisi nama alternatif subjek dengan ID DNS yang cocok. Periksa sertifikat SAN secara terpisah dan konfirmasikan nama host MX yang dipilih cocok dengan entri DNS di sana; tidak menerima pencocokan Nama Umum saja sebagai pemeriksaan identitas SMTP yang diperlukan. Verifikasi juga MX terhadap kebijakan secara independen. Untuk host kebijakan HTTPS, RFC 8461 §3.3 memungkinkan pencocokan hanya terhadap pengidentifikasi DNS-ID dan mengizinkan wildcard hanya sebagai label paling kiri yang lengkap, sedangkan default OpenSSL generik dapat menerima wildcard label parsial; perlakukan kedua probe sebagai diagnostik, bukan validator profil sertifikat MTA-STS yang lengkap. Blok port-25 keluar di lingkungan pengujian adalah batasan konektivitas, bukan bukti bahwa sertifikat jarak jauh rusak. Tidak ada titik akhir produksi yang diperiksa. Pengamatan rantai sertifikat tanggal 7 November 2026 yang disimpan di bawah ini diambil dari layanan loopback dan tidak dijalankan ulang di sini.

Perbaiki rantai tersebut tanpa melemahkan klaim kebijakan

Referensi: RFC 8461 §3.3, RFC 8461 §4.2.

Instal sertifikat dan rantai perantara yang benar pada titik akhir yang terpengaruh melalui alur kerja layanan yang disetujui. Tes ulang nama asli dan semua alamat yang relevan. Jangan gunakan pengambilan tidak aman sebagai hasil verifikasi yang berhasil atau perluas pola MX untuk menyembunyikan ketidakcocokan sertifikat.

Penyegaran yang gagal tidak membuang kebijakan cache yang valid. Pertahankan perbedaan tersebut dalam komunikasi insiden: memperbaiki kebijakan HTTPS mendukung pengambilan di masa mendatang, sedangkan memperbaiki MX yang rusak dapat memulihkan kepatuhan pengiriman bagi pengirim yang menerapkan kebijakan lama. Pantau kedua siklus hidup sertifikat secara independen.

Bukti sejarah yang disimpan dan ruang lingkup yang tersisa

Berikut ini adalah catatan lab yang disimpan pada tanggal 7 November 2026, diperiksa tetapi tidak dijalankan kembali sebagai eksperimen jaringan untuk peninjauan ini. Eksekusi perlengkapan offline baru dicatat secara terpisah.

Pelacakan lokal yang diberi stempel waktu menangkap kegagalan nama host HTTPS dan SMTP . HTTPS menggunakan sertifikat .test wrong.example gagal dengan nama host yang tidak cocok untuk mta-sts.example .test. Sertifikat yang kedaluwarsa gagal dengan sertifikat telah kedaluwarsa. Sertifikat host kebijakan valid yang baru dibuat, lalu memulihkan pengambilan HTTPS. Secara terpisah, layanan SMTP diiklankan STARTTLS dan terlebih dahulu menyelesaikan TLS 1.3 dengan sertifikat lab yang valid; setelah sertifikat yang salah dipasang, verifikasi klien gagal untuk mx.old.example .test. Semua pemeriksaan kepercayaan menggunakan CA lab sekali pakai yang eksplisit dan nama SNI yang diminta. Stempel waktu yang disimpan mengidentifikasi pengamatan. Sertifikat tersebut merupakan materi perlengkapan bersejarah, bukan kredensial atau bukti kesehatan layanan saat ini. Peristiwa pengambilan HTTPS yang berhasil juga mempertahankan sidik jari sertifikat; peristiwa HTTPS dan SMTP yang gagal mempertahankan hasil verifikasi tetapi tidak berisi sidik jari sertifikat sejawat. Hal ini merupakan bukti jabat tangan tersendiri, bukan klaim bahwa penyedia publik mempunyai masalah sertifikat atau bahwa perpanjangan sertifikat publik telah diverifikasi.