SSL sertifikası kurulduktan sonra sitenin açılmaması tek bir nedene bağlanamaz. Tarayıcının gösterdiği hata metni, sertifikanın hangi alan adı için sunulduğu, DNS kayıtları, sunucu ve uygulama içindeki yönlendirme kuralları ve varsa CDN ayarları birlikte değerlendirilmelidir. Sertifika hatasını tarayıcıdaki “yine de devam et” uyarısını geçerek “çözmeye” çalışmayın; bu yalnızca sizin bilgisayarınızda sorunu gizler, ziyaretçileriniz aynı hatayı görmeye devam eder. Bu rehberde hata mesajından yola çıkarak sorunun hangi katmanda olduğunu bulmayı, en sık görülen beş senaryoyu ve kalıcı çözümleri adım adım ele alıyoruz.
Önce hata mesajını doğru okuyun
“Site açılmıyor” ifadesi birbirinden çok farklı sorunları kapsar. Teşhise başlamadan önce sayfayı gizli pencerede açın ve tarayıcının verdiği hata kodunu not edin. Aşağıdaki kodlar hangi yöne bakmanız gerektiğini büyük ölçüde belirler:
- NET::ERR_CERT_COMMON_NAME_INVALID: Sunulan sertifika ziyaret ettiğiniz alan adını kapsamıyor. Genellikle
wwwile kök alan adından birinin sertifikaya eklenmemesi veya DNS’in başka bir sunucuyu göstermesinden kaynaklanır. - NET::ERR_CERT_DATE_INVALID: Sertifikanın süresi dolmuş ya da cihazın saati yanlış. Yeni kurduğunuz bir sertifikada bu hatayı görüyorsanız sunucu hâlâ eski sertifikayı sunuyor olabilir.
- NET::ERR_CERT_AUTHORITY_INVALID: Sertifika zinciri eksik veya kendinden imzalı (self-signed) bir sertifika sunuluyor. Ara sertifikanın (CA bundle) yüklenmemesi sık nedendir.
- ERR_TOO_MANY_REDIRECTS: Sertifika büyük olasılıkla doğru; sorun birbirini tetikleyen yönlendirme kurallarında.
- ERR_SSL_PROTOCOL_ERROR / SSL Handshake Failed: Sunucu 443 portunda düzgün bir TLS bağlantısı kuramıyor; yapılandırma, port veya protokol sürümü sorunu olabilir.
- Sayfa açılıyor ama kilit simgesi yok: Sertifika çalışıyor, ancak sayfa içinde HTTP ile yüklenen kaynaklar (mixed content) var.
Senaryo 1: Sertifika yanlış alan adı için sunuluyor
cPanel’de SSL/TLS Status ekranından ilgili alan adının sertifika durumunu görün. www.alanadi.com ve alanadi.com ayrı adlardır; ikisinin de sertifika kapsamında olduğunu doğrulayın. AutoSSL kullanıyorsanız ekranda bir alan adının yanında hata simgesi görüyorsanız ayrıntıya tıklayın; çoğu zaman sebep o adın DNS kaydının bu sunucuyu göstermemesidir.
Sertifikanın gerçekte ne sunduğunu panelden değil, dışarıdan görmek daha güvenilirdir. Terminalde şu komut sunucunun döndürdüğü sertifikanın konu alanını, kapsadığı alan adlarını ve geçerlilik tarihlerini gösterir:
openssl s_client -connect alanadi.com:443 -servername alanadi.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName -dates-servername parametresi önemlidir: aynı IP üzerinde birden fazla site barındıran paylaşımlı sunucularda doğru sertifikayı almak için SNI bilgisinin gönderilmesi gerekir. Çıktıdaki subjectAltName satırında alan adınız yoksa sertifika yeniden üretilmeli veya doğru sertifika ilgili siteye atanmalıdır.
Senaryo 2: DNS hâlâ eski sunucuyu gösteriyor
Hosting değiştirdikten hemen sonra sertifika kurduysanız, sizin bilgisayarınız yeni sunucuya giderken ziyaretçilerin bir kısmı DNS önbelleği nedeniyle hâlâ eski sunucuya gidebilir. Eski sunucuda sertifika yoksa ya da süresi dolmuşsa bu kişiler hata görür. Ayrıca AutoSSL ve Let’s Encrypt gibi otomatik sertifika sistemleri alan adının bu sunucuya ait olduğunu doğrulayamadığı için sertifika üretemez.
- A ve AAAA kayıtlarının yeni sunucunun IP adreslerini gösterdiğini kontrol edin. Eski bir IPv6 (AAAA) kaydının unutulması, sadece IPv6 kullanan ziyaretçilerde hata çıkmasına yol açan klasik bir hatadır.
- Alan adında CAA kaydı varsa, kullandığınız sertifika sağlayıcısının bu kayıtta izinli olduğundan emin olun. İzin verilmeyen bir sağlayıcı sertifika üretemez.
- Let’s Encrypt’in HTTP doğrulaması için
/.well-known/acme-challenge/yolunun 80 portundan erişilebilir olması gerekir. Bu yolu engelleyen bir güvenlik kuralı veya her isteği zorla HTTPS’e yönlendiren hatalı bir yapı doğrulamayı bozabilir.
DNS’in hangi sunucuyu gösterdiğini kontrol etmek için dig +short alanadi.com A ve dig +short alanadi.com AAAA komutlarını kullanabilir, farklı ülkelerden sonuç gösteren DNS kontrol araçlarıyla yayılımı izleyebilirsiniz. DNS kayıtlarının nasıl çalıştığını hatırlamak isterseniz DNS yönlendirme rehberimize göz atın.
Senaryo 3: Yönlendirme döngüsü (ERR_TOO_MANY_REDIRECTS)
HTTP’den HTTPS’e yönlendirme hem hosting panelinde hem .htaccess dosyasında hem de uygulama veya eklenti içinde tanımlanmış olabilir. Bu kurallardan biri isteği HTTPS’e, diğeri tekrar HTTP’ye veya www‘lu adrese gönderdiğinde tarayıcı sonsuz bir döngüye girer.
CDN veya proxy arkasındaki siteler
En yaygın döngü nedeni, Cloudflare gibi bir proxy’nin “Flexible” SSL modunda çalışmasıdır. Bu modda ziyaretçi ile Cloudflare arasında HTTPS kullanılır, ancak Cloudflare sizin sunucunuza HTTP ile bağlanır. Sunucunuz gelen HTTP isteğini görüp HTTPS’e yönlendirir, Cloudflare yine HTTP ile ister ve döngü başlar. Sunucunuzda geçerli bir sertifika varsa SSL modunu Full (strict) olarak ayarlamak bu sorunu kalıcı olarak çözer.
Proxy arkasında çalışan uygulamalar, isteğin aslında HTTPS ile geldiğini X-Forwarded-Proto başlığından anlamalıdır. WordPress bu başlığı varsayılan olarak dikkate almaz; gerekirse wp-config.php içinde, yalnızca güvenilir proxy’den geldiğinden emin olduğunuz durumlarda, şu kontrol eklenebilir:
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https' ) {
$_SERVER['HTTPS'] = 'on';
}Tek bir yönlendirme zinciri tasarlayın
Kuralları tek bir yerde toplayın. Örneğin Apache kullanan bir sitede .htaccess içinde hem HTTPS hem tercih edilen alan adı (www’lu veya www’suz) tek kuralda çözülebilir; WordPress tarafında ise Ayarlar → Genel ekranındaki WordPress Adresi ve Site Adresi alanlarının aynı biçimde (https:// ile ve aynı alan adıyla) tanımlı olması gerekir. Hem yönlendirme eklentisi hem sunucu kuralı aynı işi yapıyorsa birini kaldırın.
Zinciri test etmek için curl -sIL http://alanadi.com komutunu kullanın. Çıktıda her adımın durum kodu ve Location başlığı görünür. İdeal durumda en fazla bir veya iki 301 adımından sonra 200 yanıtı alınmalıdır.
Sertifika çalışmadan “her zaman HTTPS” veya HSTS kuralını zorlamak erişimi tamamen kesebilir. HSTS başlığı tarayıcıya siteyi belirli bir süre yalnızca HTTPS ile açmasını söyler; sertifika sorunu yaşanırken bu başlık gönderildiyse kullanıcılar uyarıyı geçemez. HSTS’i ancak tüm alan adları ve alt alan adları sorunsuz HTTPS sunduktan sonra, önce kısa bir süreyle etkinleştirin.
Senaryo 4: Sayfa açılıyor ama kilit simgesi eksik
Bu durumda genellikle mixed content vardır: HTML sayfası HTTPS iken resim, CSS veya JavaScript dosyaları http:// ile çağrılır. Tarayıcılar güvensiz komut dosyalarını engellediği için sayfa düzeni bozulabilir, menüler veya formlar çalışmayabilir.
- Tarayıcının geliştirici araçlarını açıp Console sekmesinde “Mixed Content” uyarılarını listeleyin.
- Uyarıdaki adreslerin nereden geldiğini bulun: yazı içeriği, tema ayarları, widget, özelleştirici CSS veya eklenti ayarları olabilir.
- WordPress’te veritabanında
http://alanadi.comgeçen adreslerihttps://alanadi.comile değiştirmek için serileştirilmiş veriyi bozmayan bir araç (ör. WP-CLIsearch-replacekomutu) kullanın. Düz SQL ile toplu değiştirme, serileştirilmiş ayarları bozabilir. - Değişiklikten önce mutlaka veritabanı yedeği alın ve önce
--dry-runile kaç kaydın etkileneceğini görün. - Önbellek eklentisi ve CDN önbelleğini temizleyip sayfayı yeniden kontrol edin.
Senaryo 5: Bağlantı hiç kurulamıyor
Tarayıcı “bağlantı reddedildi” veya protokol hatası veriyorsa sorun sertifikadan önce gelir. Sunucunun 443 portunu dinlediğini, güvenlik duvarının bu portu açtığını ve web sunucusu yapılandırmasında ilgili sanal sunucu (virtual host) için sertifika dosyalarının doğru yollarla tanımlandığını kontrol edin. Sertifika ve özel anahtar dosyalarının birbiriyle eşleşmemesi de web sunucusunun yeniden başlatılırken hata vermesine yol açar. VPS kullanıyorsanız web sunucusunu yeniden başlatmadan önce yapılandırmayı nginx -t veya apachectl configtest ile test edin. Bu hatanın ayrıntıları için SSL Handshake Failed rehberine ve ERR_SSL_PROTOCOL_ERROR rehberine bakabilirsiniz.
WordPress sitelerinde ek kontroller
WordPress, site adresini veritabanındaki siteurl ve home seçeneklerinde saklar. HTTPS’e geçişte bu iki değerin güncellenmemesi, yönetici paneline girişte döngü veya yarım yüklenen sayfalar gibi sorunlara yol açar. Panele erişemiyorsanız wp-config.php dosyasına geçici olarak şu satırları ekleyerek adresi zorlayabilirsiniz:
define( 'WP_HOME', 'https://alanadi.com' );
define( 'WP_SITEURL', 'https://alanadi.com' );Bu sabitler tanımlıyken Ayarlar ekranındaki adres alanları kilitlenir. Panele girip sorunu çözdükten sonra veritabanındaki değerleri güncelleyebilir ve isterseniz bu satırları kaldırabilirsiniz. Yönetici paneli ve giriş sayfasının her zaman şifreli bağlantıyla açılması için FORCE_SSL_ADMIN sabitini true olarak tanımlamak da iyi bir uygulamadır.
Dikkat edilmesi gereken diğer noktalar:
- SSL eklentileri: HTTPS geçişini otomatikleştiren eklentiler kendi yönlendirme ve içerik düzeltme kurallarını ekler. Sunucuda zaten yönlendirme varsa bu kurallar çakışabilir. Eklenti devre dışı bırakılırken eklediği .htaccess kurallarının da temizlendiğini kontrol edin.
- Önbellek eklentileri: HTTP sürümüyle önbelleğe alınmış sayfalar, geçişten sonra da sunulmaya devam edebilir. Geçişin ardından önbelleği tamamen temizleyin.
- Sabit kodlanmış adresler: Tema dosyalarında, özel CSS’te veya sayfa oluşturucu ayarlarında
http://ile yazılmış görsel ve font adresleri mixed content uyarılarının sık kaynağıdır. - Çoklu site (multisite): Ağ kurulumlarında her alt sitenin adresi ayrı tabloda tutulur; tüm alt sitelerin adreslerini ayrı ayrı güncellemeniz gerekir.
Sertifika yenilemesini güvence altına alın
Bugün çalışan bir sertifika, otomatik yenileme bozulursa birkaç ay sonra aynı hatayı yeniden üretir. Ücretsiz sertifikaların geçerlilik süresi kısa olduğu için yenileme sürecinin sorunsuz çalıştığından emin olmak, kurulum kadar önemlidir.
- cPanel’de AutoSSL’in etkin olduğunu ve son çalışma kaydında hata olmadığını kontrol edin.
- VPS’te Certbot veya benzeri bir araç kullanıyorsanız yenileme zamanlayıcısının çalıştığını ve
certbot renew --dry-runkomutunun hatasız tamamlandığını doğrulayın. - Yenilemeden sonra web sunucusunun yeni sertifikayı yüklemesi için yeniden yükleme (reload) adımının otomasyona dahil olduğundan emin olun.
- Sertifika bitiş tarihini izleyen basit bir uyarı kurun. Pek çok çalışma süresi izleme servisi, sertifikanın bitmesine belirli gün kala e-posta gönderebilir.
Alan adı taşıma, DNS sağlayıcısı değişikliği veya CDN etkinleştirme gibi işlemlerden sonra yenilemenin hâlâ çalışıp çalışmadığını mutlaka yeniden kontrol edin; doğrulama yöntemi bu değişikliklerden doğrudan etkilenir.
Son kontrol: her adresi tek tek test edin
Sorunu çözdüğünüzü düşündüğünüzde şu dört adresin her birinin tek adımda doğru ana adrese gittiğini doğrulayın:
http://alanadi.comhttp://www.alanadi.comhttps://alanadi.comhttps://www.alanadi.com
Ardından yalnızca ana sayfayı değil, giriş sayfası, iletişim formu, ödeme sayfası ve API çağrıları gibi kritik işlemleri ayrıca test edin. Ödeme sağlayıcıları ve harici servislerde tanımlı geri dönüş (callback, webhook) adreslerinin de HTTPS’e güncellenmesi gerekebilir. Google Search Console’da HTTPS mülkünün doğrulandığından ve site haritasının yeni adreslerle gönderildiğinden emin olun.
Sorun sürüyorsa hosting desteğine başvururken şu bilgileri birlikte iletin: alan adı, sorunun başladığı zaman, tarayıcıdaki hata kodu, openssl s_client çıktısı, curl -sIL çıktısı ve DNS kayıtlarınız. Bu bilgiler destek ekibinin sorunu doğrudan doğru katmanda aramasını sağlar.
Gerçekçi bir teşhis örneği
Paylaşımlı hostingden yeni bir sunucuya taşınan bir WordPress sitesini düşünelim. Taşımadan sonra AutoSSL ile sertifika kuruluyor; site yöneticinin bilgisayarında sorunsuz açılırken bazı kullanıcılar sertifika uyarısı, bazıları ise “çok fazla yönlendirme” hatası bildiriyor.
İlk adımda dig çıktısı A kaydının yeni sunucuyu gösterdiğini, ancak alan adında eski hostinge ait bir AAAA kaydının kaldığını ortaya koyuyor. IPv6 kullanan ziyaretçiler eski sunucuya gidiyor ve orada süresi dolmuş sertifikayla karşılaşıyor. AAAA kaydı kaldırılınca sertifika uyarısı birkaç saat içinde ortadan kalkıyor.
Yönlendirme hatası ise farklı bir katmandan geliyor: Alan adı Cloudflare üzerinden yayımlanıyor ve SSL modu Flexible olarak kalmış. Sunucudaki .htaccess kuralı HTTP isteklerini HTTPS’e yönlendirdiği için döngü oluşuyor. Sunucuda artık geçerli bir sertifika olduğundan mod Full (strict) yapılıyor ve curl -sIL çıktısında zincir tek bir 301 adımına iniyor. Son olarak WP-CLI ile veritabanındaki eski HTTP adresleri güncelleniyor ve önbellek temizleniyor.
Bu örnekte görüldüğü gibi “SSL sonrası site açılmıyor” şikâyetinin arkasında birbirinden bağımsız iki sorun olabilir. Her belirtiyi ayrı not edip katman katman ilerlemek, rastgele ayar değiştirmekten çok daha hızlı sonuç verir.
Sıkça Sorulan Sorular
SSL kurduktan sonra site neden bazı kişilerde açılıp bazılarında açılmıyor?
Genellikle DNS yayılımı veya eski bir AAAA (IPv6) kaydı nedeniyle ziyaretçilerin bir kısmı eski sunucuya gidiyordur. Farklı ağlardan test edin ve tüm DNS kayıtlarının yeni sunucuyu gösterdiğini doğrulayın.
Cloudflare kullanırken hangi SSL modunu seçmeliyim?
Sunucunuzda geçerli bir sertifika varsa Full (strict) modu önerilir. Flexible modu, sunucu tarafında HTTPS yönlendirmesi bulunan sitelerde yönlendirme döngüsüne yol açar ve sunucu ile Cloudflare arasındaki trafiği şifrelemez.
Mixed content sorunu SEO’yu etkiler mi?
Doğrudan bir sıralama cezası olarak düşünülmemelidir, ancak tarayıcıların engellediği kaynaklar sayfanın düzgün çalışmasını bozar ve kullanıcı deneyimini düşürür. Ayrıca güvenlik uyarısı gören ziyaretçilerin siteden ayrılma olasılığı artar.
Ücretsiz sertifika ile ücretli sertifika arasında güvenlik farkı var mı?
Şifreleme gücü açısından fark yoktur; her ikisi de aynı TLS protokollerini kullanır. Fark, doğrulama türü, garanti ve destek gibi hizmetlerdedir. Ücretsiz sertifikaların kısa geçerlilik süresi nedeniyle otomatik yenilemenin düzgün çalıştığını düzenli kontrol edin.
HTTPS’e geçtikten sonra Search Console’da ne yapmalıyım?
Alan adı mülkü kullanıyorsanız ek bir doğrulama gerekmez; URL öneki mülkü kullanıyorsanız https:// sürümünü ayrı mülk olarak ekleyin. Site haritasını HTTPS adresleriyle yeniden gönderin, birkaç önemli sayfayı URL Denetimi aracıyla kontrol edin ve sonraki haftalarda Sayfa Dizine Ekleme raporunda yönlendirme veya yinelenen sayfa uyarılarındaki değişimi izleyin.
Sertifika kurulumundan sonra site neden yavaşladı?
TLS el sıkışması ilk bağlantıya küçük bir ek süre getirir; ancak HTTP/2 veya HTTP/3 ile bu fark genellikle telafi edilir. Belirgin bir yavaşlama varsa birden fazla yönlendirme adımı, önbelleğin temizlenmesi veya OCSP doğrulamasında yaşanan gecikmeler gibi nedenleri inceleyin.
İlgili Rehberler
- WordPress’te SSL Handshake Failed Hatası Nasıl Çözülür?
- WordPress Cloudflare Kurulumu: Hız ve Güvenlik Rehberi
- 301 Yönlendirme SEO Açısından Nasıl Yapılır?
Kaynaklar ve İleri Okuma
