TLS Sertifika Hatası: Mail Sunucusunda SSL Sorunlarını Çözme

Bykomut

Mail sunucunuzda bir sabah aniden e-postalar gönderilemiyor, alınamıyor ve log dosyaları SSL/TLS hataları ile dolup taşıyor. Bu senaryo her sistem yöneticisinin kâbusu ve maalesef oldukça sık karşılaşılan bir durum. TLS sertifika sorunları mail sunucularında sessiz sedasız çıkabilir ya da tam tersi, sistemi tamamen çökertebilir. Bu yazıda Postfix, Dovecot ve diğer mail bileşenlerinde karşılaşılan SSL/TLS hatalarını nasıl tespit edeceğinizi ve çözeceğinizi adım adım ele alacağız.

TLS Hatalarını Anlamak: Temel Kavramlar

Mail sunucuları SSL/TLS’i birden fazla bağlantı noktasında kullanır. SMTP için 25 (STARTTLS), 465 (SSL/TLS) ve 587 (STARTTLS submission), IMAP için 143 (STARTTLS) ve 993 (SSL/TLS), POP3 için ise 110 (STARTTLS) ve 995 (SSL/TLS) portları kullanılır. Bu kadar çok noktada TLS devreye girdiği için sorunun kaynağını bulmak bazen karmaşıklaşabiliyor.

TLS hatalarının en yaygın sebepleri şunlardır:

  • Süresi dolmuş sertifika: En klasik senaryo, Let’s Encrypt veya ticari sertifika yenileme sürecinin atlanması
  • Yanlış sertifika zinciri: Ara CA sertifikalarının eksik olması
  • SNI yapılandırma hatası: Birden fazla domain barındıran sunucularda yanlış sertifika sunulması
  • İzin sorunları: Sertifika dosyalarına servis kullanıcısının erişememesi
  • Uyumsuz TLS versiyonları: İstemci-sunucu TLS versiyon uyuşmazlığı
  • Cipher suite çakışmaları: Desteklenmeyen şifreleme algoritmalarının talep edilmesi

İlk Adım: Log Dosyalarına Bakmak

Herhangi bir araç çalıştırmadan önce log dosyalarını incelemek, sorunun ne olduğuna dair en hızlı ipucunu verir. Postfix logları genellikle /var/log/mail.log veya /var/log/maillog konumundadır.

# Postfix TLS hatalarını filtrele
grep -i "tls|ssl|certificate|handshake" /var/log/mail.log | tail -50

# Sadece hataları göster
grep -i "error|warn|fatal" /var/log/mail.log | grep -i "tls|ssl" | tail -30

# Gerçek zamanlı takip
tail -f /var/log/mail.log | grep -i "tls|ssl|cert"

Tipik bir süresi dolmuş sertifika hatası log’da şöyle görünür:

postfix/smtpd[12345]: SSL_accept error from mail.example.com: -1
postfix/smtpd[12345]: warning: TLS library problem: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired

Dovecot için log konumu genellikle aynı dosya veya /var/log/dovecot.log olur:

# Dovecot TLS hatalarını filtrele
grep -i "ssl|tls|cert" /var/log/dovecot.log | tail -30

# Systemd journal ile dovecot loglarına bak
journalctl -u dovecot --since "1 hour ago" | grep -i "ssl|tls"

Sertifika Durumunu Kontrol Etme

Log’larda TLS hatası gördükten sonra ilk kontrol noktası sertifikanın kendisi. OpenSSL ile sertifikayı doğrudan analiz edebilirsiniz.

# Sertifika dosyasını doğrudan incele
openssl x509 -in /etc/ssl/certs/mail.example.com.crt -text -noout | grep -A 2 "Validity"

# Sertifikanın kaç gün geçerli olduğunu göster
openssl x509 -in /etc/ssl/certs/mail.example.com.crt -checkend 86400 -noout
# Çıktı: "Certificate will not expire" veya "Certificate has expired"

# Sertifika zincirini kontrol et
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/mail.example.com.crt

Uzak sunucuya bağlanarak sertifikayı doğrudan test etmek çok daha gerçekçi sonuçlar verir:

# SMTP STARTTLS ile sertifika kontrolü
openssl s_client -connect mail.example.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates

# IMAPS doğrudan SSL bağlantısı
openssl s_client -connect mail.example.com:993 2>/dev/null | openssl x509 -noout -subject -dates

# SMTPS (465) kontrolü
openssl s_client -connect mail.example.com:465 2>/dev/null | openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not Before:|Not After:"

Bu komutların çıktısında Not After tarihine dikkat edin. Eğer bu tarih geçmişse sertifika yenilenmesi gerekiyor demektir.

Gerçek Dünya Senaryosu: Let’s Encrypt Otomatik Yenileme Çalışmıyor

Şirketteki mail sunucusunda bir Pazartesi sabahı tüm dış bağlantılar kesildi. Log’lara bakıldığında sertifikanın 3 gün önce expire olduğu görüldü. Certbot cron job çalışıyordu ama sertifika yenilenmemişti. Sorunun kökü şuydu: Certbot sertifikayı yenilemiş ama Postfix ve Dovecot yeni sertifikayı okuyacak şekilde yeniden başlatılmamıştı.

# Certbot sertifika durumunu kontrol et
certbot certificates

# Son yenileme denemelerini gör
grep "certbot" /var/log/syslog | tail -20

# Manuel olarak yenile ve servisleri yeniden başlat
certbot renew --force-renewal
systemctl reload postfix
systemctl reload dovecot

Let’s Encrypt kullanıyorsanız, deploy hook mekanizması bu sorunu kalıcı olarak çözer:

# Deploy hook dosyası oluştur
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh << 'EOF'
#!/bin/bash
systemctl reload postfix
systemctl reload dovecot
echo "Mail servisleri $(date) tarihinde yeniden yüklendi" >> /var/log/certbot-deploy.log
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh

Bu hook sayesinde certbot her başarılı yenileme sonrasında otomatik olarak servisleri yeniden yükleyecektir.

Postfix TLS Yapılandırmasını Doğrulama

Sertifika geçerliyse ama hata devam ediyorsa Postfix yapılandırmasında sorun olabilir. /etc/postfix/main.cf dosyasındaki TLS ayarlarını gözden geçirin.

# Mevcut TLS yapılandırmasını göster
postconf -n | grep -i "tls|ssl|cert|key"

Sağlıklı bir Postfix TLS yapılandırması şu şekilde görünmelidir:

# /etc/postfix/main.cf - TLS için kritik parametreler

# SMTP istemci TLS ayarları (giden mail)
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# SMTP sunucu TLS ayarları (gelen mail)
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_ciphers = high

Yapılandırmayı değiştirdikten sonra sözdizimini doğrulamayı unutmayın:

# Postfix yapılandırmasını test et
postfix check

# Uyarı: Bu komut yapılandırma hatalarını gösterir
postfix -e check

# Yapılandırmayı uygula
systemctl reload postfix

Sertifika Zinciri Sorunları

Bu, en sinsi TLS sorunlarından biridir. Sertifikanızın süresi dolmamış olabilir, ama ara CA sertifikaları eksikse bazı istemciler bağlantıyı reddeder. Özellikle kurumsal e-posta istemcileri ve katı güvenlik politikalarına sahip mail sunucuları bu konuda hassastır.

# Sertifika zincirini test et
openssl s_client -connect mail.example.com:993 -showcerts 2>/dev/null

# Zincirin tam olup olmadığını kontrol et
openssl s_client -connect mail.example.com:25 -starttls smtp 2>&1 | grep -E "Verify return|depth|subject"

Eğer çıktıda Verify return code: 21 (unable to verify the first certificate) veya benzeri bir hata görüyorsanız, ara sertifika zincirinde sorun var demektir.

Let’s Encrypt kullanıyorsanız cert.pem yerine fullchain.pem kullandığınızdan emin olun. Fullchain.pem hem domain sertifikanızı hem de ara CA sertifikalarını içerir:

# Postfix'te fullchain kullanımını zorla
postconf -e "smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem"

# Sertifika zincirindeki sertifika sayısını kontrol et
openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/mail.example.com/fullchain.pem | openssl pkcs7 -print_certs -noout | grep "subject"

Çıktıda en az iki satır görmelisiniz: domain sertifikanız ve Let’s Encrypt ara CA sertifikası.

Dovecot SSL Yapılandırması

Dovecot’ta SSL sorunları genellikle /etc/dovecot/conf.d/10-ssl.conf dosyasındaki yanlış ayarlardan kaynaklanır.

# Dovecot SSL yapılandırmasını kontrol et
cat /etc/dovecot/conf.d/10-ssl.conf | grep -v "^#|^$"

# Dovecot'un sertifika dosyasına erişip erişemediğini test et
sudo -u dovecot openssl x509 -in /etc/letsencrypt/live/mail.example.com/fullchain.pem -noout -subject 2>&1

Yaygın bir sorun, dovecot kullanıcısının Let’s Encrypt sertifika dizinine erişememesidir. Let’s Encrypt sertifikaları /etc/letsencrypt/live/ altında symlink olarak bulunur ve gerçek dosyalar /etc/letsencrypt/archive/ dizinindedir. Her iki dizine de erişim gerekir:

# İzin sorununu kontrol et
ls -la /etc/letsencrypt/live/mail.example.com/
ls -la /etc/letsencrypt/archive/mail.example.com/

# Dovecot kullanıcısına okuma izni ver
chmod 750 /etc/letsencrypt/{live,archive}
chown root:dovecot /etc/letsencrypt/{live,archive}
chmod 640 /etc/letsencrypt/archive/mail.example.com/*.pem

# Dovecot yapılandırmasını test et
dovecot -n | grep ssl
doveconf -n | grep ssl

TLS Versiyon ve Cipher Uyumsuzlukları

Eski istemciler veya kötü yapılandırılmış mail sunucuları zaman zaman TLS 1.0 veya 1.1 kullanmaya çalışır. Modern sunucular bu versiyonları devre dışı bırakır ve bağlantı kesilir. Logda şöyle bir şey görürsünüz:

warning: TLS library problem: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number

Bu durumda sorunun hangi istemciden kaynaklandığını bulmak önemlidir:

# Hangi TLS versiyonunun kullanıldığını görmek için loglama seviyesini artır
postconf -e "smtpd_tls_loglevel = 2"
systemctl reload postfix

# Birkaç dakika bekle ve logları incele
grep "TLS connection established" /var/log/mail.log | tail -20

TLS versiyonlarını test etmek için:

# TLS 1.2 desteğini test et
openssl s_client -connect mail.example.com:993 -tls1_2 2>&1 | grep -E "Protocol|Cipher|Verify"

# TLS 1.3 desteğini test et
openssl s_client -connect mail.example.com:993 -tls1_3 2>&1 | grep -E "Protocol|Cipher|Verify"

# Hangi cipher'ların desteklendiğini listele
nmap --script ssl-enum-ciphers -p 993 mail.example.com

STARTTLS Downgrade Saldırısı ve Yapılandırması

Bazen sorun teknik değil, yapılandırma politikasıdır. Outbound mail için smtpd_tls_security_level = encrypt ayarı yapıldığında, TLS desteklemeyen sunuculara mail gönderilemez. Oysa standart may ayarı TLS’i tercih eder ama zorlamaz.

# Belirli bir sunucuya TLS ile bağlantıyı manuel test et
swaks --to [email protected] --from [email protected] 
      --server mail.example.com --port 587 
      --tls --tls-verify 
      --auth LOGIN --auth-user [email protected]

# STARTTLS müzakeresini adım adım gör
openssl s_client -connect hedef-mail.com:25 -starttls smtp -debug 2>&1 | head -50

Sertifika İzleme ve Proaktif Önlemler

En iyi sorun giderme, sorunun yaşanmamasını sağlamaktır. Sertifika süresi için bir izleme sistemi kurmak kritik önem taşır.

#!/bin/bash
# /usr/local/bin/check-cert-expiry.sh
# Bu scripti cron ile haftada bir çalıştırın

MAIL_DOMAIN="mail.example.com"
ALERT_EMAIL="[email protected]"
WARNING_DAYS=30

# Port listesi: açıklama:port şeklinde
PORTS=("IMAPS:993" "SMTPS:465" "SMTP:25")

for PORT_INFO in "${PORTS[@]}"; do
    PROTO=$(echo $PORT_INFO | cut -d: -f1)
    PORT=$(echo $PORT_INFO | cut -d: -f2)
    
    if [ "$PROTO" == "SMTP" ]; then
        EXPIRY=$(echo | openssl s_client -connect ${MAIL_DOMAIN}:${PORT} -starttls smtp 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
    else
        EXPIRY=$(echo | openssl s_client -connect ${MAIL_DOMAIN}:${PORT} 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
    fi
    
    if [ -z "$EXPIRY" ]; then
        echo "HATA: ${PROTO}:${PORT} portu için sertifika alınamadı" | mail -s "UYARI: Mail TLS Sertifika Kontrolü Başarısız" $ALERT_EMAIL
        continue
    fi
    
    EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
    NOW_EPOCH=$(date +%s)
    DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))
    
    if [ $DAYS_LEFT -lt $WARNING_DAYS ]; then
        echo "${PROTO} sertifikası ${DAYS_LEFT} gün içinde sona erecek (${EXPIRY})" | 
            mail -s "UYARI: Mail Sertifikası Sona Eriyor - ${DAYS_LEFT} Gün" $ALERT_EMAIL
    fi
done

Bu scripti cron’a ekleyin:

# Her Pazartesi sabahı 08:00'de çalıştır
echo "0 8 * * 1 root /usr/local/bin/check-cert-expiry.sh" > /etc/cron.d/cert-check
chmod 644 /etc/cron.d/cert-check

Acil Durum: Sertifika Süresi Doldu, Hızlı Çözüm

Sertifika süresi doldu ve mail akışı durdu. Panik yok, adım adım gidelim.

# 1. Mevcut sertifika durumunu hızlıca gör
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem -noout -dates

# 2. Certbot ile yenile (80 portu açık olmalı)
certbot renew --force-renewal --standalone --pre-hook "systemctl stop postfix dovecot nginx" 
               --post-hook "systemctl start postfix dovecot nginx"

# 3. Eğer standalone çalışmıyorsa webroot kullan
certbot renew --force-renewal --webroot -w /var/www/html

# 4. Yeni sertifikanın yüklendiğini doğrula
openssl x509 -in /etc/letsencrypt/live/mail.example.com/cert.pem -noout -dates

# 5. Servisleri yeniden başlat
systemctl restart postfix dovecot

# 6. Test et
openssl s_client -connect mail.example.com:993 2>/dev/null | openssl x509 -noout -dates

Port 80’e erişim yoksa ya da certbot çalışmıyorsa manuel sertifika yükleme gerekebilir. Bu durumda sertifika sağlayıcınızdan yeni sertifikayı indirip /etc/ssl/ altına yerleştirip yapılandırmayı güncelleyin.

Yaygın Hata Mesajları ve Anlamları

Her sistem yöneticisinin bir yerde not etmesi gereken TLS hata mesajları ve ne anlama geldikleri:

  • SSL_accept error from ... : -1: TLS handshake başlamadan bağlantı kesildi, genellikle sertifika güven sorunu
  • certificate verify failed: Sertifika imzalayan CA güvenilmiyor veya zincir eksik
  • certificate has expired: Sertifika süresi dolmuş, hemen yenileme gerekli
  • handshake failure: İstemci ve sunucu ortak cipher suite bulamadı, TLS versiyon uyumsuzluğu olabilir
  • unknown ca: İstemci, sertifikayı imzalayan CA’yı tanımıyor
  • no shared cipher: Desteklenen şifreleme algoritması yok, cipher suite yapılandırması gözden geçirilmeli
  • tlsv1 alert protocol version: İstemci sunucunun desteklemediği TLS versiyonu talep ediyor
  • wrong version number: TLS olmayan bir porta TLS bağlantısı deneniyor veya tam tersi

Sonuç

Mail sunucusundaki TLS sorunları genellikle üç ana kategoriye girer: sertifika sorunları (süresi dolma, eksik zincir, izin hatası), yapılandırma sorunları (yanlış dosya yolları, uyumsuz TLS versiyonları) ve altyapı sorunları (servis yeniden başlatılmaması, otomatik yenileme çalışmaması).

Bu sorunların büyük çoğunluğu proaktif izleme ile tamamen önlenebilir. Certbot deploy hook’ları, sertifika süresi izleme scriptleri ve düzenli TLS konfigürasyon testleri, mail sunucunuzu gece 02:00’de panik içinde debug etmekten kurtarır.

Bir sorunla karşılaştığınızda şu sırayı takip edin: önce loglar, sonra sertifika geçerliliği, ardından dosya izinleri, sonra yapılandırma doğruluğu ve son olarak ağ katmanı. Çoğu zaman sorun ilk iki adımda ortaya çıkar ve çözüm düşündüğünüzden çok daha basit olur.

Benzer Konular

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir