SSL Sertifikası Yenilendi Ama E-Posta Bağlantısı Hata Veriyor

SSL sertifikanızı yeniledikten sonra e-posta istemciniz veya sunucunuz bağlantı hatası veriyorsa yalnız değilsiniz. Bu durum, yanlış yapılandırılmış sertifika zincirlerinden kaynaklanan bir protokol sorunudur ve birkaç sistematik adımla tamamen çözülebilir.

Sorunun Kaynağı: Sertifika ≠ Güvenli Bağlantı

Pek çok sistem yöneticisi SSL sertifikasını yeniledikten sonra işin bittiğini varsayar. Oysa e-posta protokolleri — SMTP (RFC 5321), IMAP ve POP3 — TLS anlaşması (handshake) sırasında web tarayıcılarından çok daha katı doğrulama adımları uygular. Tarayıcılar ara sertifikaları bazen AIA (Authority Information Access) uzantısı üzerinden dinamik olarak indirebilirken, e-posta istemcileri ve sunucuları bu esnekliği büyük ölçüde desteklemez.

Sonuç olarak, Let's Encrypt, DigiCert veya Sectigo gibi bir CA'dan aldığınız sertifikayı sunucuya yüklerken yalnızca cert.pem dosyasını kopyaladığınızda istemci tarafında şu hata ailesiyle karşılaşırsınız:

• SSL_CTX_use_certificate_file: no certificate or crl found
• TLS error: no shared cipher
• certificate verify failed (unable to get local issuer certificate)
• 140DB08810F0: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
• Outlook/Thunderbird'de "The server you are connected to is using a security certificate that cannot be verified."

Önce Teşhis: Sertifika Zincirini Kontrol Edin

Sorunun tam kaynağını belirlemek için aşağıdaki araçları sırasıyla kullanın.

1. openssl s_client ile Uzak Test

SMTP (port 587, STARTTLS) için:

openssl s_client -connect mail.siteniz.com:587 -starttls smtp 2>&1 | grep -E 'Verify|depth|error'

IMAPS (port 993) için:

openssl s_client -connect mail.siteniz.com:993 2>&1 | grep -E 'Verify|depth|Cert'

Çıktıda Verify return code: 0 (ok) görmek istiyorsunuz. 21 (unable to verify the first certificate) veya 20 (unable to get local issuer certificate) kodları zincirin eksik olduğuna işaret eder.

2. MX Toolbox veya SSL Labs

Tarayıcı tabanlı araçlardan SSL Labs Mail Server Test (https://www.ssllabs.com/ssltest/) ve MX Toolbox SuperTool, sertifika zincirini, TLS versiyonunu ve cipher suite uyumluluğunu görsel olarak raporlar. Özellikle Google Postmaster Tools ile izlediğiniz alan adlarında bu test skoru, spam filtresi kararlarını doğrudan etkiler.

3. Sunucu Log'larını İnceleyin

Postfix için:

journalctl -u postfix --since "1 hour ago" | grep -i 'tls\|ssl\|cert'

Dovecot için:

grep -i 'ssl\|tls\|cert' /var/log/dovecot.log | tail -50

En Yaygın Senaryo: Eksik Ara Sertifika (Intermediate CA)

Let's Encrypt'in ISRG Root X1 zinciri veya DigiCert'in hiyerarşisi gibi modern CA yapılarında en az bir ara sertifika bulunur. Sunucunuza yalnızca son kullanıcı (leaf) sertifikasını yüklediyseniz, CA kök sertifikasını kendi güven deposunda barındırmayan istemciler bağlantıyı reddeder.

Çözüm: CA'nın size sağladığı fullchain.pem (ya da chain.pem + cert.pem) dosyasını kullanın. Bu dosya, leaf sertifikayı ve tüm ara sertifikaları sıralı biçimde içerir.

Postfix (/etc/postfix/main.cf):

smtpd_tls_cert_file = /etc/letsencrypt/live/siteniz.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/siteniz.com/privkey.pem

Dovecot (/etc/dovecot/conf.d/10-ssl.conf):

ssl_cert = </etc/letsencrypt/live/siteniz.com/fullchain.pem
ssl_key  = </etc/letsencrypt/live/siteniz.com/privkey.pem

Değişiklikten sonra servisleri yeniden yükleyin:

systemctl reload postfix
systemctl reload dovecot

İkinci Senaryo: Eski Sertifika Hâlâ Aktif

Bazı kontrol panelleri (cPanel, Plesk, DirectAdmin) e-posta servisleri için ayrı bir sertifika deposu kullanır. Web sunucusunuzdaki sertifikayı güncellediniz; ancak Postfix ve Dovecot hâlâ eski sertifikayı sunabilir. Şu komutla hangi sertifikanın aktif olduğunu kontrol edin:

openssl x509 -in /etc/postfix/ssl/smtpd.crt -noout -dates

notAfter değeri geçmiş bir tarihe işaret ediyorsa sertifika dosyasını yeni fullchain.pem ile değiştirip servisi yeniden başlatmanız yeterlidir.

Üçüncü Senaryo: SNI Uyumsuzluğu

Tek IP üzerinde birden fazla alan adı barındırıyorsanız ve TLS için SNI (Server Name Indication) kullanıyorsanız, istemcinin gönderdiği sunucu adı ile sertifikadaki CN veya SAN alanı eşleşmeyebilir. Özellikle eski Outlook sürümleri ve bazı kurumsal güvenlik duvarları SNI desteği olmadan bağlantı kurmaya çalıştığında varsayılan sertifika sunulur ve bu sertifika doğru alan adını kapsamıyorsa bağlantı kesilir. Sertifikanızın SAN listesini doğrulayın:

openssl x509 -in fullchain.pem -noout -ext subjectAltName

Dördüncü Senaryo: SPF, DKIM ve DMARC Kaydı Değişmedi ama İmza Doğrulaması Bozuldu

SSL sertifikası yenilemesiyle doğrudan ilgisi olmasa da, bazı yöneticiler bu süreçte sunucu hostname veya IP adresini değiştirdiğinde SPF kaydındaki (RFC 7208) ip4: veya a: mekanizmaları geçersiz hale gelir. DKIM (RFC 6376) özel anahtarı da taşınan sunucularda kaybolabilir. Bu durum, alıcı sunucularda 550 5.7.26 This message does not have authentication information veya DMARC policy of ... disallows (RFC 7489) hatası olarak görünür. Google Workspace ve Microsoft 365 kaynaklı reddedilen iletileri Google Postmaster Tools ve Microsoft SNDS panellerinden takip edebilirsiniz.

Port ve Firewall Kontrolü

SSL yenileme sırasında bazen güvenlik duvarı kuralları da değiştirilir. E-posta için kritik portları şu şekilde kontrol edin:

ss -tlnp | grep -E '25|465|587|993|995'

Hata Kodları ve Anlamları

Adım Adım Kontrol Listesi

1. Sertifika dosyası yolunu doğrulayın — Postfix ve Dovecot yapılandırmalarındaki yollar mevcut ve okunabilir olmalı.
2. fullchain.pem kullandığınızdan emin olun — Yalnızca cert.pem değil, tüm zinciri içeren dosyayı belirtin.
3. Dosya izinlerini kontrol edin — privkey.pem yalnızca root veya ilgili servis kullanıcısı tarafından okunabilir olmalı (chmod 600).
4. Servisleri yeniden yükleyin — reload ile mevcut bağlantılar kesilmeden yeni sertifika aktif hale gelir.
5. openssl s_client ile doğrulayın — Verify return code: 0 (ok) görene kadar adımları tekrarlayın.
6. SPF, DKIM ve DMARC kayıtlarını kontrol edin — DNS değiştiyse kayıtları güncelleyin.
7. E-posta test aracıyla gönderim yapın — mail-tester.com veya mxtoolbox.com üzerinden tam skor alın.

Otomatik Yenileme ve Servis Yeniden Başlatma

Let's Encrypt kullanıyorsanız certbot renew komutu sertifikayı günceller; ancak Postfix ve Dovecot'u otomatik olarak yeniden yüklemez. /etc/letsencrypt/renewal-hooks/deploy/ dizinine aşağıdaki gibi bir betik ekleyin:

#!/bin/bash
systemctl reload postfix
systemctl reload dovecot

Bu betiği çalıştırılabilir yapın: chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh. Böylece sertifika her yenilendiğinde servisler otomatik olarak güncel sertifikayı devreye alır.

Sık Sorulan Sorular