Cloudflare 525 ve 526 Hataları: SSL/TLS Ayarı Nasıl Kontrol Edilir?

Cloudflare 525, Cloudflare ile kaynak sunucunuz arasındaki SSL el sıkışmasının başarısız olduğunu söyler ve yalnız Full ya da Full (strict) modunda görülür. 526 ise Full (strict) modunda Cloudflare'in kaynaktaki sertifikayı doğrulayamadığını anlatır: süresi geçmiş, kendinden imzalı, adı uyuşmayan ya da zinciri eksik bir sertifika. İkisinin de çözümü Cloudflare ayarında değil, kaynak sunucudadır. 443 portunun açık olduğunu ve alan adı için geçerli bir sertifika (Let's Encrypt, AutoSSL, ücretli sertifika ya da Cloudflare Origin CA) sunulduğunu openssl s_client ile doğrudan test edin. Flexible moda geçmek hatayı gizler, sorunu çözmez.

Hangi modda hangi hata çıkar?

Cloudflare'de proxy açık bir kayıt varsa ortada iki ayrı bağlantı vardır: ziyaretçi ile Cloudflare arası ve Cloudflare ile sizin sunucunuz arası. Tarayıcıdaki kilit simgesi yalnız birinci bağlantıyı anlatır. 525 ve 526 ise ikinci bağlantının hatalarıdır ve hangisini göreceğinizi SSL/TLS > Overview ekranındaki şifreleme modu belirler.

Cloudflare'in güncel belgelerinde bu modların üstünde bir de Automatic SSL/TLS seçeneği var ve varsayılan olarak o geliyor. Bu seçenek kaynağınızın desteklediği en güvenli modu kendisi seçer. Belgede iki ayrıntı dikkat çekiyor: Automatic SSL/TLS ayarı hiçbir zaman daha zayıf bir moda indirmez ve kaynaktaki sertifikanın süresi dolarsa geri dönüş yapmaz. Yani dün Full (strict) ile sorunsuz çalışan bir sitede bugün 526 çıkıyorsa ilk şüpheli, kaynaktaki sertifikanın süresidir.

Bir de şunu ayırın: Cloudflare kaynağa TCP bağlantısını hiç kuramıyorsa ekranda 525 değil, bağlantı zaman aşımını anlatan 522 hatası görünür. 525'te TCP bağlantısı kurulmuştur, TLS aşamasında kopar.

525: el sıkışma neden kurulamıyor?

Cloudflare'in 525 sayfası kaynak tarafında dört olası neden sayıyor. Kaynakta geçerli bir SSL sertifikası kurulu değildir. 443 portu (ya da kullandığınız özel güvenli port) açık değildir. Sunucu SNI (Server Name Indication) desteklemiyordur. Cloudflare'in sunduğu şifre takımlarıyla sunucunun desteklediği takımlar örtüşmüyordur.

İşin pratiğinde bu dört maddenin arkasında çoğunlukla daha sıradan şeyler çıkar. Alan adı hosting paneline eklenmiş ama HTTPS sanal sunucusu (virtual host) hiç oluşturulmamıştır. Sunucu taşınmış, eski IP Cloudflare DNS'inde kalmış, o IP'de artık başka bir şey çalışıyordur. Güvenlik duvarı 80'e izin verip 443'ü kapatmıştır. Kendi yönettiğiniz bir VPS'te TLS yapılandırması aşırı daraltılmış, Cloudflare'in sunduğu takımların hiçbiri kabul edilmiyordur.

Hata aralıklı geliyorsa Cloudflare'in önerisi, 525'lerin görüldüğü saatlerde sunucunun hata günlüklerine bakmaktır. Apache'de mod_ssl günlük düzeyini, nginx'te error_log düzeyini geçici olarak artırmak el sıkışmanın neden kesildiğini çoğu zaman açıkça yazar. Birden fazla kaynak sunucunuz varsa (yük dengeleme ya da hem A hem AAAA kaydı) hepsini ayrı ayrı test edin, çünkü yalnız birinin bozuk olması aralıklı hataya en sık yol açan durumdur.

526: sertifika neden doğrulanamıyor?

526 yalnız Full (strict) ve Strict modlarında çıkar. Cloudflare'in bu modda kaynaktan beklediği üç şey var: sertifikanın geçerlilik tarihleri içinde olması, herkesin güvendiği bir sertifika kuruluşundan ya da Cloudflare Origin CA'dan çıkmış olması ve istenen ad için Common Name ya da Subject Alternative Name alanında bir eşleşme taşıması. 526 belgesi buna eksik zinciri de ekliyor: kaynak sunucu, kendi sertifikasının yanında gereken ara sertifikaları da göndermelidir.

Yaygın bir tuzak şudur: site Cloudflare'i aradan çıkarınca tarayıcıda sorunsuz açılır, herkes sertifikanın sağlam olduğunu düşünür. Oysa bazı tarayıcılar eksik ara sertifikayı kendi imkânlarıyla tamamlayabilir. Tarayıcıda açılması zincirin eksiksiz olduğunu kanıtlamaz. İkinci tuzak kapsamdır. Sertifika ornek.com.tr için alınmış ama www.ornek.com.tr ya da shop.ornek.com.tr da Cloudflare üzerinden yayındaysa o adlar için 526 alırsınız. Joker sertifika (*.ornek.com.tr) kök adı kapsamaz, ona ayrıca yer verilmelidir.

Kaynağı Cloudflare'i aradan çıkararak test edin

Tahmin yürütmek yerine kaynak sunucuya doğrudan bağlanıp ne sunduğuna bakın. Kaynağın IP adresini Cloudflare'in DNS ekranındaki A kaydından alabilirsiniz. Aşağıdaki örnekte 203.0.113.10 kullanılıyor:

openssl s_client -connect 203.0.113.10:443 \
  -servername ornek.com.tr \
  -verify_hostname ornek.com.tr \
  -showcerts </dev/null

-servername, Cloudflare'in yaptığı gibi SNI ile alan adını gönderir. -verify_hostname sertifikadaki adın eşleşip eşleşmediğini de denetletir. -showcerts sunucunun gönderdiği bütün sertifikaları sırasıyla döker, böylece ara sertifikanın gelip gelmediğini görürsünüz. Çıktının sonuna doğru Verify return code: 0 (ok) satırını arayın. Sorun varsa OpenSSL sebebini düz metinle yazar:

• certificate has expired: süresi dolmuş sertifika, 526'nın en yaygın nedeni.
• self-signed certificate: kendinden imzalı sertifika. Full modda geçer, Full (strict) modda geçmez.
• unable to get local issuer certificate: çoğunlukla ara sertifika gönderilmiyordur.
• hostname mismatch: sertifika başka bir ad için düzenlenmiştir.

Bağlantı daha el sıkışmada kopuyor, sertifika hiç gelmiyorsa 525 tarafındasınız demektir: port, SNI ya da şifre takımı uyumsuzluğu. Aynı testi HTTP yanıtıyla birlikte görmek isterseniz curl'ün --resolve seçeneği adı belirttiğiniz IP'ye sabitler, SNI ve sertifika denetimini yine alan adına göre yapar:

curl -sv -o /dev/null \
  --resolve ornek.com.tr:443:203.0.113.10 \
  https://ornek.com.tr/

Sunucunuzun güvenlik duvarı 443'e yalnız Cloudflare IP'lerinden izin veriyorsa bu testler sizin bilgisayarınızdan zaman aşımına uğrar. O durumda aynı komutu sunucunun kendisinde 127.0.0.1:443 adresine karşı çalıştırın.

Çözüm: kaynağa geçerli bir sertifika koymak

Panelin ücretsiz sertifikası

Paylaşımlı hostingte en kolay yol panelin kendi sertifikasıdır. cPanel'de AutoSSL, Plesk'te alan adının SSL/TLS Certificates ekranı üzerinden Let's Encrypt sertifikası alınır ve otomatik yenilenir. Kurulum adımlarını cPanel'de AutoSSL ve Let's Encrypt kurulumu rehberinde bulabilirsiniz. Proxy açıkken de HTTP doğrulaması çoğu zaman geçer. Geçmiyorsa, ki Cloudflare'in güvenlik kuralları doğrulama yolunu engellediğinde böyle olur, AutoSSL'in alan adını doğrulayamadığı durumların teşhisi adım adım ilerlemenizi sağlar. Netx'in Plesk panelli web hosting paketlerinde ücretsiz Let's Encrypt SSL bulunur.

Kurumsal doğrulama (OV ya da EV) gerekiyorsa ücretli bir sertifika da Cloudflare arkasında sorunsuz çalışır. Sertifikayı yüklerken ara sertifika paketini (CA bundle) eklemeyi unutmayın. Türler arasındaki farkı DV, OV ve EV sertifika karşılaştırması anlatıyor, seçenekler için SSL sertifikası sayfamıza bakabilirsiniz.

Cloudflare Origin CA sertifikası

Kaynağınız trafiği yalnız Cloudflare üzerinden alıyorsa ikinci seçenek Cloudflare'in kendi Origin CA sertifikasıdır. Panelde SSL/TLS altındaki Origin Server sayfasında, Origin Certificates sekmesinden Create Certificate ile üretilir. Çıkan sertifikayı ve özel anahtarı sunucunuza yükler, ardından modu Full (strict) yaparsınız.

Sınırlarını bilerek kullanın. Bu sertifika yalnız Cloudflare ile kaynak arasındaki bağlantı içindir. Cloudflare belgesine göre Cloudflare'i duraklatırsanız ya da bir kaydın proxy'sini kapatırsanız ziyaretçiler güvenilmeyen sertifika hatası görür. Cloudflare bu sertifikaların süre sonu için bildirim de göndermez, bitiş tarihini kendi takviminize yazmanız gerekir. Bizce yönetimi kendinizde olan bir VPS'te uzun süreli Origin CA sertifikası pratik bir seçimdir. Paylaşımlı hostingte ise panelin otomatik yenilenen sertifikası daha az sürprize yol açar.

525'e özgü ayarlar

Sertifika yerindeyse ama el sıkışma yine kuruluyorsa sunucu tarafına bakın. 443 portu güvenlik duvarında açık mı? Alan adı için HTTPS sanal sunucusu tanımlı mı? Sunucu SNI ile gelen ada doğru sertifikayı veriyor mu? Kendi yönettiğiniz sunucuda TLS 1.2 ve 1.3 açık, modern ECDHE takımları etkin olmalıdır. Hangi takımların sunulduğunu Cloudflare'in şifre takımları listesiyle karşılaştırabilirsiniz.

Flexible neden çözüm değil?

Forumlarda en sık önerilen "çözüm" modu Flexible'a çekmektir. Hata kaybolur, çünkü Cloudflare artık kaynağa şifresiz HTTP ile bağlanır ve sertifikaya hiç bakmaz. Bedeli iki tanedir. İlki güvenlik: Cloudflare ile sunucunuz arasındaki trafik, giriş bilgileri ve form verileri dahil, düz metin olarak taşınır. Ziyaretçi kilidi görür ama yolun yarısı açıktır. Cloudflare belgesi de kişisel veri ya da kullanıcı girişi işleyen uygulamalar için Full ya da Full (strict) kullanılmasını istiyor.

İkinci bedel yönlendirme döngüsüdür. Sunucunuz HTTP isteklerini HTTPS'e yönlendiriyorsa, ki SSL kurulu sitelerin neredeyse hepsi böyle yapar, Flexible modda Cloudflare'in HTTP isteği her seferinde yönlendirilir, Cloudflare yine HTTP ile gelir. Tarayıcı ERR_TOO_MANY_REDIRECTS hatası verir. Cloudflare'in Flexible sayfası bu durumda Flexible'ın kullanılmamasını açıkça yazıyor.

Full mod da kalıcı bir çare sayılmaz. Cloudflare'in 526 belgesi hızlı çözüm olarak Full'e geçişi anıyor. Bunu yalnız kısa süreli bir tanı adımı olarak görün: Full modda kaynak sertifikasının süresine, imzalayanına ve adına bakılmaz, belgenin kendi ifadesiyle araya giren biri kendi sertifikasını sunarak bağlantıyı ele geçirebilir.

Hatanın gerçekten kalktığını görmek

• Kaynağa doğrudan yapılan openssl s_client testi Verify return code: 0 (ok) veriyor ve sertifikanın bitiş tarihi ileride.
• Proxy açık her ad için (kök, www, alt alan adları) aynı test temiz sonuç veriyor.
• Mod Full (strict) ya da Automatic SSL/TLS, yani geçici olarak düşürdüyseniz geri aldınız.
• curl -sI https://ornek.com.tr/ yanıtında HTTP/2 200 ya da beklediğiniz yönlendirme kodu ve cf-ray başlığı görünüyor.
• Origin CA kullandıysanız bitiş tarihi takviminizde.

Hata kalktıktan sonra tarayıcıda kilit yine eksik görünüyorsa sorun artık sertifikada değil, sayfanın içeriğindedir. HTTPS sayfada http ile yüklenen görsel ya da betik varsa karışık içerik uyarısını temizlemek sonraki adımdır.

Destek ekibine yazarken

Kaynak sunucunuz Netx'teyse Netx müşteri panelinden destek talebi açabilirsiniz. Şunları eklerseniz teşhis doğrudan doğru katmandan başlar: hatanın göründüğü tam adres, Cloudflare hata sayfasının altındaki Ray ID, hatanın görüldüğü tarih ve saat (saat dilimiyle), Cloudflare'deki şifreleme modu, Cloudflare DNS'inde kaynak olarak girilen IP ve openssl s_client testinin çıktısı. Origin CA ya da ücretli sertifika kurduysanız hangisini, hangi adlar için kurduğunuzu da yazın. Özel anahtarı talebe eklemeyin.

Sık sorulan sorular

Cloudflare zaten SSL veriyor, sunucuda neden ayrıca sertifika gerekiyor?

Cloudflare'in otomatik verdiği sertifika yalnız ziyaretçi ile Cloudflare arasındaki bağlantıyı korur. Cloudflare ile sunucunuz arasındaki bağlantı ayrı bir TLS oturumudur ve Full ya da Full (strict) modda sunucunun kendi sertifikasını ister.

Origin CA sertifikasını e-posta ya da panel adresleri için de kullanabilir miyim?

Önermeyiz. mail.ornek.com.tr ya da panel adresleri genellikle proxy kapalı (DNS only) kayıtlardır ve istemciler sunucuya doğrudan bağlanır. Origin CA sertifikası o bağlantıda güvenilmeyen sertifika uyarısı üretir. Bu adlar için herkesin güvendiği bir sertifika kullanın.