WordPress’te SSL Handshake Failed Hatası Nasıl Çözülür?

Cloudflare 525 “SSL handshake failed”, Cloudflare ile kaynak sunucu arasındaki TLS görüşmesinin başarısız olduğunu gösterir. Tarayıcının doğrudan TLS hatası veya WordPress’in başka bir servise yaptığı bağlantı hatası aynı bağlantı değildir. Önce mesajı ve hatanın hangi hatta oluştuğunu belirleyin.

Hangi Hata, Hangi Bağlantı?

Cloudflare varsa tarayıcıda gördüğünüz sertifika genellikle CDN’in sertifikasıdır; kaynak sunucunun sertifikasını ayrıca kontrol etmeniz gerekir. PHP sürümünü değiştirmek tarayıcı/CDN ile web sunucusunun bütün TLS yapılandırmasını otomatik düzeltmez.

525 İçin Kaynak Sunucu Kontrolleri

Cloudflare, 525’in Full veya Full (strict) modunda kaynakla TLS görüşmesi başarısız olduğunda oluştuğunu açıklıyor. Hosting sağlayıcısıyla kaynakta HTTPS dinleyicisini, 443 erişimini, kurulu sertifikayı, SNI desteğini ve uyumlu şifre takımlarını inceleyin. Aralıklı hatada olay saatini sunucu TLS hata loguyla eşleştirin.

526 İle Sertifika Sorununu Ayırın

526, Cloudflare’ın kaynak sertifikasını doğrulayamadığını belirtir. Süre, alan adı/SAN eşleşmesi, güven zinciri ve ara sertifikaları inceleyin. Kaynak için uygun sertifika ve tam zincir kurulduktan sonra Full (strict) yapılandırmasını doğrulayın.

Cloudflare Origin CA sertifikası Cloudflare-kaynak bağlantısı için kullanılabilir; normal tarayıcının kaynak adresine doğrudan güveneceğini varsaymayın. Güven deposu ve sertifika türünü testin bağlamına göre değerlendirin. Doğrulamayı kapatmak kalıcı çözüm değildir.

Flexible Neden Başka Sorun Çıkarabilir?

Flexible, ziyaretçiden Cloudflare’a HTTPS, Cloudflare’dan kaynağa HTTP kullanır. Kaynak HTTP’yi HTTPS’ye yönlendiriyorsa yönlendirme döngüsü oluşabilir. Bu, 525 ile aynı teşhis değildir. Kaynak HTTPS’yi düzgün kurup uygun doğrulanan modu kullanın; hatayı gizlemek için Flexible’a geçmeyin.

Sertifika Testinde SNI’ı Unutmayın

Yetkili olduğunuz sunucuda OpenSSL bulunuyorsa aşağıdaki örnek bağlantı ve alan adı doğrulamasını incelemeye yardımcı olur. Adresi ve alan adını kendi gerçek kaynak bilginizle değiştirin; 203.0.113.10 örnek IP’dir.

openssl s_client -connect 203.0.113.10:443 -servername www.example.com -verify_hostname www.example.com -verify_return_error

-servername doğru sanal sunucuyu seçmek için SNI gönderir; -verify_hostname isim eşleşmesini, -verify_return_error doğrulama hatasında durmayı sağlar. Yerel güven deposu da sonucu etkiler. Sadece bağlantının açılmasını sertifikanın doğru olduğuna kanıt saymayın.

WordPress Ayarları Ne Zaman Kontrol Edilmeli?

HTTPS hattı çalıştıktan sonra Site Adresi/WordPress Adresi, yönlendirme ve karışık içerik kontrollerine geçin. Mixed content, HTTPS sayfanın HTTP kaynak çağırmasıdır; tek başına ilk TLS görüşmesinin başarısızlığı değildir. Site adresini değiştirirken mevcut kurulum yapısını ve yönetim erişimini koruyun.

Dış API bağlantısındaki cURL hatasında hedef adres, CA deposu, sistem saati, kullanılan PHP/OpenSSL ve çıkış bağlantısını inceleyin. SSL doğrulamasını kapatan WordPress filtresi veya cURL seçeneği eklemeyin. Bunlar yanlış sertifikayı kabul ederek sorunu gizleyebilir.

Hosting Desteğine Hangi Bilgiyi Vermeli?

• Tam hata kodu, URL ve olay saati/saat dilimi.
• Cloudflare kullanımı ve mevcut SSL modu.
• Sorunun sürekli mi, aralıklı mı olduğu.
• Yakın zamanda DNS, sertifika, sunucu veya CDN değişikliği olup olmadığı.
• Hassas bilgi içermeyen ilgili TLS log satırları.

DNS değiştiyse doğru kaynak IP’sini kontrol edin; “24–48 saat bekleyin” her hatanın çözümü değildir. Yeni kaynağın sertifikası yanlışsa zaman geçmesi onu düzeltmez. Çözümden sonra aynı URL’yi ve bağlantı hattını yeniden test edin; yalnızca önbellek temizlemeyle TLS arızasının giderildiğini varsaymayın.

Kaynaklar ve İleri Okuma

• Cloudflare: 525 hata tanımı ve kaynak sunucu kontrolleri
• Cloudflare: 526 ve sertifika doğrulama
• Cloudflare: Flexible ve yönlendirme döngüsü
• OpenSSL: s_client seçenekleri

İlgili Yazılar

• ERR_SSL_PROTOCOL_ERROR rehberi
• WordPress hata çözümleri