Sertifika doğrulaması kapatılınca e-postalar gönderilmeye başlıyor. Bu, sorunun çözüldüğü anlamına gelmez; WordPress yanlış sunucuya ya da TLS trafiğini inceleyen bir proxy’ye güveniyor olabilir. Güvenli çözüm, WordPress’in karşısında hangi sertifikayı gördüğünü belirleyip doğrulama zincirini düzeltmektir.
Bu rehber; host adı, sertifika zinciri, sistem saati, TLS modu ve ağdaki araya girme sorunlarını ayırt etmeyi, ardından sonucu WordPress sunucusundan doğrulamayı anlatır.
Bu konu ne anlama gelir?
SMTP TLS sertifika hatası, WordPress’in posta hizmetine ulaştığını ancak hizmetin kimliğini veya sertifika zincirini doğrulayamadığını gösterir. Yapılandırılan host adı sertifikanın Subject Alternative Name listesinde bulunmalı, gerekli ara sertifikalar sunulmalı ve WordPress sunucusu sertifikayı veren otoriteye güvenmelidir.
Port ile şifreleme yöntemi de uyumlu olmalıdır. 465 numaralı port genellikle baştan itibaren TLS kullanır. 587 gibi portlarda ise SMTP oturumu çoğunlukla açık başlar ve STARTTLS ile şifrelemeye geçer.
Gerçekçi bir WordPress örneği
Bir site yıllardır eski bir SMTP takma adı kullanıyor. Ağ değişikliğinden sonra bağlantıda, sağlayıcının kanonik posta hostu için düzenlenmiş bir sertifika görülüyor. Sertifika doğrulamasını kapatmak test e-postasının gönderilmesini sağlıyor; fakat WordPress’in doğru hizmetle konuştuğunu kanıtlayan denetimi de ortadan kaldırıyor.
Yönetici doğrulamayı yeniden açıyor, sağlayıcının belgelediği host adını ve uygun TLS modunu seçiyor, ardından testi canlı sunucudan yineliyor. Beklenmeyen sertifika yalnız bu ağda görünüyorsa WordPress ayarını gevşetmek yerine proxy veya güvenlik cihazı inceleniyor.
Neden önemlidir ve ne zaman kullanılır?
Sertifika hatası, ağ bağlantısı TLS aşamasına ulaştıktan sonra oluşur. Bu yüzden hata metni—host adı uyuşmazlığı, süresi dolmuş sertifika, bilinmeyen sertifika otoritesi, eksik zincir veya handshake hatası—çoğu zaman sorunun posta sağlayıcısında mı, hosting tarafında mı, ağda mı yoksa WordPress ayarında mı olduğunu gösterir.
SMTP hostu yerine IP adresi kullanmak veya kaynağı açıklanmayan bir sertifikayı güvenilir saymak doğru çözüm değildir. Her iki yöntem de kimlik sorununu gizleyebilir. Amaç yalnız şifreli bağlantı kurmak değil, belgelenmiş host için geçerli bir güven zinciri oluşturmaktır.
Bu yöntem TLS görüşmesi sırasında çıkan hatalar içindir. Kimlik doğrulama, reddedilen gönderen, bağlantı zaman aşımı ve teslimat sorunları ayrı değerlendirilmelidir.
Yeni başlayanlar için anlaşılır yol
- SMTP hostu, port, şifreleme yöntemi ve sertifika doğrulamasına eklenmiş geçici istisnaları kaydedin.
- Ayarları sağlayıcının güncel dokümanıyla karşılaştırın. Sunucu saatini ve işletim sistemindeki CA paketini kontrol edin.
- Sertifika ve host adı doğrulamasını açın. WordPress sunucusundan sunulan sertifikanın adlarını, veren otoriteyi, geçerlilik tarihlerini ve tüm zinciri inceleyin.
- Ayarı düzeltin veya süresi dolan sertifika ya da eksik ara sertifikalar için sorumlu sağlayıcıya başvurun.
- WordPress’in ürettiği gerçek bir ileti gönderin; SMTP yanıtını ve kontrollü posta kutusundaki teslimatı birlikte doğrulayın.
İleri teknik yol
Handshake kaydını WordPress’in çalıştığı sunucu ve ağdan alın. Yapılandırılan host adını SAN listesiyle karşılaştırın ve doğru SNI değeriyle test edin. STARTTLS kullanılıyorsa sunucunun EHLO sonrasında bu özelliği sunduğunu; örtük TLS kullanılıyorsa bağlantının ilk andan itibaren şifreli başladığını doğrulayın.
Yalnız uç sertifikaya değil tüm zincire bakın. Bir masaüstü bilgisayar eksik ara sertifikayı önbellekten tamamlayarak canlı sunucuda olmayan bir başarı gösterebilir. Geçerlilik tarihlerini UTC üzerinden ve CA paketi sürümüyle birlikte değerlendirin. Kurumsal proxy sertifikayı değiştiriyorsa özel kök sertifika yalnız yetkilendirilmiş sistemlere bilinçli biçimde dağıtılmalıdır.
Düzeltme; doğru host için doğrulanmış bağlantı, başarılı kimlik doğrulama ve normal WordPress akışından gönderilen gerçek bir iletinin teslimiyle kabul edilir.
Riskler, sık hatalar, yedekleme ve geri alma
Sertifika veya host adı doğrulamasını canlı ortamda kapalı bırakmayın. Sabit IP kullanmak, kaynağı belirsiz bir sertifikayı güvenilir saymak ya da sağlayıcının belirtmediği port/TLS eşleşmesini seçmek, kimlik bilgilerini riske atabilir ve araya giren bir sistemi gizleyebilir.
Değişiklikten önce SMTP ayarlarını yedekleyin. Doğrulanmış bağlantı ve gönderim tamamlanmıyorsa önceki güvenli yapılandırmaya dönün; güvensiz doğrulama istisnasını geri getirmeyin. Sertifikayı, test zamanını, seçilen adresi ve sorumlu tarafı kimlik bilgilerini açığa çıkarmadan kaydedin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, WordPress tarafındaki SMTP hostu, port, şifreleme ve gönderen ayarlarını tek yerde gösterir. Böylece sertifika testinin sitenin gerçek posta akışıyla aynı adresi ve TLS modunu kullanıp kullanmadığı kolayca görülebilir.
Host adı veya sertifika zinciri düzeltildikten sonra modülün test ve tanı bilgileriyle WordPress’in iletiyi sağlayıcıya aktarıp aktarmadığını ve sağlayıcının yanıtını kontrol edin. Ardından kontrollü bir parola sıfırlama bildirimi gibi gerçek bir işlem e-postası göndererek uygulama akışını da sınayın.
AIOWS sağlayıcının sertifikasını yenileyemez, sunucunun güven deposunu güncelleyemez veya ağ proxy’sini değiştiremez. Bu işlemler posta sağlayıcısı, hosting firması ya da ağ yöneticisinin sorumluluğundadır. Modül, dış sorunlar giderilirken desteklenen WordPress ayarlarını ve test sonucunu anlaşılır biçimde takip etmeye yardımcı olur.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-postaları Spama Düşüyor: 10 Etkili Çözüm
- WordPress SMTP Bağlantı Zaman Aşımı Nasıl Çözülür?
- WordPress SMTP Bağlantısı Reddedildi: Çözüm Rehberi
Sonuç ve önerilen yol
Sertifika ve host adı doğrulamasını açık tutun. Sağlayıcının belgelediği adresi kullanın; zincir, saat, güven deposu veya yetkili ağ incelemesindeki sorunu asıl kaynağında düzeltin. Değişikliği ancak canlı WordPress sunucusu doğrulanmış bağlantı kurup gerçek bir ileti gönderebildiğinde tamamlanmış sayın.
