Yaygın SSL Sertifikası Hataları ve Çözümleri

Bir ziyaretçi sitenize girmeye çalıştığında tarayıcının tam ekran kırmızı bir uyarıyla karşılık vermesi kadar can sıkıcı bir şey azdır: "Bağlantınız gizli değil", "NET::ERR_CERT_COMMON_NAME_INVALID" ya da benzeri bir mesaj. Bu hatanın çoğu zaman tek bir sebebi vardır ve doğru araçla dakikalar içinde teşhis edilir. Bu rehberde tarayıcıların gösterdiği en yaygın SSL hatalarını tek tek ele alacağız: süresi dolmuş sertifika, alan adı uyuşmazlığı, eksik ara sertifika zinciri, karışık içerik (mixed content), güvenilmeyen sertifika otoritesi, sunucu saatinin yanlış olması ve HSTS'in kendinizi kilitlemesi. Her biri için hem teşhis komutlarını hem de kalıcı çözümü göreceksiniz.

SSL'in temel mantığını ve el sıkışmanın nasıl işlediğini bilmiyorsanız önce SSL sertifikası nedir yazımıza göz atmanız bu rehberi daha anlamlı kılacaktır.

Önce Teşhis: Hatanın Kaynağını Bulmak#

Bir SSL hatasını çözmeye çalışmadan önce hatanın gerçekte ne olduğunu netleştirmek gerekir; çünkü tarayıcı mesajları bazen belirsizdir ve yanlış tarafı düzeltmekle vakit kaybedebilirsiniz. İki araç işinizi büyük ölçüde görür.

1. Tarayıcı sertifika detayı. Adres çubuğundaki kilit (veya uyarı) simgesine tıklayıp "Sertifika" ya da "Bağlantı güvenli değil" detayına girin. Burada sertifikanın kime ait olduğu, hangi alan adlarını kapsadığı (Subject Alternative Name), geçerlilik tarihleri ve zincirin tamamı görünür.

2. OpenSSL komut satırı. Sunucudan bağımsız, tarayıcı önbelleğinden etkilenmeyen en güvenilir yöntem budur:

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com -showcerts

-servername bayrağını unutmayın; SNI (Server Name Indication) olmadan sunucu yanlış sertifikayı (ör. varsayılan sanal host'unkini) döndürebilir ve teşhisi yanıltabilir. Çıktının en üstünde Verify return code satırını arayın — 0 (ok) her şeyin yolunda olduğunu, farklı bir kod ise sorunun türünü gösterir.

Sertifikanın bitiş tarihini tek satırda görmek isterseniz:

echo | openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com 2>/dev/null \
  | openssl x509 -noout -dates

Bu iki komutu aklınızda tutarsanız aşağıdaki hataların neredeyse tamamını birkaç saniyede teşhis edebilirsiniz.

Süresi Dolmuş Sertifika (NET::ERR_CERT_DATE_INVALID)#

En sık karşılaşılan ve en basit çözümü olan hatadır. Sertifikaların bir geçerlilik süresi vardır — Let's Encrypt için 90 gün, ticari sertifikalarda genelde 1 yıl. Süre dolduğunda tarayıcı, sertifikanın artık güvenilir sayılamayacağını düşünür ve bağlantıyı engeller.

Yukarıdaki openssl x509 -noout -dates komutu size notBefore ve notAfter tarihlerini verir; notAfter geçmişte kalmışsa sorun kesinleşmiştir.

Kalıcı çözüm otomatik yenilemedir. Let's Encrypt kullanıyorsanız certbot zaten bir sistemd zamanlayıcısı veya cron görevi kurar; bunun gerçekten çalışıp çalışmadığını doğrulayın:

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

--dry-run gerçek bir yenileme yapmadan tüm süreci simüle eder; hata vermiyorsa otomasyon sağlamdır. Sertifika zaten dolmuşsa hemen yenileyin:

sudo certbot renew --force-renewal
sudo systemctl reload nginx

Yönetilen bir hosting paketinde SSL genelde otomatik yenilenir ve bu hatayı hiç görmezsiniz; kendi VDS veya sanal sunucunuzu yönetiyorsanız yenileme zamanlayıcısının gerçekten aktif olduğunu ayda bir kontrol etmek iyi bir alışkanlıktır.

Alan Adı Uyuşmazlığı (NET::ERR_CERT_COMMON_NAME_INVALID)#

Bu hata, sertifikanın adres çubuğundaki alan adı için geçerli olmadığını söyler. Tipik senaryolar:

• Sertifika yalnızca alanadi.com için alınmış ama site www.alanadi.com üzerinden ziyaret ediliyor (ya da tam tersi).
• Bir alt alan adı (panel.alanadi.com) için ayrı sertifika unutulmuş.
• Sunucuda birden fazla site barındırılıyor ve yanlış sertifika sunuluyor (SNI yapılandırma hatası).

Sertifikanın hangi adları kapsadığını görmek için:

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Çıktıda beklediğiniz alan adı yoksa sertifika yanlış adlarla alınmış demektir. Çözüm, sertifikayı hem kök alan adı hem de www sürümünü (gerekiyorsa diğer alt alan adlarını da) kapsayacak şekilde yeniden almaktır:

sudo certbot --nginx -d alanadiniz.com -d www.alanadiniz.com

Çok sayıda alt alan adınız varsa tek tek sertifika almak yerine bir wildcard sertifika (*.alanadiniz.com) düşünmeye değer; bu konuyu SSL sertifikası nedir yazımızın kapsam tipleri bölümünde detaylıca anlatıyoruz.

Birden fazla siteyi tek IP üzerinde barındıran Nginx sunucularında bu hata bazen sadece yanlış server_name eşleşmesinden kaynaklanır; ilgili server bloğunda server_name değerinin doğru yazıldığından ve doğru ssl_certificate dosyasına işaret ettiğinden emin olun.

Eksik Ara Sertifika (Chain) Hatası#

Bu, en sinsi hatalardan biridir çünkü masaüstü Chrome'da site sorunsuz açılırken mobil tarayıcılarda, bazı eski işletim sistemlerinde veya curl gibi komut satırı araçlarında "sertifika doğrulanamadı" hatası verir. Sebep, sunucunun yalnızca kendi sertifikasını sunup CA'nın ara sertifikasını (intermediate) göndermemesidir. Masaüstü tarayıcılar bu eksik halkayı bazen kendi önbelleğinden tamamlayabilir; ama çoğu istemci bunu yapmaz ve zincir kırılmış sayılır.

Teşhis için -showcerts bayrağıyla kaç sertifika döndüğüne bakın:

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com -showcerts 2>/dev/null \
  | grep "BEGIN CERTIFICATE" | wc -l

Sonuç 1 ise yalnızca kendi sertifikanız gönderiliyor demektir; sağlıklı bir kurulumda genelde en az 2 (kendi sertifikanız + ara sertifika) görmeniz gerekir.

Çözüm: kendi sertifikanızla CA'nın ara sertifikasını birleştirip tek bir fullchain dosyası olarak sunmaktır. Let's Encrypt / Certbot bunu zaten otomatik yapar (fullchain.pem dosyası tam zinciri içerir); elle kurulum yapıyorsanız sırayı doğru tutarak birleştirin:

cat alanadiniz.crt intermediate.crt > fullchain.crt

Nginx yapılandırmasında ssl_certificate yönergesinin kendi sertifikanıza değil, bu birleşik fullchain dosyasına işaret ettiğinden emin olun:

ssl_certificate     /etc/letsencrypt/live/alanadiniz.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/alanadiniz.com/privkey.pem;

Değişiklikten sonra yapılandırmayı test edip yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Zincirin artık tam olduğunu, ücretsiz bir üçüncü taraf SSL test aracıyla (arama motorunda "SSL sunucu testi" ile bulabileceğiniz araçlar) veya yukarıdaki -showcerts komutuyla doğrulayabilirsiniz.

Karışık İçerik (Mixed Content)#

Sertifika tamamen sağlam olduğu halde adres çubuğunda kilit yerine bir uyarı üçgeni görüyorsanız sorun büyük ihtimalle karışık içeriktir: HTTPS ile yüklenen sayfanın içinde hâlâ http:// üzerinden çağrılan görsel, CSS, font veya JavaScript bulunması. Tarayıcı bu güvensiz kaynakları ya sessizce engeller ya da sayfayı "tam güvenli değil" olarak işaretler.

Kaynağı bulmak için tarayıcı geliştirici araçlarını (F12) açıp Console sekmesine bakın; "Mixed Content" ile başlayan her satır hangi dosyanın HTTP üzerinden geldiğini tam olarak söyler.

WordPress sitelerinde en sık rastlanan durum, veritabanındaki eski yazılarda veya tema ayarlarında sabitlenmiş http:// bağlantılardır:

UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://alanadiniz.com', 'https://alanadiniz.com');

Bu komut yalnızca yazı gövdesindeki düz bağlantıları düzeltir; tema ayarları ve bazı eklentiler veriyi serileştirilmiş biçimde sakladığı için ham REPLACE orada veri bozabilir — böyle durumlarda serileştirmeye duyarlı bir arama-değiştirme aracı kullanmanız gerekir. Karışık içerik ve genel HTTPS geçişini uçtan uca HTTP'den HTTPS'e yönlendirme rehberimizde daha ayrıntılı işledik.

Güvenilmeyen Sertifika Otoritesi (NET::ERR_CERT_AUTHORITY_INVALID)#

Bu hata tarayıcının sertifikayı imzalayan otoriteyi tanımadığını söyler. En yaygın nedenleri:

• Kendinden imzalı (self-signed) sertifika kullanılıyor — geliştirme ortamları için normaldir ama canlı bir site için tarayıcılar bunu asla güvenilir kabul etmez.
• Yukarıda anlatılan eksik ara sertifika zinciri — bazı istemciler bunu "authority invalid" olarak da raporlayabilir.
• Sertifika, artık güvenilir kök listesinden çıkarılmış eski bir CA tarafından verilmiş (nadir ama olur; büyük CA'lar kök değişikliklerini önceden duyurur).

Kendinden imzalı bir sertifikayla mı karşı karşıya olduğunuzu görmek için openssl x509 -noout -issuer -subject çıktısında Issuer ile Subject alanlarının aynı olup olmadığına bakın — aynıysa sertifika kendi kendini imzalamış demektir:

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject

Çözüm canlı ortamda her zaman tanınan bir CA'dan (Let's Encrypt dahil) gerçek bir sertifika almaktır; kendinden imzalı sertifikalar yalnızca yerel test ortamlarında kullanılmalıdır.

Sunucu Saati Yanlışsa#

Az bilinen ama şaşırtıcı derecede yaygın bir sebep: sunucunun sistem saati. TLS el sıkışması sırasında istemci, sertifikanın notBefore/notAfter aralığını kendi saatiyle karşılaştırır. Sunucunuzun saati birkaç gün ileri veya geriyse — özellikle sanal makine saat senkronizasyonu bozulduğunda olur — sertifika henüz "geçerli değil" ya da "süresi dolmuş" gibi görünebilir; oysa sertifikanın kendisinde hiçbir sorun yoktur.

Sunucu saatini kontrol edin:

date -u
timedatectl status

NTP synchronized: no görüyorsanız zaman senkronizasyonu etkin değildir. Çoğu Linux dağıtımında düzeltmek tek komuttur:

sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd

Bu adımdan sonra timedatectl status çıktısında System clock synchronized: yes görmelisiniz. İlginç şekilde bu hata bazen yalnızca istemci (ziyaretçinin bilgisayarı) tarafında da yaşanır — kullanıcının kendi cihaz saati yanlışsa sizin sertifikanız kusursuz olsa bile hata alır; destek talebi geldiğinde bu ihtimali de sorgulamakta fayda var.

HSTS Kilitlenmesi#

HSTS (HTTP Strict Transport Security) başlığını etkinleştirdikten sonra bir sorun yaşarsanız (sertifika süresi dolar, yanlışlıkla siler ya da yanlış yapılandırırsanız) kendinizi ilginç bir kısır döngüde bulabilirsiniz: tarayıcı, max-age süresi boyunca o alan adına hiç HTTP ile bağlanmayı denemez ve olağan "devam et" seçeneğini bile göstermez — kilit doğrudan bloklar.

Bunun tipik belirtisi şudur: sertifikanızı yeniden kurdunuz, her şey sunucu tarafında düzgün görünüyor, ama tarayıcı hâlâ eski bir hatayı ya da bağlantı reddini gösteriyor. Sorun sunucuda değil, tarayıcının önbelleğindeki HSTS kaydında olabilir.

Test için önce sunucu tarafını curl ile doğrulayın (tarayıcı önbelleğinden tamamen bağımsız çalışır):

curl -I https://alanadiniz.com

Beklenen 200 veya 301 dönüyorsa sunucu sorunsuzdur; sorun istemci tarafındadır. Chrome'da bunu chrome://net-internals/#hsts sayfasından ilgili alan adını "Delete domain security policies" ile temizleyerek çözebilirsiniz.

Önlem, tedaviden kolaydır. HSTS'i etkinleştirmeden önce:

1. HTTPS'in ve tüm yönlendirmelerin sorunsuz çalıştığından emin olun.
2. Karışık içeriği tamamen temizleyin.
3. Önce kısa bir max-age (ör. max-age=300, 5 dakika) ile test edin.
4. Sorun çıkmadığından emin olduktan sonra süreyi bir yıla (max-age=31536000) çıkarın.

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

includeSubDomains eklemeden önce tüm alt alan adlarınızın HTTPS sunduğunu doğrulayın; unutulan bir alt alan adı bu başlık yüzünden erişilemez hale gelebilir. HSTS'in ayrıntılarını ve kademeli geçiş stratejisini HTTP'den HTTPS'e yönlendirme rehberimizde bulabilirsiniz.

Hızlı Teşhis Tablosu#

Sıkça Sorulan Sorular#

Sertifikamı yeniledim ama tarayıcı hâlâ eski hatayı gösteriyor, neden?#

Büyük ihtimalle tarayıcı önbelleği veya HSTS kaydı devrede. Önce curl -I https://alanadiniz.com ile sunucu tarafını doğrulayın; sunucu doğru cevap veriyorsa gizli sekmede veya farklı bir cihazda test edin. Hâlâ hata görüyorsanız chrome://net-internals/#hsts üzerinden alan adının HSTS kaydını temizleyin.

Chrome'da sorunsuz açılan sitem neden telefonda "güvenli değil" diyor?#

Bu neredeyse her zaman eksik ara sertifika (chain) sorunudur. Masaüstü tarayıcılar eksik zinciri bazen kendi önbelleğinden tamamlayabilirken mobil işletim sistemleri ve çoğu komut satırı aracı bunu yapmaz. openssl s_client -showcerts ile kaç sertifika döndüğünü kontrol edin ve fullchain dosyanızı yeniden oluşturun.

Sertifikayı yeni aldım ama hâlâ "henüz geçerli değil" hatası alıyorum, sorun sertifikada mı?#

Genelde değil. Sunucunuzun sistem saatinin yanlış olma ihtimali yüksektir; timedatectl status ile NTP senkronizasyonunun aktif olduğunu doğrulayın. Nadiren sorun ziyaretçinin kendi cihaz saatinden de kaynaklanabilir.

Karışık içerik hatasını nasıl en hızlı bulurum?#

Tarayıcıda F12 ile geliştirici araçlarını açıp Console sekmesine bakın; "Mixed Content" ile başlayan satırlar hangi görsel, betik veya CSS dosyasının hâlâ http:// üzerinden çağrıldığını tam olarak gösterir. WordPress'te bu genelde eski yazı içeriklerinde veya serileştirilmiş tema ayarlarında sabitlenmiş bağlantılardır.

HSTS'i etkinleştirdim ama şimdi siteme hiç giremiyorum, ne yapmalıyım?#

Önce sertifikanızın ve HTTPS yapılandırmanızın gerçekten sağlıklı çalıştığından emin olun (curl -I ile). Sorun devam ediyorsa max-age süresi dolana kadar beklemeniz ya da etkilenen ziyaretçilerin tarayıcısından o alan adının HSTS kaydını manuel silmesi gerekir; bu yüzden HSTS'i her zaman kısa bir max-age ile test ederek başlatmak önemlidir.

Wildcard sertifikam var ama bir alt alan adında hâlâ uyuşmazlık hatası alıyorum, neden?#

Wildcard sertifikalar (*.alanadiniz.com) yalnızca tek seviye alt alan adlarını kapsar; blog.alanadiniz.com geçerliyken a.blog.alanadiniz.com gibi iki seviye aşağıdaki adlar kapsam dışı kalır. Ayrıca kök alan adının (alanadiniz.com, wildcard'sız) kendisi de ayrıca eklenmiş olmalıdır — bazı CA'lar bunu otomatik eklemez.

SSL hatalarının büyük çoğunluğu birkaç dakikalık bir openssl komutuyla teşhis edilip yine birkaç dakikada çözülür; asıl önemli olan panik yapmadan doğru sırayla ilerlemektir. Sertifika yönetimini ve otomatik yenilemeyi hiç düşünmeden, yönetilen bir altyapıda halletmek isterseniz SSL çözümlerimizi ve hosting paketlerimizi inceleyebilirsiniz.