SMTP’de TLS (STARTTLS) neden önemlidir?
Kurumsal e-posta trafiği, çoğu zaman birden fazla sunucu arasında aktarılır: gönderen MTA’dan (mail transfer agent) alıcı MTA’ya, bazen de aradaki gateway’ler üzerinden. Bu aktarım sırasında bağlantının şifrelenmesi, mesaj içeriğinin ağ üzerinde düz metin olarak taşınmasını önlemek için kritik bir güvenlik katmanıdır. SMTP dünyasında bu şifreleme çoğunlukla STARTTLS ile sağlanır. STARTTLS, bağlantıyı düz SMTP ile başlatıp ardından TLS’e yükseltir.
Ancak TLS’in var olması tek başına yeterli değildir. Sertifikanın doğru host adıyla eşleşmesi, tam sertifika zincirinin (certificate chain) sunulması, eski protokollerin kapatılması ve bazı durumlarda SNI (Server Name Indication) gibi mekanizmaların doğru çalışması gerekir. Aksi halde bazı alıcı sunucular TLS’i reddeder, bazıları şifrelemeyi atlar ve bazı ortamlarda teslimat gecikmeleri veya “deferred” gibi kuyruklanma sorunları görülebilir.
SMTP TLS nasıl çalışır: SMTPS değil, STARTTLS
Pratikte iki kavram karıştırılır: “SMTPS” ve “SMTP + STARTTLS”. Günümüzde sunucudan sunucuya e-posta aktarımında yaygın olan model, TCP/25 üzerinden SMTP konuşup STARTTLS ile şifrelemeye geçmektir. İstemciden (kullanıcı uygulaması) sunucuya gönderimde ise genellikle TCP/587 (SMTP Submission) ve TLS kullanılır; bazı senaryolarda TCP/465 (implicit TLS) de görülebilir.
Bu ayrım teşhis için önemlidir çünkü aynı sertifika farklı portlarda farklı davranışlara yol açabilir. Örneğin 25’te sunulan sertifika ile 587’de sunulan sertifika aynı olabilir, ama ayrı servisler veya farklı sanal host tanımları nedeniyle farklı sertifika zinciri gönderiliyor olabilir.
Sertifika doğrulamasında alıcı sunucular neye bakar?
1) Hostname eşleşmesi (CN/SAN)
Alıcı sistem, TLS oturumu kurulurken sertifikanın konu adının (Common Name) veya daha doğrusu SAN (Subject Alternative Name) alanlarının, bağlandığı host adıyla uyumlu olmasını bekler. SMTP’de bu “hangi isme bağlanıyorum?” sorusu çoğu zaman MX kaydındaki hedef üzerinden şekillenir. Yani alıcı, MX kaydınızda yazan host adına bağlanır ve TLS sertifikanızın o host adını kapsamasını bekler.
Yaygın hata: MX kaydınız mail.example.com gösterirken sertifikanız yalnızca example.com veya web.example.com için alınmıştır. Bu durumda bazı alıcılar “certificate mismatch” veya “hostname verification failed” benzeri hatalar üretebilir.
2) Sertifika zinciri (Intermediate CA) eksik mi?
Sunucunuz yalnızca leaf (sunucu) sertifikasını gönderiyor, ama ara sertifikaları (intermediate) göndermiyorsa bazı alıcılar zinciri tamamlayamaz. Bazı sistemlerde istemci tarafında ara sertifika önbelleği olduğundan sorun “bazı alıcılarda var, bazılarında yok” şeklinde kendini gösterebilir. Bu da teşhisi zorlaştırır.
Doğru yaklaşım, sunucunun “full chain” (leaf + intermediate) sunacak şekilde yapılandırılmasıdır. Root sertifika genellikle gönderilmez; alıcılar root’u zaten güven deposunda tutar.
3) Geçerlilik, zaman ve algoritmalar
Sertifikanın süresi dolmuşsa, henüz geçerli değilse (saat farkı), çok zayıf anahtar kullanıyorsa veya artık kabul görmeyen algoritmalar içeriyorsa TLS el sıkışması (handshake) başarısız olabilir. Bu tür sorunlar, e-postanın tamamen durmasına yol açmasa bile bazı alıcıların TLS’i zorunlu kabul ettiği ortamlarda teslimatı engelleyebilir.
SNI nedir ve SMTP’de neden karşınıza çıkar?
SNI (Server Name Indication), bir IP üzerinde birden fazla TLS sertifikası barındıran sunucularda, istemcinin “hangi alan adı için bağlandığını” TLS el sıkışmasının başında söylemesini sağlar. Web’de çok yaygındır; SMTP’de de giderek daha sık görülür.
SNI’nin kritik olduğu senaryolar:
- Bir IP üzerinde birden fazla mail domaini veya birden fazla TLS sertifikası barındırıyorsanız
- Reverse proxy veya mail gateway arkasında sanal host mantığıyla TLS sonlandırıyorsanız
- Aynı sunucuda hem web hem mail servisleri var ve yapılandırmalar karışmışsa
SNI düzgün çalışmadığında sunucu, istemciye “varsayılan” sertifikayı sunabilir. Bu sertifika yanlış alan adını kapsıyorsa, alıcı taraf “mismatch” görür. Bazı alıcılar bu durumda TLS’i bırakıp düz SMTP ile devam edebilir, bazıları ise politikaları gereği bağlantıyı kesebilir.
En sık görülen SMTP TLS sertifika hataları ve anlamları
“Certificate mismatch” / “Hostname verification failed”
Genellikle sertifika, alıcının bağlandığı MX host adını SAN içinde içermiyordur. Çözüm çoğu zaman, MX’in işaret ettiği FQDN için uygun sertifika almak veya MX hedefini sertifikanın kapsadığı host adına taşımaktır.
“Unable to get local issuer certificate” / “Unknown CA”
Çoğu zaman intermediate zinciri eksiktir veya yanlış sırada sunuluyordur. Sunucu sertifikasını “full chain” dosyasıyla sunmak ve doğru chain’i yüklemek gerekir.
“Handshake failure” / “No shared cipher”
Taraflar ortak şifre takımı (cipher) veya TLS sürümü üzerinde anlaşamıyordur. Eski TLS sürümlerini kapatmak doğru bir güvenlik yaklaşımıdır, ancak çok katı ayarlar bazı eski sistemlerle uyumsuzluk yaratabilir. Burada amaç, makul bir güvenlik seviyesiyle geniş uyumluluğu dengelemektir.
“Certificate expired”
Sertifika süresi dolmuştur. Mail sunucularında bu hata bazen gözden kaçar çünkü web tarayıcısı gibi “anında görünür” bir işaret yoktur. Takvim hatırlatmaları, izleme ve düzenli kontrol kritik önemdedir.
Teşhis yaklaşımı: adım adım kontrol listesi
1) MX hedefini ve gerçek bağlanılan host adını netleştirin
Önce domaininizin MX kayıtlarının hangi FQDN’e işaret ettiğini belirleyin. Ardından alıcıların bağlanacağı host adı budur varsayımıyla sertifikanızın SAN alanlarını kontrol edin. Eğer bir load balancer veya gateway kullanıyorsanız, TLS’in nerede sonlandığını da netleştirin.
2) Sertifika zincirinin tam sunulduğunu doğrulayın
Sunucunuzun leaf sertifikayla birlikte intermediate sertifikaları gönderdiğini doğrulayın. “Bazı alıcılar sorun yaşıyor” durumlarının önemli bir kısmı chain kaynaklıdır.
3) Aynı IP’de birden fazla sertifika varsa SNI davranışını test edin
SNI olmayan istemciler hangi sertifikayı görüyor, SNI olanlar hangi sertifikayı görüyor sorusunu yanıtlayın. Yanlış “default certificate” sunulması, özellikle çoklu domain barındıran yapılarda yaygındır.
4) Geçerlilik süresi, anahtar uzunluğu ve imza algoritmasını kontrol edin
Sertifikanın süresi, RSA/ECDSA anahtar parametreleri ve kullanılan imza algoritması modern alıcılarla uyumlu olmalıdır. Ayrıca sunucu saati ve zaman senkronizasyonu doğru olmalıdır.
Düzeltme stratejileri: kalıcı çözüm için öneriler
MX ve sertifika adını uyumlu tasarlayın
En pratik tasarım, MX hedefini mail.example.com gibi net bir isimde sabitlemek ve sertifikayı bu isim için almak/yenilemektir. Eğer birden fazla isim kullanmanız gerekiyorsa (ör. mail.example.com ve mx.example.com), sertifikaya SAN olarak ekleyin.
Full chain kullanın ve yapılandırmayı standartlaştırın
Birçok mail servisi sertifika dosyalarını ayrı ayrı ister: private key, leaf cert ve chain. Yanlış dosyayı yanlış alana koymak sık yapılan hatadır. Yapılandırmayı belgelendirin, değişiklikleri kontrollü uygulayın.
Sertifika yenilemelerini operasyonel bir sürece bağlayın
“Sertifika süresi doldu” problemleri teknik değil operasyonel bir eksikliktir. Sorumluluk atayın, yenileme takvimi belirleyin, değişiklikten sonra dışarıdan doğrulama yapın. Sertifika yenilemesi sadece dosyayı güncellemek değil, servislerin yeniden yüklenmesi ve doğru sertifikanın sunulduğunun test edilmesi anlamına gelir.
Teslimat ve güvenlik açısından beklentiyi doğru yönetin
STARTTLS birçok ortamda “opportunistic” çalışır: iki taraf destekliyorsa şifreli olur, desteklemiyorsa düz devam edebilir. Bu yüzden TLS’i doğru yapılandırmak, hem gizlilik hem de kurumsal itibar açısından önemlidir. Öte yandan her alıcının aynı politikayı uygulamadığını bilmek gerekir; bazı kurumlar TLS’i zorunlu kılar, bazıları ise sadece tercih eder. Bu da “bazı yerlere gidiyor, bazılarına gitmiyor” şikayetlerinde TLS sertifika hatalarını olası kök nedenler arasına sokar.
Son kontrol: değişiklikten sonra neyi doğrulamalısınız?
- MX hedefinizin doğru hosta işaret ettiğini
- Sunulan sertifikanın SAN içinde MX host adını içerdiğini
- Intermediate zincirin eksiksiz gönderildiğini
- 25/587 gibi ilgili portlarda aynı doğrulamanın geçtiğini
- SNI senaryolarında doğru sertifikanın seçildiğini
- Yenileme sonrası servislerin doğru şekilde yeniden yüklendiğini
MX1Mail gibi yönetilen iş e-posta platformlarında TLS ve sertifika tarafındaki doğru kurgu, e-posta akışının daha sorunsuz çalışmasına yardımcı olur. Yine de domaininizin MX hedefleri ve DNS değişiklikleri gibi alanlar sizin yönetiminizde olduğundan, sertifika-hostname uyumunu ve değişiklik sonrası kontrolleri operasyonel rutininize dahil etmek uzun vadede en az sorun çıkaran yaklaşımdır.