SSL Sertifika Hataları: Nedenleri ve Çözümleri

SSL sertifikası yüklü olduğu halde tarayıcıda “Not Secure”, bağlantı hatası veya “Mixed Content” uyarısı görülebilir. Sorun; sayfanın HTTP ile açılması, sertifikanın alan adıyla eşleşmemesi, ara sertifikaların eksik olması ya da uygulamanın HTTP kaynakları üretmesi olabilir. Tanıya, hatanın görüldüğü tam URL ve tarayıcının verdiği mesajla başlayın.

Bu rehber, SSL sertifika hatalarını ve mixed content sorunlarını hosting ve uygulama katmanında teşhis etmek için bir kontrol sırası sunar. Apache/Nginx yönlendirmeleri, WordPress URL ayarları, sertifika zinciri, TLS ve HSTS yapılandırmasını birlikte ele alır. Önce HTTPS bağlantısını doğrulayın; ardından yönlendirmeleri ve sayfanın yüklediği kaynakları kontrol edin.

SSL ve HTTPS uyarıları hangi sorunları gösterir?

Tarayıcıların kullandığı simgeler ve hata metinleri sürüme göre değişir. Teşhis için şu durumları birbirinden ayırın:

• HTTP üzerinden açılan sayfanın şifrelenmemiş bağlantısı,
• HTTPS kurulurken reddedilen sertifika veya sertifika zinciri,
• HTTPS sayfasındaki HTTP kaynaklarının yükseltilmesi ya da engellenmesi,
• İstemci ile sunucunun desteklediği TLS sürümü veya şifre takımlarının uyuşmaması.

Tek bir kilit rengi, bu nedenlerden hangisinin geçerli olduğunu göstermez; ayrıntılı hata ve ağ isteğini incelemek gerekir.

Ödeme, giriş veya kullanıcı verisi içeren sayfalarda bağlantı hatası işlemi kesintiye uğratabilir. HTTPS’in çalışması, sitenin bütün güvenlik kontrollerinin tamamlandığı veya arama sıralamasının yükseleceği anlamına gelmez. Temel kavramlar için SSL sertifikası rehberine; belirli bir hatayı çözmek için aşağıdaki kontrollerin ilgili bölümüne başvurabilirsiniz.

Tarayıcı uyarılarını doğru okumak

Önce tarayıcının verdiği mesajları doğru anlamak gerekiyor. Çünkü her “Not Secure” aynı kökten kaynaklanmıyor ve çözüm de ona göre değişiyor.

En sık görülen uyarı tipleri

• HTTP sayfasında “Not Secure”: Açılan URL HTTP kullanıyordur. HTTPS bağlantısını doğruladıktan sonra uygun yönlendirmeyi kurun.
• Sertifika hata sayfası: Süre, alan adı eşleşmesi, güvenilmeyen sertifika otoritesi veya eksik zincir gibi nedenleri kontrol edin.
• Mixed content: HTTPS sayfasının yüklemeye çalıştığı HTTP kaynakları geliştirici araçlarında görünür; tarayıcı kaynağı yükseltebilir veya engelleyebilir.
• TLS bağlantı hatası: Protokol ve şifre takımı desteğini kontrol edin. Eski TLS sürümleri yalnızca bir uyarıya değil, bağlantının kurulamamasına da neden olabilir.

Sertifika süresiyle ilgili bir hatada yalnızca yenileme günlüğüne bakmayın: yeni sertifikanın ilgili sunucuya veya CDN katmanına dağıtıldığını da doğrulayın. Mixed content için ise uygulamanın ürettiği kaynak URL’lerini ve varsa reverse proxy arkasındaki HTTPS algısını inceleyin.

SSL varken bile neden “Not Secure” görebilirsiniz?

HTTPS kurulmuş olsa bile güvenlik uyarılarına yol açabilen nedenler:

• Yanlış host adına kesilmiş sertifika: Sertifika www.ornek.com için alınmış ama siteyi https://ornek.com üzerinden açıyorsunuz (veya tam tersi).
• Sertifika zinciri eksik: Sunucuda sadece sunucu sertifikası yüklenmiş, ara sertifikalar (intermediate) eksik.
• Mixed content: HTML HTTPS üzerinden, bazı gömülü kaynaklar ise HTTP üzerinden çağrılıyor.
• Eski TLS yapılandırması: Tarayıcı, kullanılan şifre takımlarını veya protokol sürümünü artık kabul etmiyor.

DNS, sertifika ve sunucu yapılandırmasını ayrı ayrı kontrol etmek tanıyı daraltır. Daha ayrıntılı protokol ve HSTS ayarları için TLS 1.3 ve modern şifreler rehberine bakabilirsiniz; örnekleri kurulu sunucu ve TLS kitaplığı sürümüne göre değerlendirin.

Mixed Content hatası nedir, nasıl tespit edilir?

Mixed Content, sayfanızın ana HTML isteği HTTPS iken, içindeki bazı kaynakların (görsel, JS, CSS, font, iframe vb.) HTTP üzerinden çağrılmasıdır. Tarayıcı bunu, güvenli bir sayfa içinde güvensiz parçalar var şeklinde yorumlar ve:

• Yükseltilebilir içerik: Uygun görsel, ses ve video istekleri HTTPS’e yükseltilir. IP adresli URL’ler ve bazı görsel istek biçimleri bu davranışın dışındadır.
• Engellenebilir içerik: Script, stil dosyası, iframe ve diğer yükseltilemeyen HTTP kaynakları engellenir.
• Konsol ve ağ kayıtları, hangi isteğin değiştirildiğini, engellendiğini veya HTTPS üzerinden yüklenemediğini gösterir.

Mixed content kaynaklarını tespit etme

İlk adım, hangi kaynakların HTTP üzerinden çağrıldığını bulmak:

1. Sayfayı HTTPS üzerinden açıp tarayıcının geliştirici araçlarına geçin.
2. Console sekmesinde “Mixed Content” uyarılarını ve ilgili kaynak URL’lerini inceleyin.
3. Network sekmesinde http:// isteklerini, başarısız yüklemeleri ve otomatik HTTPS yükseltmelerini kontrol edin; engellenen istek sunucuya hiç ulaşmayabilir.
4. Kaynak kodda sabit http:// adreslerini arayın ve gerçekten sayfaya gömülen kaynak olup olmadıklarını ayırın. Normal dış bağlantıları topluca değiştirmeyin.

Bu adımlar sonunda elinizde genelde üç tip problemli bağlantı olur:

• Eski tema/plugin veya statik HTML içinde sabitlenmiş HTTP linkleri,
• CDN, harici servisler veya eski alan adı üzerinden çekilen kaynaklar,
• Yanlış base URL veya site adresi ayarları.

WordPress ve PHP uygulamalarında mixed content çözümü

WordPress ve benzeri CMS’lerde mixed content çoğu zaman temel URL ayarlarının yanlış olmasından veya veritabanına HTTP’li linklerin kaydedilmiş olmasından kaynaklanır:

• Site adresi ayarı: WordPress’te Ayarlar > Genel bölümündeki Site Adresi (URL) ve WordPress Adresi (URL) değerlerini, varsa yapılandırma dosyasındaki geçersiz kılmalarıyla birlikte kontrol edin. İlgili değerler https:// kullanmalıdır.
• Veritabanında HTTP kaynakları: Eski http:// adresleri sayfaya gömülü kaynak olarak yükleniyorsa mixed content oluşturabilir. Değişikliği ilgili site ve kaynak URL’leriyle sınırlandırın; normal gezinme bağlantıları tek başına mixed content değildir.

WordPress için önce yedek alıp WP-CLI search-replace gibi serileştirmeyi koruyan bir araçla dry-run önizlemesi yapmak tercih edilir. Aşağıdaki SQL yalnızca wp_posts.post_content alanındaki değişimin sınırlı bir örneğidir; genel veritabanı taşıma komutu değildir. Bunu ancak ilgili içerik alanında serileştirilmiş veri bulunmadığını doğruladığınızda değerlendirin. Tablo önekini ve örnek alan adını uyarlayın, hedef verileri inceleyin ve önce deneme kopyasında çalıştırın.

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

wp_postmeta ve options tablolarında tema veya eklentilere ait serileştirilmiş veriler bulunabilir. Bu tablolara aynı SQL REPLACE işlemini uygulamayın. WP-CLI search-replace ile ilgili tablo ve sütunları seçin, GUID alanlarını ve ilgisiz siteleri kapsam dışında bırakın, dry-run raporunu inceleyip değişikliği uygulayın. Ardından önbellekleri temizleyin ve sayfa, medya ile yönetim ekranlarını test edin. İşleme başlamadan önce 3-2-1 yedekleme stratejisi rehberindeki gibi geri yüklenebilir bir yedek planı oluşturun.

Apache/Nginx yönlendirmeleri ve CSP’nin rolü

Uygulamanın HTTPS kaynak URL’leri üretmesini sağlayın. Sunucu yönlendirmesi ve CSP farklı aşamalarda çalışır; her birini kendi amacı ve sınırlarıyla değerlendirin:

1) Sunucuya ulaşan HTTP isteklerini HTTPS’e yönlendirmek

HTTP isteği sunucuya ulaşıyorsa, onu seçtiğiniz HTTPS adresine 301 ile yönlendirebilirsiniz. Önce hedef HTTPS sitesinin sertifika ve içerik erişimini doğrulayın. Aşağıdaki örneklerde ornek.com yerine kendi kanonik alan adınızı yazın.

Apache .htaccess örneği: Kural, ilgili sitenin belge kökündeki .htaccess dosyası içindir. mod_rewrite etkin olmalı, sunucu .htaccess üzerinden bu kurallara izin vermeli ve ilgili dizinde FollowSymLinks veya SymLinksIfOwnerMatch koşulu sağlanmalıdır. HTTPS bağlantısının doğrudan Apache’de sonlandığı varsayılır. TLS’i başka bir proxy sonlandırıyorsa bu HTTPS-off koşulunu aynen kullanmak döngüye yol açabilir; şema bilgisini yalnızca doğrulanmış proxy’den alan ayrı yapılandırma gerekir.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://ornek.com%{REQUEST_URI} [R=301,L]

Nginx HTTP sunucu bloğu: Bu örnek 80 numaralı porta gelen istekleri yönlendirir. 443 numaralı portta çalışan, geçerli sertifikalı HTTPS sunucu bloğunu ayrıca kurun. Sabit hedef alan adı, yönlendirme adresinin istemcinin Host değerinden üretilmesini önler.

server {
    listen 80;
    server_name ornek.com www.ornek.com;
    return 301 https://ornek.com$request_uri;
}

Bu yönlendirme yalnızca sunucuya ulaşan HTTP isteğine cevap verir; ilk istek yine HTTP’dir. Tarayıcı mixed content isteğini göndermeden engellerse sunucu yönlendirmesi devreye giremez. Kural ayrıca başka bir sunucudaki harici kaynağı değiştirmez. Veritabanı ve şablonlarda saklanan kaynak adreslerini bu nedenle ayrıca düzeltin.

2) Content-Security-Policy ile “upgrade-insecure-requests” kullanmak

Geçiş sırasında, kapsadığı HTTP kaynak isteklerini tarayıcıda HTTPS’e yükseltmek için aşağıdaki HTTP yanıt başlığını kullanabilirsiniz. Bu satır tek başına .htaccess veya Nginx direktifi değildir; başlığı uygulamanızın ya da web sunucunuzun desteklediği yöntemle ayarlayın ve harici kaynaklar dahil HTTPS erişimini test edin.

Content-Security-Policy: upgrade-insecure-requests

Bu başlık, kapsadığı http:// kaynak isteklerini HTTPS’e yükseltir. Kaynak HTTPS üzerinden sunulamıyorsa yükleme başarısız olur; HTTP’ye geri dönülmez. CSP konusunda daha detaylı bir kurulum için CSP’yi doğru kurma rehberimize göz atabilirsiniz.

Yönlendirme HTTP giriş adreslerini, bu CSP direktifi ise kapsadığı kaynak isteklerini ele alır. Uygulamadaki URL’leri düzeltmek ve değişikliği yeni içeriklerde de korumak, bu geçiş önlemlerinin yanında yapılması gereken asıl bakımdır.

Sertifika ve alan adı hatalarını düzeltmek

Mixed content dışında, sertifikanın süresi, alan adı kapsamı ve güven zinciri bağlantıyı etkiler. Her kontrolde tarayıcının bağlandığı uç noktanın sertifikasını inceleyin; CDN kullanıldığında bu sertifika origin sunucudakinden farklı olabilir.

1) Sertifika süresi dolmuş (expired certificate)

Tarayıcı, “NET::ERR_CERT_DATE_INVALID” gibi bir tarih hatası gösterebilir; mesaj sürüme göre değişir. Sertifika gerçekten süresi dolmuş veya henüz geçerli olmayabilir, istemci cihazının saati de yanlış olabilir. Kontrol sırası:

• Panelde kayıtlı sertifikanın yanında, ilgili hostname için gerçekten sunulan sertifikanın başlangıç ve bitiş tarihlerini kontrol edin.
• Tarayıcının çalıştığı cihazın tarih ve saatini doğrulayın.
• ACME yenileme görevini, hata günlüklerini ve sertifikanın ilgili web sunucusu veya proxy’ye dağıtımını kontrol edin.
• Yeni sertifikadan sonra gerekli yeniden yüklemeyi yapın ve istemciye sunulan sertifikayı tekrar inceleyin. Başarılı yenileme kaydı, dağıtımın tamamlandığını tek başına göstermez.

Otomasyon tarafında daha ileri senaryolar için ACME otomasyonunda yedekli CA kullanımı makalemizde detaylı bir örnek akış bulabilirsiniz.

2) Alan adı uyuşmazlığı ve SAN kapsamı

İstenen hostname sertifikadaki Subject Alternative Name (SAN) adlarıyla eşleşmelidir; Common Name (CN) alanına tek başına güvenilmez. Alan adı uyuşmazlığında şu olasılıkları kontrol edin:

• Sertifika sadece ornek.com için alınmıştır, siz www.ornek.com üzerinden erişiyorsunuz (veya tam tersi).
• Sertifika yanlış alan adına bağlanmış vhost altında kullanılıyor.
• Wildcard sertifika beklerken tek alan adına kesilmiş bir sertifika yüklenmiş.

Çözüm tarafında iki kritik nokta var:

1. Kapsanan adları doğrulayın: Aynı sertifikanın SAN alanında hem ornek.com hem www.ornek.com bulunabilir. *.ornek.com yalnızca bir alt alan düzeyini kapsar; kök alan adını veya daha derin adları kapsamaz. Kök alan adı ayrıca SAN’a eklenebilir.
2. Doğru sanal sunucuya bağlayın: Nginx’te server_name, Apache’de ServerName/ServerAlias ile ilgili sertifika eşleşmesini kontrol edin. HTTPS yönlendirmesinin kaynak hostname’i de geçerli sertifika ister; sertifika kontrolü 301 yanıtından önce yapılır.

Hangi senaryoda DV, OV, EV veya wildcard sertifika tercih etmeniz gerektiği konusunda kararsızsanız, DV, OV, EV ve Wildcard SSL rehberimiz karar aşamasında iyi bir referans olacaktır.

3) Sertifika zinciri eksik (intermediate CA yüklenmemiş)

Sertifikanın adı ve geçerlilik süresi doğru olduğu halde bir istemci güven zincirini kuramayabilir. Eksik ara sertifikalar bu durumun olası nedenlerinden biridir:

• Sunucuya yalnızca sunucu sertifikası yüklenmiş,
• CA’nın verdiği intermediate (ara) sertifikalar yüklenmemiş veya yanlış sırada birleştirilmiş.

Çözüm için:

1. Sertifika otoritesinin sağladığı uygun ara sertifikaları alın ve doğru sunucu sertifikasıyla birlikte hazırlayın.
2. Apache 2.4.8 ve sonrasında SSLCertificateFile, sunucu sertifikasının ardından ara sertifikaları da yükleyebilir. SSLCertificateChainFile bu sürümden beri eski kullanım olarak belgelenir; birleşik zinciri SSLCertificateFile üzerinden yapılandırın.
3. Nginx’te ssl_certificate dosyasında önce sunucu sertifikası, ardından ara sertifikalar bulunmalıdır. ssl_certificate_key eşleşen özel anahtarı göstermelidir. İstemciye gönderilen zinciri ayrıca doğrulayın.

4) SNI ve birden fazla site barındırma sorunları

Aynı IP üzerinde birden fazla HTTPS site için farklı sertifikalar sunarken SNI (Server Name Indication), sunucunun istenen hostname’e göre sertifika seçmesini sağlar; modern tarayıcılar SNI destekler. Yanlış yapılandırılmış vhost’lar veya istemcinin SNI göndermemesi, istenen adı kapsamayan bir sertifikanın sunulmasına yol açabilir. Tek bir sertifikanın bütün ilgili adları kapsadığı durumda, yalnızca aynı IP’yi paylaşmak SNI’yi zorunlu kılmaz.

Panelin SNI davranışını veya sertifika eşlemesini varsaymayın; ilgili alan adından bağlanarak sunulan sertifikayı kontrol edin. Nginx’te server_name, Apache’de ServerName ve varsa alias tanımlarını, IP/port dinleyicilerini ve varsayılan sanal sunucuyu inceleyin. SNI desteği olmayan eski istemciler için uyumluluk gereksinimini ayrıca değerlendirin.

HTTPS yönlendirmeleri ve HSTS politikası

Sertifika ve kaynaklar düzeltildikten sonra, kullanıcıların HTTP adreslerinden doğru HTTPS sayfasına ulaşmasını sağlayın. Kalıcı yönlendirme URL tercihini belirtir; HSTS ise destekleyen tarayıcının belirli süreyle HTTPS kullanmasını sağlar.

HTTP → HTTPS yönlendirme stratejisi

Hedefiniz şu olmalı: Kullanıcı http:// ile de yazsa, her zaman tek bir kanonik HTTPS adresine düşmeli.

• Tüm http://ornek.com istekleri → https://ornek.com
• Tüm http://www.ornek.com istekleri → https://ornek.com (veya tam tersi, hangi yapıyı kanonik seçtiyseniz)

Apache için birleşik kanonik yönlendirme: Bu kural, önceki Apache örneğinin alternatifidir; ikisini üst üste eklemeyin. Yine ilgili sitenin belge kökündeki .htaccess dosyasında ve TLS doğrudan Apache’de sonlanırken kullanılır. ornek.com ve www.ornek.com için HTTPS erişimi ve sertifika kapsamı önceden doğrulanmalıdır. Sabit hedefi kendi kanonik hostname’inize uyarlayın; mevcut uygulama kurallarıyla yönlendirme zincirini test edin.

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^ornek\.com$ [NC]
RewriteRule ^ https://ornek.com%{REQUEST_URI} [R=301,L]

Nginx için HTTP yönlendirmesi: Aşağıdaki blok yalnızca HTTP isteklerini kapsar. HTTPS üzerinden www.ornek.com adresini de yönlendirmek için o hostname’i kapsayan sertifikalı bir 443 sunucu bloğu gerekir; bu blok kanonik HTTPS adrese yönlendirir. Kanonik hostname’in HTTPS bloğu ise içeriği sunar. Yalnızca 80 numaralı portu yapılandırmak, HTTPS üzerindeki www tercihini tamamlamaz.

server {
    listen 80;
    server_name ornek.com www.ornek.com;
    return 301 https://ornek.com$request_uri;
}

HSTS ile süreli HTTPS politikası uygulamak

HSTS (HTTP Strict Transport Security), destekleyen tarayıcıya alan adı için belirli süre boyunca HTTPS kullanmasını bildirir. Süre, geçerli bir HTTPS yanıtında alınan max-age değerine bağlıdır; “bir daha asla HTTP kullanma” şeklinde süresiz bir talimat değildir.

• Tarayıcıda politika etkinken ilgili HTTP adresleri HTTPS’e yükseltilir.
• HSTS kapsamındaki bağlantıda sertifika doğrulaması başarısızsa bağlantı kesilir; HSTS hatalı sertifikayı geçerli hale getirmez.
• Politika ilk kez alınmadan önceki HTTP bağlantısı ile önceden kaydedilmiş veya preload edilmiş politika farklı durumlardır.

HTTPS çalıştıktan sonra yalnızca mevcut hostname için kısa süreli bir başlangıç yanıt başlığı örneği aşağıdadır. 300 saniye beş dakikadır; başlığı sunucunuzun desteklediği yöntemle HTTPS yanıtına ekleyin, ardından tarayıcı davranışını ve yenileme akışını test edin.

Strict-Transport-Security: max-age=300

Kontroller tamamlandığında max-age süresini kademeli artırabilirsiniz. includeSubDomains bütün alt alanları kapsar; henüz HTTPS sunmayan alt alanlar varken eklemeyin. preload kaydı ayrı bir karar ve hazırlık sürecidir, başlangıç örneğinin parçası değildir. Başlığı kaldırmak tarayıcıda saklanan politikayı hemen silmez; mevcut süre dolana kadar devam edebilir. Ayrıntılar için HTTP güvenlik başlıkları rehberine bakın.

Hosting ortamına göre kontrol adımları

Paylaşımlı hosting, VPS, fiziksel sunucu ve colocation ortamlarında yönetim yetkisi farklı olabilir. Önce sertifika, web sunucusu ve uygulama ayarlarından kimin sorumlu olduğunu belirleyin; işlemleri sahip olduğunuz erişim kapsamına göre yürütün.

Paylaşımlı hosting üzerinde SSL hatalarını düzeltmek

Paylaşımlı hosting panelinde ve hizmet kapsamında şu olanakları kontrol edin:

• Alan adı için otomatik sertifika hizmeti ve yenileme durumunun bulunup bulunmadığı,
• HTTPS yönlendirmesi seçeneğinin hangi domain ve alt alanlara uygulandığı,
• HTTP yanıt başlıklarını veya .htaccess kurallarını düzenleme yetkisi ve sınırları.

Bu ortamda yapılacaklar özetle:

1. A/AAAA kayıtlarının amaçlanan hosting sunucusu, CDN veya reverse proxy’yi gösterdiğini doğrulayın.
2. Paneldeki SSL sertifikası durumunu ve tarayıcıya sunulan sertifikanın adı, zinciri ve tarihlerini karşılaştırın.
3. HTTPS bağlantısını doğruladıktan sonra panelin yönlendirmesini veya ortama uygun tek bir kuralı etkinleştirip test edin.
4. WordPress/CMS adreslerini ve kaynak URL’lerini yedekli, kapsamı belirlenmiş bir işlemle https:// olarak güncelleyin.

VPS ve dedicated sunucularda daha ince ayarlar

Yönetim yetkinizin bulunduğu VPS veya fiziksel sunucuda protokol, sertifika ve proxy ayarlarını doğrudan kontrol edebilirsiniz. Yönetilen bir hizmette hangi değişiklikleri sağlayıcının yaptığı ayrıca belirlenmelidir:

• ACME istemcisiyle, örneğin acme.sh ile yenilemeyi planlayın; dağıtım adımını, gerekli yeniden yüklemeyi ve gerçekten sunulan sertifikayı doğrulayın.
• Bakımı süren yazılım sürümlerinde TLS 1.2 ve destekleniyorsa TLS 1.3 kullanın; TLS 1.0/1.1’i kapatın. Nginx’in ssl_protocols ve ssl_ciphers adları Apache direktifi değildir. TLS 1.2 için RFC 9325’in ECDHE/AES-GCM önerilerini inceleyin; RC4 kullanmayın ve 112 bit etkili güce sahip 3DES’i devre dışı bırakın. TLS 1.3 ayrı AEAD şifre takımları kullanır; eski cipher listesiyle aynı kapsamda değerlendirilmez.
• CDN/proxy’nin tarayıcı bağlantısını ve origin bağlantısını ayrı denetleyin. Ağ üzerinden origin bağlantısında HTTPS ve sertifika doğrulaması kullanın. Uygulama, Forwarded veya X-Forwarded-Proto bilgisini yalnızca açıkça güvenilen proxy’den kabul etmeli; proxy, istemcinin gönderdiği bu başlıkları gerçek şemayla değiştirmelidir.

Bu konuların çoğunu daha önce parça parça işledik; örneğin:

• Nginx’te TLS 1.3, OCSP stapling ve Brotli kurulumu
• Let’s Encrypt wildcard SSL otomasyonu ve DNS-01 senaryoları
• ACME challenge türleri (HTTP-01, DNS-01, TLS-ALPN-01)

Bu rehberler, kurulu sunucu ve sertifika otoritesinin güncel belgeleriyle birlikte değerlendirilmelidir. Değişiklikleri deneme ortamında doğrulayın; ardından gerçek hostname ve istemcilerle sertifika, protokol ve yönlendirme kontrollerini tekrarlayın.

SSL hatasına yol açabilen örnek senaryolar

Aşağıdaki olası senaryolar, hangi katmanın kontrol edilmesi gerektiğini gösterir. Bunlar belirli bir müşteri olayı veya ölçülmüş sonuç olarak sunulmaz.

1) HTTP’den HTTPS’e geçişte unutulan CDN ve medya alan adları

Statik dosyaların cdn.ornek.com gibi bir alt alandan sunulduğunu düşünün. Ana site HTTPS’e geçirilirken kaynak URL’leri HTTP olarak kalırsa mixed content ortaya çıkabilir. Kaynak URL’si HTTPS olduğu halde CDN sertifikası hatalıysa bu kez ilgili kaynağın TLS bağlantısı başarısız olur. İki durumu ağ kayıtlarında ayırın.

Çözüm:

• CDN hostname’i için HTTPS erişimini ve istemciye sunulan sertifikayı doğrulayın.
• Uygulamanın asset URL veya base URL ayarlarını ilgili HTTPS kaynak adresine güncelleyin.
• Veritabanındaki ilgili CDN URL’lerini yedek ve serileştirme kontrolleriyle https:// olarak değiştirin; önbelleği temizleyip kaynakları yeniden test edin.

2) Alan adı değişimi + HTTPS geçişi aynı anda

Alan adı ve HTTPS değişikliğini birlikte yapmak, hem URL eşlemesini hem sertifika dağıtımını kontrol etmeyi gerektirir. Değişikliği tek başına bir SEO garantisi olarak görmeyin; eski sayfaların doğru yeni karşılıklarına yönlendiğini ve yeni URL’lerin erişilebilir olduğunu doğrulayın. Ek geçiş kontrolleri için alan adı değişiminde SEO rehberine başvurabilirsiniz.

Özet kontrol listesi:

• Eski hostname’e HTTPS erişimi ve yönlendirmesi sürdüğü müddetçe o hostname için geçerli sertifika bulundurun.
• Eski alan adının HTTP ve HTTPS sayfalarını uygun yeni kanonik HTTPS karşılıklarına yönlendirin; her sayfayı ana sayfaya göndermeyin.
• Eski kaynak URL’lerini, dahili bağlantıları ve kanonik adresleri kontrol edin; yönlendirme zincirlerini ve mixed content sonuçlarını test edin.

3) Sertifika güncellemeleri hep son dakikaya kalıyor

Yenileme uyarısı gözden kaçtığında veya dağıtım adımı başarısız olduğunda süresi dolmuş sertifika sunulabilir. Sabit bir sertifika ömrü varsaymak yerine gerçek geçerlilik tarihlerini, otomasyon durumunu ve sunulan sertifikayı izleyin. Operasyonel kontrol önerileri için SSL sertifika güvenlik güncellemeleri yazısına bakabilirsiniz.

Adım adım genel çözüm rehberi

Hata veren tam URL’yi kaydedin ve aşağıdaki sırayla ilerleyin. Her değişiklikten sonra aynı sayfayı yeniden test ederek sorunun hangi adımda giderildiğini belirleyin:

1. DNS ve uç nokta: A/AAAA kayıtları amaçlanan sunucu veya proxy’yi gösteriyor mu? IPv4 ve IPv6 yollarında farklı sertifikalar sunuluyor mu?
2. Sertifika: Sunulan sertifikanın tarihleri, SAN alan adı eşleşmesi ve ara sertifika zinciri doğru mu? İstemci saati doğru mu?
3. Yönlendirme: HTTP ile www/non-www adresleri seçilen HTTPS karşılığa gidiyor mu? HTTPS kaynak hostname’lerinin sertifikaları geçerli mi?
4. Mixed content: Konsol ve ağ kayıtlarında hangi kaynaklar başarısız? Tema, içerik, CDN ve proxy arkasındaki URL üretimi kontrol edildi mi?
5. Protokol ve politika: TLS sürümleri ile şifre takımları kurulu yazılım ve istemcilerle uyumlu mu? HSTS süresi ve alt alan kapsamı doğrulandı mı?
6. Yenileme ve izleme: ACME görevi, dağıtım ve gerekli yeniden yükleme çalışıyor mu? Hata bildirimlerini kimin takip ettiği belli mi?

SSL hatalarını çözmek için izlenecek yol

Önce sertifika ve HTTPS bağlantısını, sonra yönlendirmeleri ve uygulamanın kaynak URL’lerini doğrulayın. Sertifika yenilendiğinde, DNS değiştiğinde veya yeni bir proxy eklendiğinde ilgili kontrolleri tekrarlayın. Otomasyon bakım yükünü azaltır; başarısızlıkları izlemenin ve sunulan sonucu doğrulamanın yerini tutmaz.

DCHost üzerindeki bir hizmet için destek kaydı açarken etkilenen hostname’i, tarayıcı hatasını ve son değişiklikleri belirtin. DNS, sertifika, web sunucusu ve uygulama işlerinin hangilerinin hizmetin yönetim kapsamında olduğunu netleştirin. Çok alan adlı bir yapıda her hostname’in yetkilendirme, sertifika ve yenileme sorumluluğunu ayrıca kaydedin.

Kontrol listesini mevcut sorunu daraltmak ve sonraki bakım işlemlerini planlamak için kullanın. Amaç, her katmanda doğru sertifika ve HTTPS davranışını doğrulamak ve değişikliklerden sonra bunu yeniden kontrol edebilmektir.