Cloudflare 525 ve 526 Hatası: SSL Handshake Failed Çözümü

Sabah sitenizi açıyorsunuz ve turuncu bulut logolu bir sayfa karşınıza çıkıyor: Error 525: SSL handshake failed. Sayfanın üstündeki üç kutudan ilk ikisi — Browser ve Cloudflare — yeşil tik almış, üçüncüsü, yani Host, kırmızı çarpıyla işaretlenmiş. Dün akşam site sorunsuz çalışıyordu, koda dokunulmadı, sunucuya kimse girmedi. Yine de ziyaretçilerin hiçbiri siteye ulaşamıyor.

Bu ekranın en yanıltıcı tarafı, hatanın Cloudflare markasıyla gelmesidir. Oysa 525 ve 526 kodlarının ikisi de "Cloudflare çalışıyor, ziyaretçiden isteği aldım, ama sizin sunucunuzla şifreli bir bağlantı kuramadım" demektir. Ziyaretçi ile Cloudflare arasındaki bacak sağlamdır; kanıtı da bu hata sayfasının ziyaretçiye ulaşmış olmasıdır. Arıza, Cloudflare'in origin sunucunuza uzandığı ikinci bacaktadır ve çözümü Cloudflare panelinde değil, sunucunuzda aramanız gerekir.

Bu iki kodu tek bir "SSL sorunu" torbasına atmak, saatlerce yanlış yerde arama yapmanın en sık nedenidir. Aşağıda önce 525 ile 526'yı kesin biçimde ayıracağız — biri el sıkışmanın hiç tamamlanmaması, diğeri sertifikanın reddedilmesidir — sonra her birinin gerçek nedenlerini, Cloudflare'i devre dışı bırakmadan sunucuyu test etmenin yollarını ve kalıcı çözümü ele alacağız. Bu arada çok yaygın bir "hızlı çözüm"ün neden sorunu çözmeyip yalnızca gizlediğini de göstereceğim.

525 ile 526 Arasındaki Fark: El Sıkışma mı, Sertifika mı?#

İki kodu ayıran şey, TLS el sıkışmasının hangi aşamasında tıkanıldığıdır. En kısa özet şudur: 525'te konuşma hiç başlayamaz, 526'da konuşma başlar ama gösterilen kimlik kabul edilmez.

Bu ayrımın pratik değeri büyüktür. 526 alıyorsanız sunucunuzda HTTPS zaten çalışıyordur: 443 portu açıktır, bir sertifika sunulmaktadır ve TLS parametreleri uyumludur. Sorun yalnızca o sertifikanın Cloudflare'in güven ölçütlerini karşılamamasıdır. Dolayısıyla 526 aldığınızda güvenlik duvarı kurallarını, port durumunu ya da şifre takımlarını kontrol etmek zaman kaybıdır; doğrudan sertifikanın kendisine bakın.

Tersine 525 aldığınızda sertifikaya bakmanın anlamı yoktur, çünkü Cloudflare sertifikayı görecek noktaya bile gelememiştir. TLS'in adım adım nasıl işlediğini ve hangi aşamada neyin konuşulduğunu görmek isterseniz TLS handshake nasıl çalışır yazısı, bu iki kodu neden farklı yerlerde aramanız gerektiğini de netleştirir.

Kardeş kodlarla karıştırmamak da önemlidir: 521 ve 522 gibi kodlar TCP düzeyinde bir sorunu (bağlantının reddedilmesi ya da zaman aşımı) anlatır, yani sunucuya hiç ulaşılamamıştır. 525'te ise TCP bağlantısı kurulmuş, iş TLS katmanında kırılmıştır. Bu ailenin tamamını Cloudflare 520, 521 ve 522 hataları yazısında karşılaştırmalı bulabilirsiniz.

Hangi Şifreleme Modunda Hangi Hata Çıkar?#

Aldığınız kodun hangisi olduğu, Cloudflare panelindeki SSL/TLS → Overview ekranında seçili moda doğrudan bağlıdır:

Tablodaki en kritik satır Full'dur: bu modda Cloudflare şifreli bağlanır ama sertifikanın geçerliliğini denetlemez. Bu yüzden Full modunda 526 hatasını hiç görmezsiniz; süresi üç ay önce dolmuş, kendinden imzalı bir sertifika bile kabul edilir. Bu davranışı bir çözüm olarak değil, bir uyarı olarak okuyun: 526 hatasının Full'a geçince "düzelmesi", sertifikanın düzeldiği anlamına gelmez, yalnızca denetimin kapatıldığı anlamına gelir.

Error 525: SSL Handshake Failed Nedenleri#

525'in nedenleri, Cloudflare'in origin'e TLS ile bağlanma denemesinin nerede kırıldığına göre birkaç başlıkta toplanır.

443 Portu Kapalı ya da Kimse Dinlemiyor#

En sık neden budur. Sunucuda web servisi çalışıyor olabilir ama yalnızca 80 portunu dinliyordur; ya da güvenlik duvarı 443'ü dışarıya kapatmıştır. Proxy modu açık bir alan adında Cloudflare, origin'e varsayılan olarak 443 üzerinden HTTPS ile bağlanır.

# 443'te gerçekten dinleyen bir süreç var mı?
sudo ss -lntp | grep ':443'

# Güvenlik duvarı 443'e izin veriyor mu?
sudo ufw status verbose
sudo iptables -L INPUT -n --line-numbers | grep 443

ss çıktısı boşsa web sunucusunun HTTPS yapılandırması hiç yüklenmemiştir. Port kapalıysa açın:

sudo ufw allow 443/tcp
sudo ufw reload

Hangi portların açık kalması, hangilerinin kapatılması gerektiğine dair genel çerçeve için sunucuda hangi portlar açık olmalı yazısına göz atabilirsiniz.

Sunucuda HTTPS Sanal Host Tanımlı Değil#

Port açıktır, süreç dinlemektedir, ama ilgili alan adı için tanımlı bir SSL sanal host yoktur. Bu durumda web sunucusu ya bağlantıyı düşürür ya da tamamen alakasız bir varsayılan siteyi sunar. Nginx'te belirti nettir: etkin yapılandırmada o server_name için listen 443 ssl satırı bulunmaz.

# Etkin yapılandırmanın tamamını dök ve 443 bloklarını ara
sudo nginx -T 2>/dev/null | grep -B2 -A6 'listen 443'

# Apache'de etkin sanal hostlar
sudo apache2ctl -S

TLS Sürümü veya Şifre Takımı Uyuşmuyor#

Cloudflare modern TLS sürümleriyle bağlanmaya çalışır. Yalnızca TLS 1.0/1.1 konuşan, çok eski bir kütüphaneyle derlenmiş ya da şifre takımı listesi aşırı daraltılmış bir sunucu, ortak zeminde buluşamadığı için el sıkışmayı yarıda keser. Aynı şey ters yönde de olur: ssl_ciphers satırını "maksimum güvenlik" adına birkaç takıma indirdiyseniz, uyuşma ihtimalini kendi elinizle düşürmüşsünüzdür.

# Sunucu TLS 1.2 konuşuyor mu?
openssl s_client -connect 203.0.113.10:443 -servername ornek.com -tls1_2 </dev/null

# TLS 1.3 deneyin
openssl s_client -connect 203.0.113.10:443 -servername ornek.com -tls1_3 </dev/null

Sağlıklı bir origin'de bu komutlardan en az biri sertifika zincirini basmalıdır. no protocols available ya da handshake failure görüyorsanız nedeni buldunuz demektir. Nginx tarafında güvenli ve yeterince geniş bir taban şudur:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

SNI Desteği Yok ya da Yanlış Sertifika Sunuluyor#

Cloudflare origin'e bağlanırken hangi alan adını istediğini SNI ile bildirir. Sunucu SNI'yı yok sayıyorsa ya da tek bir IP üzerinde birden fazla site barındırıp SNI'sız istekte yanlış sanal hostu döndürüyorsa el sıkışma başarısız olabilir. Test ederken -servername parametresini kullanmanız tam da bu yüzden şarttır; onsuz yaptığınız test gerçeği yansıtmaz.

Güvenlik Duvarı Bağlantıyı Ortada Kesiyor#

ModSecurity, imunify360, CSF ya da bir DDoS koruma katmanı, Cloudflare'in IP aralıklarını tanımadığı için yoğun istekleri saldırı sanıp bağlantıyı düşürebilir. Bu senaryoda hata aralıklıdır: site bazen açılır, bazen 525 verir. Çözüm, Cloudflare'in yayımladığı IPv4 ve IPv6 aralıklarını sunucu güvenlik duvarında beyaz listeye almaktır.

Error 526: Invalid SSL Certificate Nedenleri#

526 yalnızca Full (strict) modunda görülür ve Cloudflare'in origin sertifikanızı doğrulayamadığını söyler. Doğrulama dört ayrı testten oluşur; herhangi biri düşerse kod 526'dır.

Sertifikanın Süresi Doldu#

Açık ara en yaygın neden. Let's Encrypt sertifikaları 90 gün geçerlidir ve yenileme görevi haftalar önce sessizce bozulmuşsa bunu ancak sertifikanın dolduğu gün fark edersiniz. "Dün çalışıyordu, bugün çalışmıyor, hiçbir şey değiştirmedim" cümlesinin arkasında genellikle bu vardır.

# Origin'in sunduğu sertifikanın tarihlerini ve sahibini oku
echo | openssl s_client -connect 203.0.113.10:443 -servername ornek.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

notAfter tarihi geçmişse teşhis tamamlanmıştır. Sertifika ömürlerinin neden kısaldığı ve bunun operasyonel karşılığı için sertifika geçerlilik süresi yazısı iyi bir arka plan sunar.

Kendinden İmzalı Sertifika#

Sunucu kurulumları çoğu zaman kendinden imzalı bir sertifikayla gelir. Bu sertifika şifrelemeyi sağlar ama hiçbir güvenilir kök tarafından imzalanmadığı için Full (strict) modunda reddedilir. Yukarıdaki komutun çıktısında issuer ile subject alanlarının birebir aynı olması bu durumun imzasıdır. Kendinden imzalı sertifikaların hangi durumlarda meşru olduğunu self-signed sertifika oluşturma yazısında bulabilirsiniz.

Alan Adı Sertifikayla Uyuşmuyor#

Sertifikanın Common Name ya da Subject Alternative Name alanında istenen alan adı yer almalıdır. ornek.com için sertifika alıp www.ornek.com'u eklememişseniz, www'lu adres 526 verirken köksüz adres sorunsuz çalışır. Bu asimetri teşhisi kolaylaştırır: iki adresten yalnızca biri hata veriyorsa neredeyse kesinlikle ad uyuşmazlığı vardır.

# Sertifikadaki tüm alan adlarını listele
echo | openssl s_client -connect 203.0.113.10:443 -servername ornek.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

Ara Sertifika Zinciri Eksik#

Sunucu yalnızca kendi sertifikasını sunuyor, ara CA sertifikasını sunmuyorsa Cloudflare güvenilir bir köke kadar zinciri kuramaz. Bu hatanın sinsiliği, tarayıcıların çoğunun eksik ara sertifikayı kendi önbelleğinden tamamlayabilmesi, Cloudflare'in ise tamamlamamasıdır: siteyi kendi tarayıcınızda açtığınızda hiçbir sorun görünmez. Nginx'te ssl_certificate yönergesi, leaf ve ara sertifikaları birleştiren fullchain.pem dosyasını göstermelidir. Konunun tamamı için sertifika zinciri nedir ve ara sertifika hatası yazılarına bakın.

Origin'i Cloudflare'i Kapatmadan Test Etmek#

Teşhis sırasında en sık yapılan hata, proxy'yi kapatıp DNS'in yayılmasını beklemektir. Buna gerek yok: curl ile alan adını doğrudan origin IP'sine sabitleyerek Cloudflare'i atlayabilirsiniz.

# Cloudflare'i atlayıp doğrudan origin'e HTTPS isteği at
curl -svo /dev/null --resolve ornek.com:443:203.0.113.10 https://ornek.com/

Çıktıda üç satıra bakın: SSL connection using TLSv1.3 (el sıkışma kuruldu mu), subject: ile issuer: (hangi sertifika sunuldu) ve expire date: (süresi dolmuş mu). Bu tek komut, 525 ile 526 arasındaki ayrımı saniyeler içinde yapmanızı sağlar:

• Komut SSL certificate problem diyerek düşüyorsa sertifika geçersizdir, yani 526 tarafındasınız.
• Komut Connection refused ya da handshake failure veriyorsa el sıkışma hiç kurulamamıştır, yani 525 tarafındasınız.

Sertifikayı doğrulamadan yalnızca el sıkışmanın kurulup kurulmadığını görmek isterseniz -k bayrağını ekleyin. Bağlantı -k ile açılıp -k olmadan düşüyorsa, sorunun kesinlikle sertifika doğrulaması olduğunu kanıtlamış olursunuz. Bu teşhis komutlarının daha geniş bir listesi için openssl komutları yazısı iyi bir başvuru kaynağıdır.

Sunucu tarafında log bakmayı da ihmal etmeyin. Apache'de mod_ssl log seviyesini geçici olarak yükseltmek, hangi aşamada anlaşılamadığını doğrudan gösterir:

LogLevel warn ssl:info

Neden Flexible'a Düşürmek Çözüm Değil?#

Bu iki hata için en çok önerilen "çözüm", SSL modunu Flexible'a çekmektir. Site gerçekten de anında açılır; bu yüzden çözüm sanılır. Oysa yaptığınız şey hatayı gidermek değil, hatayı üreten denetimi kapatmaktır. Flexible modunda Cloudflare origin sunucunuza düz HTTP ile bağlanır. Sonuçları şunlardır:

1. Sunucu ile Cloudflare arasındaki trafik şifresiz akar. Ziyaretçi adres çubuğunda kilidi görür ve verisinin uçtan uca korunduğunu sanar; oysa yolun ikinci yarısı açıktır. Bir e-ticaret sitesinde bu, form verilerinin ve oturum çerezlerinin ağ üzerinde düz metin taşınması demektir.
2. Yönlendirme döngüsü riski. Sunucunuzda HTTP'yi HTTPS'e yönlendiren bir kural varsa — ki olmalıdır — Cloudflare HTTP ile gelir, sunucu HTTPS'e yönlendirir, Cloudflare yine HTTP ile gelir. Sonuç ERR_TOO_MANY_REDIRECTS olur. Yönlendirmeyi doğru kurgulamak için HTTPS yönlendirme yazısına bakın.
3. Asıl arıza yerinde durur. Süresi dolmuş sertifika hâlâ dolmuş, kırık yenileme görevi hâlâ kırıktır. Bir gün Cloudflare'i devre dışı bıraktığınızda ya da başka bir servis doğrudan origin'e bağlandığında sorun aynen geri gelir.

Doğru yol sırasıyla şudur: geçici olarak Full'a alarak siteyi ayağa kaldırın (şifreleme korunur, yalnızca doğrulama gevşer), origin sertifikasını düzeltin, sonra Full (strict)'e geri dönün. Flexible'ı yalnızca origin'de kesinlikle TLS kurulamayan geçici durumlar için, o da saatler ölçeğinde düşünün.

Kalıcı Çözüm: Cloudflare Origin CA Sertifikası#

Cloudflare arkasındaki bir sunucu için en dayanıklı çözüm, Cloudflare'in ücretsiz Origin CA sertifikasını kurmaktır. Bu sertifika yalnızca Cloudflare tarafından güvenilir kabul edilir; tarayıcıya doğrudan sunulursa uyarı verir. Ama origin bacağı için tasarlandığından bu bir eksiklik değildir. Asıl avantajı çok uzun geçerlilik süresidir: 90 günde bir yenilenmesi gereken bir sertifika yerine yıllarca dayanan bir sertifika kurarsınız, böylece "yenileme görevi bozuldu, sertifika doldu" senaryosu tamamen ortadan kalkar.

Adımlar:

1. Cloudflare panelinde SSL/TLS → Origin Server → Create Certificate yolunu izleyin.
2. Alan adı listesine hem kök adı hem joker kaydı ekleyin: ornek.com ve *.ornek.com.
3. Geçerlilik süresini seçin, üretilen sertifika ve özel anahtar metinlerini sunucuya kaydedin. Özel anahtar bu ekranda yalnızca bir kez gösterilir; kaçırırsanız yeni sertifika üretmeniz gerekir.

sudo mkdir -p /etc/ssl/cloudflare
sudo nano /etc/ssl/cloudflare/ornek.com.pem
sudo nano /etc/ssl/cloudflare/ornek.com.key
sudo chmod 600 /etc/ssl/cloudflare/ornek.com.key
sudo chown root:root /etc/ssl/cloudflare/ornek.com.key

Nginx tarafında:

server {
    listen 443 ssl;
    server_name ornek.com www.ornek.com;

    ssl_certificate     /etc/ssl/cloudflare/ornek.com.pem;
    ssl_certificate_key /etc/ssl/cloudflare/ornek.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    root /var/www/ornek;
}

Apache tarafında:

<VirtualHost *:443>
    ServerName ornek.com
    ServerAlias www.ornek.com

    SSLEngine on
    SSLCertificateFile    /etc/ssl/cloudflare/ornek.com.pem
    SSLCertificateKeyFile /etc/ssl/cloudflare/ornek.com.key
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    DocumentRoot /var/www/ornek
</VirtualHost>

Yapılandırmayı yüklemeden önce mutlaka sözdizimini sınayın; hatalı bir SSL bloğu servisin hiç başlamamasına ve 525'in kalıcı hâle gelmesine yol açar:

sudo nginx -t && sudo systemctl reload nginx

# Apache için
sudo apachectl configtest && sudo systemctl reload apache2

Origin CA sertifikasını kurduktan sonra Cloudflare panelinde modu Full (strict) yapın. Bu noktada origin bacağı hem şifreli hem doğrulanmış olur. Yapılandırmanın diğer başlıkları ve oturum ayarları için nginx SSL yapılandırma yazısına bakabilirsiniz.

Hatanın Tekrarlamaması İçin Ne Yapmalı?#

525 ve 526 hatalarının büyük kısmı kurulum anında değil, aylar sonra ortaya çıkar. Kalıcı olarak kurtulmak için üç alışkanlık yeterlidir.

Yenilemeyi test edin, varlığına güvenmeyin. Bir yenileme görevinin tanımlı olması çalıştığı anlamına gelmez. Certbot kullanıyorsanız prova modunda çalıştırıp gerçekten sonuç ürettiğini görün:

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

Otomatik yenilemeyi doğru kurgulamak için SSL otomatik yenileme yazısındaki kontrol listesi işinizi görür.

Sertifika bitiş tarihini dışarıdan izleyin. Sunucunun kendi kendini izlemesi, sunucu ayakta değilken işe yaramaz. Bağımsız bir noktadan çalışan basit bir kontrol bile 30 gün önceden uyarı vermenize yeter:

end=$(echo | openssl s_client -connect ornek.com:443 -servername ornek.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ( $(date -d "$end" +%s) - $(date +%s) ) / 86400 )) gun kaldi

Modu Full'da bırakmayın. Geçici çözüm olarak Full'a düştüyseniz takviminize bir hatırlatma koyun. Full modu 526 hatasını göstermez; bu, sertifikanızın sessizce bozulup aylarca öyle kalabileceği anlamına gelir. Full (strict) aslında sizin lehinize çalışan bir alarm sistemidir; alarmı susturmak yerine onu çaldıran nedeni giderin.

Sıkça Sorulan Sorular#

Cloudflare 525 hatası Cloudflare kaynaklı mı, benim sunucumdan mı?#

Neredeyse her zaman origin sunucunuzdan kaynaklanır. Hata sayfasındaki üç kutudan işaretli olanı "Host" kutusudur ve bu, Cloudflare'in ziyaretçiden isteği aldığını ama sizin sunucunuzla şifreli bağlantı kuramadığını gösterir. Cloudflare panelinde ayar kurcalamak yerine sunucunuza bağlanıp 443 portunu, HTTPS sanal hostu ve TLS ayarlarını kontrol etmelisiniz.

525 ve 526 hatası arasındaki fark tam olarak nedir?#

525'te TLS el sıkışması hiç tamamlanamaz; Cloudflare sertifikanızı görecek aşamaya bile gelemez. Genellikle 443 portunun kapalı olması, HTTPS'in yapılandırılmamış olması ya da TLS sürümü ile şifre takımı uyuşmazlığı yüzünden çıkar. 526'da ise el sıkışma kurulur, sertifika sunulur ama Cloudflare onu geçersiz bulur: süresi dolmuştur, kendinden imzalıdır, alan adı uyuşmaz veya zinciri eksiktir.

SSL modunu Flexible yaparsam sorun çözülür mü?#

Site açılır ama sorun çözülmez. Flexible modunda Cloudflare sunucunuza şifresiz HTTP ile bağlanır; ziyaretçi kilit simgesini görse de trafiğin ikinci yarısı korumasız akar. Ayrıca sunucunuzda HTTPS yönlendirmesi varsa sonsuz yönlendirme döngüsü oluşur. Doğru yaklaşım, geçici olarak Full moduna almak, origin sertifikasını düzeltmek ve ardından Full (strict) moduna dönmektir.

Cloudflare Origin CA sertifikası tarayıcıda güvenli görünür mü?#

Doğrudan sunulursa görünmez, çünkü bu sertifikayı yalnızca Cloudflare güvenilir kabul eder. Ancak bu bir eksiklik değildir: ziyaretçiye sunulan sertifika Cloudflare'in kendi kenar sertifikasıdır, Origin CA sertifikası yalnızca Cloudflare ile sunucunuz arasındaki bacakta kullanılır. Proxy kapalıyken alan adına doğrudan erişilecekse ayrıca güvenilir bir CA sertifikası kurmanız gerekir.

Sertifikam geçerli görünüyor ama hâlâ 526 alıyorum, sebebi ne olabilir?#

En olası neden eksik ara sertifikadır. Tarayıcılar çoğu zaman eksik ara sertifikayı kendi önbelleklerinden tamamlar, Cloudflare tamamlamaz; bu yüzden site size çalışıyormuş gibi görünür. Nginx'te ssl_certificate yönergesinin yalnızca leaf sertifikayı değil, ara sertifikaları da içeren fullchain.pem dosyasını göstermesi gerekir. İkinci olasılık, sertifikada www'lu adın bulunmamasıdır.

Bu hatalar kendiliğinden düzelir mi, beklemeli miyim?#

Hayır. 525 ve 526 geçici ağ dalgalanmalarından değil, sunucu tarafındaki somut bir yapılandırma ya da sertifika sorunundan kaynaklanır; siz müdahale etmedikçe düzelmez. Tek istisna, güvenlik duvarının Cloudflare IP'lerini süreli olarak engellemesidir. Bu durumda hata aralıklı görünür ve engel süresi dolunca kaybolur, ama koşullar tekrarlandığında yeniden ortaya çıkar.