Outlook ve Telefonda Sertifika Uyarısı: Mail Sunucusu Adı Neden Eşleşmiyor

Salı sabahı Outlook'u açıyorsunuz ve ekranın ortasında o pencere beliriyor: "İnternet Güvenlik Uyarısı — Bağlanmakta olduğunuz sunucu doğrulanamayan bir güvenlik sertifikası kullanıyor. Hedef asıl adı yanlış." Altında iki düğme var: "Evet" ve "Hayır". Aynı dakikada tarayıcıda sitenizi açıyorsunuz, adres çubuğunda kilit duruyor, sertifikaya bakıyorsunuz, altmış günü daha var. Sonra muhasebeden telefon geliyor: iPhone'da posta uygulaması "Sunucu Kimliği Doğrulanamıyor" diyormuş.

Buradaki çelişki aslında bir çelişki değil. İki farklı sertifikaya bakıyorsunuz. Tarayıcı 443 numaralı porta bağlanır ve o portu dinleyen web sunucusunun alanadiniz.com için sunduğu sertifikayı doğrular. Outlook ise 993'e, telefonunuz 465'e bağlanır; o portları dinleyen posta servisleri (cPanel'de Dovecot ve Exim, kendi sunucunuzda Dovecot ve Postfix) tamamen ayrı bir sertifika dosyası sunabilir. Aynı makinede çalışıyor olmaları ikisini aynı yapmaz ve paylaşımlı hostingte çoğu zaman aynı değildir.

Bu yazıda uyarının hangi katmandan geldiğini otuz saniyede kanıtlayan komutu, istemciye mail.alanadiniz.com mı yoksa sağlayıcının sunucu adını mı yazmanız gerektiğine karar veren tabloyu, cPanel ve kendi sunucunuz için kalıcı çözümleri ve Outlook, iPhone, Android'de tam olarak hangi alanı düzelteceğinizi anlatıyorum. Bir de Türkçe kaynakların neredeyse tamamının verdiği "Yine de güven deyip geçin" cevabının neden bir çözüm değil, doğrudan bir güvenlik açığı olduğunu gerekçesiyle açıklıyorum.

Sitede Kilit Var Ama Mail Uyarı Veriyor: İki Ayrı Sertifika#

Bir TLS sertifikası bir alan adına değil, bir bağlantıya sunulur. Hangi sertifikanın sunulacağına, bağlandığınız portu dinleyen servis karar verir. Aynı sunucuda beş farklı servis beş farklı sertifika sunabilir ve bu tamamen normaldir.

Doğrulama kuralı her birinde aynıdır ve tek cümleyle özetlenir: istemcide yazdığınız sunucu adı, sunucunun sunduğu sertifikanın içinde geçmek zorundadır. Sertifikanın "Subject Alternative Name" (SAN) alanında hangi adlar listelenmişse, yalnızca o adlarla bağlandığınızda uyarı çıkmaz.

En sık yaşanan senaryo şudur: sertifikanız alanadiniz.com ve www.alanadiniz.com adlarını kapsıyor. Siz Outlook'a gelen sunucu olarak mail.alanadiniz.com yazdınız. Bu ad sertifikada yok. Sunucu size elindeki tek sertifikayı, yani kendi makine adına (srv12.saglayici.com gibi) verilmiş olanı sunuyor. Outlook adları karşılaştırıyor, tutmuyor, uyarı basıyor. Sertifikanın süresiyle, güvenilirliğiyle, şifreleme gücüyle hiçbir sorun yok; sadece isim tutmuyor.

Buradaki ikinci incelik SNI'dır. Modern posta istemcileri bağlanırken hangi adı istediklerini sunucuya söyler, yani sunucu doğru sertifikayı seçebilecek bilgiye sahiptir. Ama seçebilmesi için o sertifikanın kurulmuş ve posta servisine tanıtılmış olması gerekir. Tanıtılmamışsa sunucu varsayılan sertifikasına döner ve o da makine adına aittir. Yani sorun genellikle "sertifika yok" değil, "doğru sertifika posta servisine bağlanmamış" sorunudur.

Uyarı Mesajları Platforma Göre Ne Diyor?#

Her istemci aynı olayı farklı cümleyle anlatır. Aşağıdaki tablo mesajı gerçek nedene çevirir.

Üç alt neden var ve karıştırılmamaları gerekir: ad uyuşmazlığı, süre bitmesi ve güvenilmeyen imzalayan. Outlook'un uyarı penceresinde üç satırlık bir kontrol listesi görürsünüz; yeşil tik olmayan satır size hangisi olduğunu doğrudan söyler. iPhone'da "Ayrıntılar" bağlantısına dokunup sertifikanın adına bakmak yeterlidir: orada kendi alan adınızı değil sağlayıcının makine adını görüyorsanız neden ad uyuşmazlığıdır.

Bu ayrım önemlidir, çünkü çözümler farklıdır. Ad uyuşmazlığında ya sunucuya doğru sertifika kurulur ya istemcideki ad değiştirilir. Süre bitmesinde sertifika yenilenir. Güvenilmeyen imzalayanda ise genellikle ara sertifika zinciri eksiktir; tarayıcılar bazı eksik zincirleri kendileri tamamlayabildiği için site açılırken posta istemcisi patlar. O senaryonun ayrıntısı eksik ara sertifika hatası yazısında.

Teşhis: Sunucunun Gerçekte Hangi Sertifikayı Sunduğunu Görme#

Ekran görüntülerine bakarak tahmin yürütmek yerine sunucuya doğrudan sorun. Aşağıdaki komutlar posta portlarına bağlanır ve sunulan sertifikanın kimin adına düzenlendiğini gösterir.

# IMAPS (993) — bağlantı baştan şifreli
openssl s_client -connect mail.alanadiniz.com:993 -servername mail.alanadiniz.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# SMTPS (465) — baştan şifreli gönderme portu
openssl s_client -connect mail.alanadiniz.com:465 -servername mail.alanadiniz.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

# Submission (587) — STARTTLS ile şifrelemeye geçer
openssl s_client -connect mail.alanadiniz.com:587 -starttls smtp -servername mail.alanadiniz.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Çıktıda üç satıra bakın. subject=CN = ... sertifikanın asıl adıdır. X509v3 Subject Alternative Name altındaki liste, bu sertifikanın kapsadığı tüm adlardır. notAfter ise bitiş tarihidir.

Şimdi tek soruyu sorun: istemcinize yazdığınız sunucu adı bu listede geçiyor mu? Geçmiyorsa teşhis tamamlanmıştır, sebep ad uyuşmazlığıdır. Zincirin geçerli olup olmadığını da aynı bağlantıda görebilirsiniz:

# Doğrulama sonucunu ve sunulan zinciri göster
openssl s_client -connect mail.alanadiniz.com:993 -servername mail.alanadiniz.com -showcerts </dev/null 2>/dev/null \
  | grep -E 'Verify return code|subject=|issuer='

Verify return code: 0 (ok) her şeyin yolunda olduğunu söyler. 21 (unable to verify the first certificate) zincirin eksik olduğunu, 10 (certificate has expired) süre bittiğini, 18 (self signed certificate) kendinden imzalı bir sertifika sunulduğunu gösterir. Bu kodların tamamı ve daha fazla inceleme komutu için OpenSSL komutları yazısına bakabilirsiniz.

Windows kullanıyorsanız bu komutları Git Bash veya WSL içinde çalıştırabilirsiniz. Hiçbiri yoksa curl ile de aynı bilgiye ulaşırsınız:

curl -v --url imaps://mail.alanadiniz.com 2>&1 | grep -E 'subject|issuer|expire'

Karar: mail.alanadiniz.com mı, Sağlayıcının Sunucu Adı mı?#

Bu noktada elinizde iki geçerli yol var ve hangisinin doğru olduğu barındırma tipinize bağlıdır.

İki yaklaşımın da bedeli var. Sağlayıcının makine adını yazmak her zaman çalışır, ama hosting değiştirdiğinizde ya da sağlayıcı hesabınızı başka bir makineye taşıdığında tüm cihazlardaki ayarı elle güncellemeniz gerekir. mail.alanadiniz.com kullanmak taşınabilir ve kurumsaldır; karşılığında o adın sertifika kapsamında olmasını sağlamak zorundasınız. Uzun vadede ikincisi daha az iş çıkarır.

Son satır özellikle sinsi bir tuzaktır. Postanızı Google Workspace veya benzeri bir servise taşıdıysanız ama DNS'te mail.alanadiniz.com kaydı hâlâ eski hosting sunucusunu gösteriyorsa, istemci hiç posta kutunuz olmayan bir makineye bağlanır ve oradan gelen alakasız sertifikayı reddeder. Bu senaryonun DNS tarafı mail ve sitenin farklı sunucuda olması yazısında ayrıntılı.

Çözüm A: cPanel'de Mail Servislerine Sertifika Atamak#

cPanel'in AutoSSL özelliği, bir alan adı için sertifika üretirken servis alt alan adlarını da kapsama almaya çalışır: mail., webmail., cpanel., autodiscover., autoconfig. gibi. Yani doğru koşullar sağlandığında mail.alanadiniz.com zaten sertifikanın içinde olur ve hiçbir şey yapmanız gerekmez. Olmuyorsa şu üç şeyi sırayla kontrol edin.

1. DNS kaydı sunucuyu göstersin. mail.alanadiniz.com için bir A kaydı olmalı ve hosting sunucusunun IP'sine bakmalı. Kayıt yoksa sertifika otoritesi doğrulama yapamaz ve o ad kapsam dışı kalır.

dig +short mail.alanadiniz.com A
dig +short alanadiniz.com A

2. Cloudflare proxy kapalı olsun. mail kaydı turuncu bulutla proxy'leniyorsa hem doğrulama isteği Cloudflare'a düşer hem de posta trafiği zaten proxy üzerinden geçemez. O kaydı "DNS only" (gri bulut) yapın.

3. AutoSSL'i elle çalıştırın. cPanel'de SSL/TLS Status ekranını açın, kapsam dışı alan adlarını işaretleyip Run AutoSSL düğmesine basın. Ekran hangi adın neden dışarıda kaldığını gerekçesiyle yazar; bu satır teşhisin yarısıdır. AutoSSL'in çalışma mantığı ve kapsam sorunları için cPanel AutoSSL rehberine bakın.

Sertifikayı elle kuruyorsanız, cPanel'in SSL/TLS → Install an SSL Website ekranında Enable SNI for Mail Services kutusunu işaretlemeyi unutmayın. Bu kutu, kurduğunuz sertifikanın yalnızca web sunucusuna değil Dovecot ve Exim'e de tanıtılmasını sağlar. İşaretlenmediğinde sitede kilit çıkar, posta istemcisi uyarmaya devam eder — bu yazıdaki sorunun cPanel'e özgü bir numaralı sebebi tam olarak budur.

Sunucu yöneticisiyseniz WHM tarafında Manage Service SSL Certificates ekranı da vardır. Orada sunucunun kendi makine adına kurulu sertifika yönetilir; bu, SNI eşleşmediğinde sunulan varsayılan sertifikadır. Makine adı geçerli bir tam nitelikli alan adı değilse ya da sertifikası yoksa, tüm kullanıcılar için varsayılan cevap kendinden imzalı bir sertifika olur ve herkes uyarı görür.

Çözüm B: Kendi Sunucunuzda Postfix ve Dovecot Sertifikası#

Kendi sunucunuzu yönetiyorsanız iş nettir: mail.alanadiniz.com için sertifika alın ve iki servise de tanıtın.

# Web sunucusu 80 portunu dinliyorsa webroot ile
sudo certbot certonly --webroot -w /var/www/html -d mail.alanadiniz.com \
  --deploy-hook "systemctl reload postfix dovecot"

# 80 portu boşsa standalone ile
sudo certbot certonly --standalone -d mail.alanadiniz.com \
  --deploy-hook "systemctl reload postfix dovecot"

Ardından iki yapılandırma dosyasına yolu yazın. Postfix tarafı:

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.alanadiniz.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.alanadiniz.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1

Dovecot tarafı:

# /etc/dovecot/conf.d/10-ssl.conf
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.alanadiniz.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.alanadiniz.com/privkey.pem

Burada iki ayrıntı çoğu kurulumu bozar. Birincisi, cert.pem değil fullchain.pem kullanın; posta istemcileri tarayıcılar kadar hoşgörülü değildir ve eksik ara sertifikayı kendi başlarına tamamlamaya çalışmazlar. İkincisi, Dovecot'ta yol satırının başındaki < işareti bir yazım hatası değildir; Dovecot'a "bu bir dosya yolu, içeriğini oku" der ve silinirse servis açılmaz.

Değişiklikten sonra servisleri yeniden yükleyin ve teşhis komutunu tekrar çalıştırıp sonucu doğrulayın:

sudo postfix check && sudo doveconf -n > /dev/null && echo "yapilandirma tamam"
sudo systemctl reload postfix dovecot
openssl s_client -connect mail.alanadiniz.com:993 -servername mail.alanadiniz.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

Yenileme sonrası --deploy-hook çalışmazsa sertifika dosyada güncellenir ama servis eski dosyayı bellekte tutmaya devam eder; üç ay sonra süresi dolmuş bir sertifika sunulur ve uyarı geri gelir. Bu, en sık gözden kaçan uzun vadeli hatadır.

Çözüm C: İstemcide Doğru Sunucu Adını Yazmak#

Sunucuya müdahale edemiyorsanız, doğru olan adı istemciye yazmak tamamen meşru bir çözümdür. Kritik nokta: gelen ve giden sunucu adlarının ikisini birden değiştirmeniz gerekir. Yalnızca birini düzeltmek "posta geliyor ama gitmiyor" tablosuna yol açar.

Outlook (klasik sürüm)

1. Dosya → Hesap Ayarları → Hesap Ayarları'nı açın.
2. Hesabı çift tıklayın; "Gelen posta sunucusu" alanına doğru adı yazın.
3. Diğer Ayarlar → Gelişmiş sekmesinde portların 993 (IMAP) ve 465 ya da 587 (SMTP) olduğundan emin olun.
4. Giden Sunucu sekmesinde "Giden sunucum kimlik doğrulaması gerektiriyor" işaretli kalsın.
5. Outlook'u tamamen kapatıp açın; açık bağlantılar kapanmadan uyarı devam edebilir.

iPhone ve iPad

1. Ayarlar içinden Mail bölümüne, oradan Posta Hesapları'na girip hesabı seçin.
2. Hesap satırına dokunun; "Ana Bilgisayar Adı" alanını gelen sunucu için düzeltin.
3. Aynı ekranda SMTP → Birincil Sunucu'ya girip giden sunucu adını da düzeltin.
4. Kaydettikten sonra hesabın doğrulanmasını bekleyin.

Android

Üretici uygulaması ne olursa olsun yol benzerdir: hesap ayarları → gelen sunucu ayarları → sunucu adı, sonra giden sunucu ayarları → sunucu adı. Bazı Android posta uygulamalarının sertifikayı geçici olarak kabul etme seçeneği hiç yoktur; o cihazlarda yanlış ad yazılıysa hesap kurulumu tamamlanamaz bile. Telefon tarafındaki kurulumun tamamı telefona kurumsal e-posta ekleme yazısında adım adım anlatılıyor; port seçimleri için de mail portları rehberi işinizi görür.

"Yine de Güven" Demenin Gerçek Bedeli#

Türkçe forumlarda bu sorunun standart cevabı tek satırdır: "Evet'e basın, geçer." Geçer, ama neyin geçtiğini bilerek basmak gerekir.

Sertifika doğrulaması, karşınızdaki makinenin iddia ettiği makine olduğunu kanıtlayan tek mekanizmadır. Uyarıyı kabul ettiğinizde bu kanıtı istemekten vazgeçmiş olursunuz. IMAP ve SMTP istemcileri parolanızı her bağlantıda yeniden gönderir ve bu bağlantılar dakikada birkaç kez kurulur. Otelde, kafede ya da DNS'i kurcalanmış bir ağda araya giren bir makine kendi sertifikasını sunduğunda, doğrulamayı kapattığınız için istemci hiç ses çıkarmaz; parola ve tüm posta trafiği aradaki makineden geçer. Sertifika uyarısı tam olarak bunu engellemek için vardır.

İkinci bedel operasyoneldir. İstemciler istisnayı belirli bir sertifikaya bağlar. Sertifika yenilendiğinde parmak izi değişir ve uyarı bütün cihazlarda yeniden çıkar. Let's Encrypt'te bu üç ayda bir demektir; sektör genelinde geçerlilik süreleri kısalmaya devam ettiği için sıklık artacak. On kişilik bir ofiste bu, yılda kırk kez tekrarlanan bir destek talebidir. Sunucu tarafında bir kez düzeltmek, her cihazda dört ayda bir "Evet"e basmaktan hem güvenli hem ucuzdur.

Uyarı Hâlâ Çıkıyorsa: Beş Sık Neden#

1. autodiscover.alanadiniz.com kapsam dışı. Outlook hesabı kurarken önce otomatik keşif adresine bağlanır. mail. düzeltilmiş ama autodiscover. sertifikada yoksa, kurulum sırasında ayrı bir uyarı görürsünüz. Çözüm bu adı da kapsama almak ya da hesabı elle kurmaktır.

2. Ara sertifika eksik. Zincir eksikse tarayıcı çoğu zaman toparlar, posta istemcisi toparlamaz. Verify return code: 21 görüyorsanız sebep budur.

3. İstemci eski istisnayı hatırlıyor. Thunderbird ve macOS Mail kabul edilmiş sertifikaları saklar. Sunucu düzeltildikten sonra eski istisnayı silmezseniz istemci hâlâ eski karara göre davranabilir. Thunderbird'de Ayarlar → Gizlilik ve Güvenlik → Sertifikaları Yönet → Sunucular sekmesinden silin.

4. Cihaz saati yanlış. Tarihi geleceğe kaymış bir telefon, geçerli bir sertifikayı "süresi dolmuş" sayar. Otomatik saat ayarını açın.

5. Servis yeniden yüklenmedi. Sertifika dosyası güncel ama Dovecot ya da Exim eski dosyayı bellekte tutuyor olabilir. openssl çıktısındaki notAfter tarihi dosyadakinden eskiyse sebep budur; servisi yeniden yükleyin.

Sıkça Sorulan Sorular#

Sitemde SSL var, mailde neden ayrıca gerekiyor?#

Sertifika alan adına değil bağlantıya sunulur. Tarayıcı 443 portundaki web sunucusuna, posta istemcisi 993 ve 465 portlarındaki Dovecot ile Exim'e bağlanır. Bunlar ayrı servislerdir ve her biri yalnızca kendisine tanıtılmış sertifikayı sunar. Web sertifikanız posta servislerine tanıtılmadıysa, posta tarafı sunucunun varsayılan sertifikasını sunmaya devam eder ve istemci ad uyuşmazlığı bildirir.

mail.alanadiniz.com sertifikada olmak zorunda mı?#

Zorunda değil. İstemcide sağlayıcının sunucu adını kullanırsanız bağlantı sorunsuz doğrulanır ve güvenlik açısından hiçbir kaybınız olmaz. Ancak mail.alanadiniz.com kullanmak taşınabilir bir yapılandırma sağlar: hosting değiştirdiğinizde kullanıcıların cihazlarına dokunmadan yalnızca DNS kaydını güncellersiniz. Kurumsal ortamlarda bu fark, yıllarca tekrar eden bir bakım işini ortadan kaldırır.

Wildcard sertifikam var, mail neden hâlâ uyarı veriyor?#

Wildcard sertifika *.alanadiniz.com biçimindeki adları kapsar, yani mail.alanadiniz.com gerçekten kapsam içindedir. Uyarı devam ediyorsa sertifika henüz posta servislerine tanıtılmamıştır. cPanel'de sertifikayı kurarken mail servisleri için SNI kutusunu işaretleyin; kendi sunucunuzda Postfix ve Dovecot yapılandırmasındaki dosya yollarını güncelleyip servisleri yeniden yükleyin.

Uyarıyı kabul edersem verilerim şifresiz mi gider?#

Hayır, trafik yine şifrelenir. Kaybettiğiniz şey şifreleme değil kimlik doğrulamasıdır: karşınızdaki makinenin iddia ettiği makine olduğunu artık kimse kontrol etmez. Araya giren bir sunucu kendi sertifikasını sunduğunda istemci sessiz kalır ve parolanız ile posta içeriğiniz o makine üzerinden geçer. Bu yüzden kabul etmek, özellikle açık ağlarda gerçek bir risktir.

Sertifikayı düzelttim ama Outlook hâlâ uyarıyor, ne yapmalıyım?#

Önce sunucudan gelen cevabı doğrulayın: openssl s_client çıktısındaki bitiş tarihi ve SAN listesi beklediğiniz gibiyse sorun istemci tarafındadır. Outlook'u tamamen kapatıp açın, hesap ayarlarındaki sunucu adının hem gelen hem giden için doğru yazıldığını kontrol edin ve cihaz saatinin otomatik olduğundan emin olun. Komut çıktısı hâlâ eski sertifikayı gösteriyorsa posta servisleri yeniden yüklenmemiştir.

Paylaşımlı hostingteyim ve sertifika kuramıyorum, tek çarem ne?#

Sağlayıcınızın verdiği sunucu adını istemciye yazmak tamamen geçerli ve güvenli bir çözümdür. Bunun yanında mail.alanadiniz.com için A kaydının sunucuya baktığını ve varsa Cloudflare proxy'sinin kapalı olduğunu kontrol edin. Bu iki koşul sağlandığında AutoSSL bir sonraki turda o adı genellikle kendiliğinden kapsama alır ve kendi alan adınızı kullanmaya dönebilirsiniz.