Bağlantınız Gizli Değil Hatası: Site Sahibi Ne Yapmalı?

Bir müşteriniz arayıp "sitenize giremiyorum, kırmızı bir ekran çıkıyor" dediğinde ya da kendi sitenizi açtığınızda karşınıza tam ekran bir uyarı geldiğinde gördüğünüz şey büyük ihtimalle şudur: Bağlantınız gizli değil. Chrome bu metni Türkçe gösterdiği için ifade birebir arama kutusuna yazılıyor ve karşınıza çıkan içeriklerin neredeyse tamamı ziyaretçiye hitap ediyor: saatinizi düzeltin, önbelleği temizleyin, "Gelişmiş" deyip yine de devam edin. Sitenin sahibi sizseniz bunların hiçbiri işinize yaramaz. Daha kötüsü, ziyaretçiye "yine de devam et"i öğretmek doğrudan zararınızadır — o düğmeye basmayı öğrenen kullanıcı bir sonraki sefer gerçek bir saldırıda da basacaktır.

Bu yazı tamamen site sahibi tarafından yazıldı. Uyarının hangi hata koduyla geldiğini okumayı, sorunun sizde mi ziyaretçide mi olduğunu ilk beş dakikada kesinleştirmeyi, sertifika süresi / alan adı uyuşmazlığı / eksik ara sertifika / yanlış sanal host gibi somut nedenleri sırayla elemeyi ve hepsinden önemlisi bu uyarının bir daha çıkmaması için otomatik yenileme ve izleme kurmayı anlatıyor. Yıllardır gördüğüm dağılım şu: vakaların yarısından fazlası "sertifika süresi doldu, otomatik yenileme sessizce durmuştu", geri kalanın büyük kısmı da "sertifika var ama ara sertifika sunulmuyor" ya da "www hariç tutulmuş". Üçünün de teşhisi tek komutla yapılır.

"Bağlantınız Gizli Değil" Uyarısı Ne Anlama Gelir#

Bu uyarı, tarayıcının sunucunuzla TLS el sıkışmasını tamamladığını ama sunulan sertifikaya güvenmediğini söyler. Yani bağlantı kurulmuştur, şifreleme çalışıyordur; sorun kimlik doğrulamasındadır. Tarayıcı üç soruya cevap arar: bu sertifika hâlâ geçerli mi, adres çubuğundaki alan adını kapsıyor mu, ve güvenilen bir kök sertifika otoritesine kadar uzanan bir zinciri var mı? Bu üç sorudan biri "hayır" derse tam ekran uyarı gelir.

Bu ayrım önemli, çünkü uyarıyı "SSL çalışmıyor" diye özetlerseniz yanlış yerde ararsınız. Sunucu 443 portunda dinlemiyorsa ya da protokol düzeyinde anlaşma olmuyorsa bu uyarı değil, ERR_SSL_PROTOCOL_ERROR hatası çıkar. Sertifikanın kendisiyle ilgili temel kavramları hiç oturtmadıysanız önce SSL sertifikası nedir yazısını okumanız, buradaki adımların neden bu sırada olduğunu netleştirir.

Uyarı ekranının kendisi de bilgi taşır. Chrome'da "Gelişmiş" bağlantısına tıkladığınızda metnin altında NET::ERR_CERT_... biçiminde bir kod görürsünüz. Teşhis oradan başlar; kodu okumadan yapılan her müdahale tahmindir.

Uyarı Ekranındaki Hata Kodunu Okuyun#

Her hata kodu farklı bir nedeni işaret eder ve çözümleri birbirine benzemez. Ekrandaki kodu not alın, sonra tabloda karşılığına bakın.

Tarayıcıya güvenmek yerine kaynaktan doğrulamak isterseniz, sunucunun gerçekte ne sunduğunu tek komutla görebilirsiniz:

openssl s_client -connect ornekalanadi.com:443 -servername ornekalanadi.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Çıktıda dört şeye bakın: subject (kimin için düzenlenmiş), issuer (kim düzenlemiş), notBefore/notAfter (geçerlilik aralığı) ve subjectAltName (kapsanan alan adları). Bu dört satır, yukarıdaki tablodaki kodların hepsini doğrulamanıza yeter.

Sorun Sizde mi Ziyaretçide mi: Beş Dakikalık Ayrım#

Önce şunu kesinleştirin: uyarıyı herkes mi görüyor, yoksa tek bir kullanıcı mı. Bu ayrım yapılmadan yapılan sunucu müdahaleleri boşa emektir.

Sunucu tarafından, kendi tarayıcınızdan ve kendi ağınızdan bağımsız bir test yapın:

curl -sSI https://ornekalanadi.com | head -n 1

Bu komut sunucudan HTTP durum satırını sorunsuz getiriyorsa sertifika curl açısından geçerlidir. Hata veriyorsa mesaj doğrudan nedeni söyler:

curl: (60) SSL certificate problem: certificate has expired
curl: (60) SSL certificate problem: unable to get local issuer certificate

İkinci satır özellikle kıymetlidir: "unable to get local issuer certificate" neredeyse her zaman eksik ara sertifika demektir ve bu, Chrome'da görünmeyip Android uygulamalarında, Java istemcilerde ve bazı mobil tarayıcılarda patlayan sinsi bir hatadır.

Eğer curl temiz dönüyorsa ve uyarıyı yalnızca bir kişi görüyorsa, o kullanıcı tarafındaki olası nedenler şunlardır: cihaz saatinin ileri/geri kayması, kurumsal ağdaki TLS denetleyen bir güvenlik duvarı, antivirüs yazılımının HTTPS taraması, ya da ücretsiz Wi-Fi ağlarındaki giriş portalı. Bu durumda sizin sunucunuzda yapılacak bir şey yoktur; kullanıcıya cihaz saatini kontrol ettirmek ve farklı bir ağdan denemesini istemek yeterlidir.

Sertifika Süresi Doldu: En Yaygın Neden#

ERR_CERT_DATE_INVALID görüyorsanız sorunun tek nedeni neredeyse her zaman otomatik yenilemenin sessizce durmuş olmasıdır. Let's Encrypt sertifikaları 90 gün geçerlidir ve yenileme genellikle 60. günde denenir; yani otomasyon bozulduktan sonra sitenizin 30 gün boyunca hiçbir belirti vermeden çalışmaya devam etmesi normaldir. Uyarı geldiğinde arıza bir aylıktır.

Certbot kullanan bir sunucuda önce durumu görün:

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

--dry-run çıktısı en öğretici olanıdır. Yenilemenin neden başarısız olduğunu doğrudan yazar; en sık gördüğüm üç sebep şunlar: HTTP-01 doğrulaması için /.well-known/acme-challenge/ dizinine gelen isteğin bir yönlendirme kuralı tarafından yakalanması, 80 portunun güvenlik duvarında kapatılmış olması, ve alan adının artık bu sunucuya bakmıyor olması (DNS taşınmış ama sertifika eski sunucuda yenilenmeye çalışıyor).

cPanel'li bir paylaşımlı hostingteyseniz iş daha basittir: AutoSSL genellikle kendi başına yeniler, ama alan adı Cloudflare arkasındaysa ya da DNS başka bir yerdeyse doğrulama başarısız olur. cPanel → SSL/TLS Status ekranında alan adının yanındaki "Run AutoSSL" düğmesiyle yenilemeyi elle tetikleyip çıkan hata mesajını okuyun. Bütünüyle temiz bir kurulum yapmak isterseniz Let's Encrypt ücretsiz SSL yazısındaki adımlar sizi baştan sona götürür.

Bir de klasik tuzak var: sunucu saati. Sanal makinelerde NTP kapalıysa saat aylarca kayabilir ve tamamen geçerli bir sertifika "henüz başlamamış" görünebilir. timedatectl çıktısında System clock synchronized: yes yazdığını doğrulayın.

Alan Adı Eşleşmiyor: www, Alt Alan Adı ve Wildcard#

ERR_CERT_COMMON_NAME_INVALID, sertifikanın adres çubuğundaki tam alan adını kapsamadığını söyler. Sertifika ornekalanadi.com için düzenlenmiş ama ziyaretçi www.ornekalanadi.com yazmışsa uyarı çıkar; ikisi tarayıcı için farklı iki isimdir.

Kapsanan isimleri görmek için:

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

Çıktıda hem DNS:ornekalanadi.com hem DNS:www.ornekalanadi.com görmeniz gerekir. Yoksa sertifikayı iki ismi de kapsayacak şekilde yeniden düzenletin. Certbot'ta bu tek satırdır:

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

Alt alan adları için ayrı bir tuzak var: blog.ornekalanadi.com ya da panel.ornekalanadi.com gibi adresler, ana alan adının sertifikasına dahil edilmedikçe kapsanmaz. Çok sayıda alt alan adınız varsa wildcard SSL mantığını kurmak, her yeni alt alan adında aynı sorunu tekrar yaşamanızı önler. Ancak wildcard sertifikanın da bir sınırı vardır: *.ornekalanadi.com yalnızca bir seviyeyi kapsar, a.b.ornekalanadi.com kapsam dışıdır.

Ara Sertifika Eksik: Chrome'da Görünmeyen Hata#

Bu, listedeki en yanıltıcı arızadır: sizde sorun görünmez, kullanıcılarınızın bir kısmında görünür. Nedeni şu — modern masaüstü tarayıcılar eksik ara sertifikayı çoğu zaman kendi önbelleklerinden ya da AIA alanından tamamlar; Android WebView, eski cihazlar, Java tabanlı istemciler ve ödeme sağlayıcılarının sunucu-sunucu çağrıları tamamlamaz. Sonuç: sitenize masaüstünden girenler sorun görmez, mobil uygulamadan gelenler "güvenli bağlantı sağlanamıyor" der ve ödeme entegrasyonunuz sessizce başarısız olur.

Zincirin gerçekten sunulup sunulmadığını şöyle görürsünüz:

openssl s_client -connect ornekalanadi.com:443 -servername ornekalanadi.com </dev/null 2>/dev/null \
  | grep -E "^(Certificate chain| [0-9] s:| [0-9] i:)"

Sağlıklı bir çıktıda en az iki seviye görürsünüz: 0 s: sizin sertifikanız, 1 s: ara sertifika. Yalnızca 0 varsa zincir eksiktir. Nginx'te çözüm, ayrı duran sertifika ve ara sertifika dosyalarını doğru sırayla birleştirip tek dosya olarak vermektir:

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

    # fullchain: önce sunucu sertifikası, sonra ara sertifikalar
    ssl_certificate     /etc/ssl/ornekalanadi/fullchain.pem;
    ssl_certificate_key /etc/ssl/ornekalanadi/privkey.pem;
}

En sık yapılan hata ssl_certificate satırına cert.pem (yalnız sunucu sertifikası) yazmaktır; oraya fullchain.pem yazılmalıdır. Apache tarafında ise ayrı SSLCertificateChainFile direktifi kullanılır; ayrıntılı yapılandırma için Apache SSL yapılandırma yazısına bakın. Konunun teorisi için sertifika zinciri nedir ve ara sertifika hatası yazıları da doğrudan bu problemi ele alır.

Sunucu Yanlış Sertifikayı Sunuyor Olabilir#

Bazen sertifika doğru, süresi geçerli, zinciri tam — ama sunucu o siteye başka bir sertifikayı veriyordur. Bu, aynı IP üzerinde birden fazla site barındıran sunucularda olur: istenen alan adı için tanımlı bir sanal host yoksa web sunucusu ilk tanımlı sanal hostun sertifikasını sunar ve tarayıcı doğal olarak "bu sertifika bu site için değil" der.

Test etmenin kesin yolu, -servername parametresini kaldırıp bir kez daha bakmaktır:

# SNI ile (tarayıcının yaptığı)
openssl s_client -connect 203.0.113.10:443 -servername ornekalanadi.com </dev/null 2>/dev/null | openssl x509 -noout -subject

# SNI olmadan (varsayılan vhost)
openssl s_client -connect 203.0.113.10:443 </dev/null 2>/dev/null | openssl x509 -noout -subject

İki çıktı aynıysa ve ikisi de yanlış alan adını gösteriyorsa, o alan adı için 443 portunda bir sanal host tanımı yoktur. Nginx'te nginx -T | grep -n "server_name" ile tüm tanımları listeleyip alan adınızın gerçekten bir listen 443 ssl bloğunda olduğunu doğrulayın. Apache'de apachectl -S aynı işi görür.

Aynı arıza Cloudflare gibi bir ara katman kullanıyorsanız farklı bir kılıkta gelir: proxy açıkken ziyaretçi Cloudflare'in sertifikasını görür, kapattığınızda origin sunucunun sertifikasını. Origin'de sertifika hiç yokken proxy'yi kapatırsanız uyarı bir anda ortaya çıkar.

Ziyaretçiye "Yine de Devam Et" Dedirtmek Neden Zarar Verir#

Bu uyarıyı gören bir site sahibinin en kolay refleksi, müşteriye "Gelişmiş'e tıklayıp devam edin" demektir. Kısa vadede sorunu kapatır, uzun vadede üç şeyi bozar.

Birincisi, uyarıyı tıklayarak geçen kullanıcıya bir alışkanlık kazandırmış olursunuz; aynı kullanıcı gerçek bir ortadaki adam saldırısında da aynı düğmeye basar. İkincisi, uyarıyı geçen kullanıcıların büyük çoğunluğu geçmez — sekmeyi kapatır. E-ticaret sitesinde bu doğrudan kayıp siparişdir ve analitikte "yüksek çıkış oranı" olarak görünür, gerçek nedeni göremezsiniz. Üçüncüsü, arama motorları HTTPS'i sıralama sinyali olarak kullanır ve sertifika hatası veren sayfaların taranması aksar; uyarı günlerce sürerse organik trafikte gözle görülür bir düşüş yaşarsınız.

Doğru yaklaşım, uyarıyı bir vaka gibi ele alıp süreyi dakikalarla ölçmektir. Sertifika yenilenene kadar siteyi geçici olarak HTTP üzerinden servis etmek de çözüm değildir; HTTPS yönlendirme ve HSTS aktifse tarayıcı zaten HTTP'ye düşmeyi reddeder.

Uyarı Bir Daha Çıkmasın: Otomasyon ve İzleme#

Sertifika arızalarının neredeyse tamamı önlenebilir, çünkü hepsinin bir son kullanma tarihi vardır ve o tarih baştan bellidir. Yapılması gereken üç şey var.

1. Yenilemeyi otomatikleştirin. Certbot'ta systemd timer'ının aktif olduğunu, cPanel'de AutoSSL'in ilgili alan adını kapsadığını doğrulayın. Ayrıntılar için SSL otomatik yenileme yazısına bakın.
2. Yenilemenin başarısını izleyin, çalıştığını varsaymayın. Timer'ın çalışması yenilemenin başarılı olduğu anlamına gelmez. Aylık olarak certbot certificates çıktısındaki VALID: xx days satırına bakın ya da bir uptime izleme aracına sertifika son kullanma kontrolü ekleyin.
3. Dışarıdan doğrulayın. Sunucudan bakmak yanıltıcıdır çünkü zincir yerel depodan tamamlanabilir. Ayda bir dış bir noktadan tam denetim yapın; SSL Labs testi zincir eksikliğini, protokol sürümlerini ve zayıf şifre takımlarını tek raporda gösterir.

Bunlara ek olarak, sertifika kurulumundan sonra sayfa içindeki http:// ile başlayan kaynakları da temizleyin. Bunlar tam ekran uyarı vermez ama kilit simgesini kırar ve kullanıcıda aynı güvensizliği yaratır; konu mixed content hatası başlığında ayrıca ele alınıyor.

Sıkça Sorulan Sorular#

Bağlantınız gizli değil hatası sitemin hacklendiği anlamına mı gelir#

Hayır, bu uyarı tek başına bir saldırı belirtisi değildir. Vakaların ezici çoğunluğunda neden sertifikanın süresinin dolması veya yanlış kurulmasıdır. Ancak tek bir istisna vardır: ERR_CERT_REVOKED kodunu görüyorsanız sertifika otoritesi sertifikanızı iptal etmiş demektir ve bunun en sık nedeni özel anahtarın sızdığının tespit edilmesidir. O durumda yeni bir anahtar çifti üretip sertifikayı sıfırdan almanız ve sunucudaki olası ele geçirmeyi araştırmanız gerekir.

Sitem HTTPS ile açılıyor ama bazı kullanıcılar uyarı görüyor, neden#

Bu tablonun tek bir tipik nedeni vardır: ara sertifika eksiktir. Masaüstü tarayıcılar eksik zinciri kendi kaynaklarından tamamlayabildiği için sizde sorun görünmez, ama eski Android cihazlar, uygulama içi tarayıcılar ve sunucu-sunucu entegrasyonları tamamlayamaz. Sunucudan curl -sSI https://alanadiniz.com çalıştırdığınızda "unable to get local issuer certificate" görüyorsanız teşhis kesinleşmiştir. Çözüm, web sunucusuna sertifikayı fullchain biçiminde vermektir.

Sertifikayı yeniledim ama uyarı hâlâ devam ediyor#

Yenilenen sertifikanın diske yazılması, web sunucusunun onu belleğe alması anlamına gelmez. Nginx ve Apache sertifikayı başlangıçta okur; yenilemeden sonra sudo systemctl reload nginx ya da sudo systemctl reload apache2 çalıştırmadan eski sertifika sunulmaya devam eder. Yeniden yükledikten sonra hâlâ eski tarihleri görüyorsanız, sunucunun birden fazla sanal hostunda ayrı sertifika yolları tanımlı olabilir; nginx -T | grep ssl_certificate ile hepsini listeleyip güncellenmemiş olanı bulun.

Cloudflare kullanıyorum, sertifikayı yine de sunucuma kurmam gerekir mi#

Evet, gerekir. Cloudflare'in "Full (strict)" SSL modunda origin sunucunuzda geçerli bir sertifika bulunması zorunludur; aksi halde ziyaretçi Cloudflare'in sertifikasını görse bile Cloudflare ile sunucunuz arasındaki bacak kopar ve 5xx hataları başlar. "Flexible" modda sunucuda sertifika istenmez ama bu mod, Cloudflare ile sunucunuz arasındaki trafiği şifresiz bırakır ve yönlendirme döngülerine yol açar. Doğru kurulum, origin'e ücretsiz bir sertifika kurup Full (strict) modunda çalışmaktır.

Ziyaretçinin bilgisayar saati yanlışsa ben ne yapabilirim#

Sunucu tarafında yapabileceğiniz bir şey yoktur, çünkü tarayıcı sertifikanın geçerlilik aralığını kendi sistem saatiyle karşılaştırır. Cihaz saati aylarca ileri veya geri kaymışsa tamamen sağlıklı bir sertifika bile geçersiz görünür. Tek kişide görülen ve sunucudan yapılan testlerin temiz döndüğü vakalarda ilk sorulacak soru budur; kullanıcıdan tarih ve saati otomatik ayara almasını istemek çoğu zaman sorunu anında kapatır.

Ücretsiz sertifika kullandığım için mi bu uyarı çıkıyor#

Hayır, ücretsiz ve ücretli sertifikalar arasında tarayıcı güveni açısından hiçbir fark yoktur. Uyarı, sertifikanın fiyatından değil geçerlilik süresinden, kapsadığı alan adlarından ve zincirinin tamlığından kaynaklanır. Ücretli sertifikaların getirdiği farklar kurumsal kimlik doğrulama seviyesi, garanti tutarı ve destek gibi başlıklardadır. Ücretsiz sertifikaların 90 günlük kısa ömrü bir dezavantaj gibi görünse de otomatik yenileme kurulduğunda bu süre tamamen görünmez hale gelir.

Sertifika geçerli görünüyor ama tarayıcı hâlâ güvenmiyor, başka ne olabilir#

Sunucunun yanlış sanal hostu sunması ihtimalini kontrol edin. Aynı IP üzerinde birden fazla site varsa ve alan adınız için 443 portunda bir tanım yoksa, sunucu ilk tanımlı sitenin sertifikasını verir; sertifika kendi başına geçerlidir ama sizin alan adınızı kapsamaz. openssl s_client komutunu -servername parametresiyle ve parametresiz olarak iki kez çalıştırıp subject satırlarını karşılaştırmak bu durumu net biçimde ortaya çıkarır.

Kapanış#

"Bağlantınız gizli değil" uyarısı, sunucunuzun bozulduğunu değil tarayıcının sunulan kimliğe güvenmediğini söyler ve bunun yalnızca üç ana sebebi vardır: süre dolmuştur, alan adı kapsanmamıştır ya da zincir eksiktir. Ekrandaki NET::ERR_CERT_... kodunu okumak, ardından sunucudan openssl s_client ve curl -sSI ile doğrulamak, bu üçünü on dakikada birbirinden ayırır. Uyarıyı ziyaretçiye "devam et" dedirterek geçiştirmek yerine kapatın; her geçen saat hem satış hem arama görünürlüğü açısından ölçülebilir bir kayıptır. Kalıcı çözüm ise tek bir kurala indirgenebilir: yenilemeyi otomatikleştirin, ama otomatiğin çalıştığını varsaymayıp ayda bir dışarıdan doğrulayın.

Bu döngüyü kendiniz kurmak istemiyorsanız, sertifikanın kurulumunu ve yenilenmesini üstlenen bir altyapıda çalışmak en pratik yoldur. SSL sertifikası sayfasındaki seçenekler alan adı, wildcard ve kurumsal doğrulama ihtiyaçlarını kapsıyor; sertifikanın otomatik kurulup yenilendiği bir ortam arıyorsanız web hosting paketleri bu işi panel üzerinden hallediyor. Kendi sunucunuzu yönetiyor ama sertifika, güvenlik duvarı ve yenileme otomasyonunu devretmek istiyorsanız sunucu yönetimi hizmetine, sitenizi mevcut sağlayıcıdan taşırken sertifikanın da sorunsuz gelmesini istiyorsanız site taşıma sayfasına göz atabilirsiniz.