NET::ERR_CERT_DATE_INVALID Hatasını Düzeltmenin 12 Yolu (Eksiksiz Teknik Kılavuz)

NET::ERR_CERT_DATE_INVALID hatası, bir istemcinin SSL/TLS sertifikasının zamansal bütünlüğünü doğrulayamadığında oluşan tarayıcı düzeyinde bir TLS el sıkışma hatasıdır; bu, sertifikanın süresi dolmuş, henüz geçerli değil veya sistem saatinin sertifikanın geçerlilik penceresinin dışına çıkacak kadar kaymış olduğu anlamına gelir. Chrome, Edge, Firefox ve Safari, bu kontrol başarısız olduğunda erişimi engelleyerek yumuşak bir uyarı yerine sert bir güvenlik uyarısı görüntüler.

Bu hatanın iki farklı temel nedeni vardır: istemci tarafı (yanlış sistem saati, eski önbellek, müdahale eden yazılım) ve sunucu tarafı (süresi dolmuş sertifika, yanlış yapılandırılmış sertifika zinciri, sanal ana bilgisayara bağlı yanlış sertifika). Hangi tarafın sorumlu olduğunu belirlemek kritik ilk tanı adımıdır ve bu kılavuz, sorunu kalıcı olarak çözmek için gereken hassasiyetle her ikisini de ele almaktadır.

NET::ERR_CERT_DATE_INVALID Neden Yalnızca Bir Tarayıcı Rahatsızlığından Fazlasıdır

Bir tarayıcı TLS el sıkışması başlattığında, sunucu sertifikasını üç kritere göre doğrular: sertifikayı veren Sertifika Yetkilisi güvenilir olmalı, alan adı sertifikanın Konu Alternatif Adları (SAN’lar) ile eşleşmeli ve mevcut zaman damgası sertifikanın `notBefore` ile `notAfter` alanları arasında olmalıdır. Zaman damgası kontrolü başarısız olursa — istemci veya sunucu tarafında — el sıkışma iptal edilir ve tarayıcı `NET::ERR_CERT_DATE_INVALID` hatasını gösterir.

Bunun sonuçları önemlidir. Açık kullanıcı deneyimi aksaklığının ötesinde, Google’ın tarayıcıları da geçersiz sertifikalara sahip HTTPS kaynaklarını reddeder; bu da sıralamaları olumsuz etkileyebilir. VPS Hosting ortamında çalışan siteler, sertifika yaşam döngüsü yönetimi üzerinde tam kontrole sahiptir ve sunucu tarafı çözümü basittir; ancak istemci tarafı nedenler yapılandırılmış bir tanı yaklaşımı gerektirir.

İstemci Tarafı ve Sunucu Tarafı: Bir Tanı Çerçevesi

Herhangi bir düzeltme uygulamadan önce hangi tarafın sorumlu olduğunu belirleyin. Bu, önemli ölçüde zaman kazandırır.

Düzeltme 1: Sistem Tarih ve Saatinizi Senkronize Edin

Bu, en yaygın istemci tarafı nedendir. Sistem saatiniz birkaç dakikadan fazla kapalıysa, TLS kütüphanesi geçerlilik penceresi yanlış yerel zaman damgasını kapsamayan sertifikaları reddeder. 1 Ocak’tan 31 Aralık’a kadar geçerli olan bir sertifika, saati bir sonraki Ocak ayını gösteren bir makineye “süresi dolmuş” görünecektir.

Windows:

• Sistem tepsisindeki saate sağ tıklayın ve Tarih/saati ayarla‘yı seçin
• Saati otomatik olarak ayarla‘yı etkinleştirin ve saat dilimini doğru şekilde ayarlayın
• “Saatinizi senkronize edin” altındaki Şimdi eşitle‘ye tıklayın
• Alternatif olarak, Komut İstemi aracılığıyla NTP senkronizasyonunu zorlayın (yönetici olarak çalıştırın):

“`

w32tm /resync /force

“`

macOS:

• Sistem Ayarları > Genel > Tarih ve Saat‘e gidin
• Tarih ve saati otomatik olarak ayarla‘yı etkinleştirin ve güvenilir bir NTP sunucusu seçin (örn. `time.apple.com`)

Linux (sunucu tarafı):

“`bash

timedatectl set-ntp true

systemctl restart systemd-timesyncd

timedatectl status

“`

Kritik nüans: Sanal makinelerde ve konteynerlerde, misafir saati ana bilgisayardan önemli ölçüde sapabilir. Bir VPS yönetiyorsanız, yeniden başlatmalardan sonra her zaman `timedatectl` çıktısını doğrulayın ve `pool.ntp.org` gibi güvenilir bir NTP kaynağı yapılandırın.

Düzeltme 2: Tarayıcı Önbelleğini ve SSL Durumunu Temizleyin

Tarayıcılar, sertifika yanıtlarını ve HSTS (HTTP Strict Transport Security) politikalarını agresif biçimde önbelleğe alır. Önbelleğe alınmış geçersiz bir sertifika yanıtı, temel sorun çözüldükten sonra bile devam edebilir.

Chrome’un tarama verilerini temizleme:

• `chrome://settings/clearBrowserData` adresine gidin
• Zaman aralığını Tüm zamanlar olarak ayarlayın
• Çerezler ve diğer site verileri ile Önbelleğe alınmış resimler ve dosyalar‘ı işaretleyin
• Verileri temizle‘ye tıklayın

Windows’ta SSL durumunu temizleme (tarayıcı önbelleğinden ayrı):

• Denetim Masası > Ağ ve İnternet > İnternet Seçenekleri‘ni açın
• İçerik sekmesine gidin
• SSL Durumunu Temizle‘ye tıklayın ve onaylayın

Chrome’da HSTS önbelleğini temizleme (sıklıkla gözden kaçırılır):

• `chrome://net-internals/#hsts` adresine gidin
• “Alan adı güvenlik politikalarını sil” altında alan adını girin ve Sil‘e tıklayın

Bu adım, alan adının daha önce uzun `max-age` değerine sahip geçerli bir HSTS başlığına sahip olması durumunda özellikle önemlidir. Tarayıcı, sertifika geçersiz olsa bile HTTPS’yi zorunlu kılacak ve HSTS girişinin ayrıca temizlenmesi gerekecektir.

Düzeltme 3: Tarayıcınızı En Son Sürüme Güncelleyin

Eski tarayıcılar, güncel olmayan kök sertifika depoları ile birlikte gelir. Sertifika Yetkilileri periyodik olarak kök sertifikaları ekler, iptal eder ve döndürür. Tarayıcınızın yerleşik kök deposu, sunucunun sertifikasını imzalayan CA’yı içermiyorsa, zincir doğrulaması başarısız olur; bu bazı uç durumlarda `NET::ERR_CERT_DATE_INVALID` olarak kendini gösterebilir, ancak `NET::ERR_CERT_AUTHORITY_INVALID` daha yaygındır.

Chrome’u güncelleme:

• Üç noktalı menüye tıklayın > Yardım > Google Chrome Hakkında
• Chrome bekleyen güncellemeleri otomatik olarak algılayıp uygulayacaktır
• Güncellemeyi tamamlamak için tarayıcıyı yeniden başlatın

Bu neden teknik açıdan önemlidir: Chrome 117+, daha katı sertifika şeffaflığı (CT) günlük gereksinimleri uygular. Tanınan bir CT günlüğüne kaydedilmemiş sertifikalar, geçerlilik tarihleri ne olursa olsun reddedilecektir. Tarayıcıyı güncel tutmak, modern PKI uygulamalarıyla uyumluluğu sağlar.

Düzeltme 4: Antivirüs HTTPS Denetimini Geçici Olarak Devre Dışı Bırakın

Kaspersky, ESET, Avast ve Bitdefender dahil olmak üzere birçok kurumsal ve tüketici antivirüs ürünü SSL/TLS müdahalesi gerçekleştirir (HTTPS taraması veya ortadaki adam denetimi olarak da bilinir). Bunu, yerel bir kök CA sertifikası yükleyerek ve tüm HTTPS trafiğini yeniden imzalayarak yaparlar. Antivirüsün dahili sertifikasının süresi dolmuşsa veya sertifikayı doğru geçerlilik tarihleriyle yeniden imzalamakta başarısız olursa, tarayıcı geçersiz bir sertifika alır ve `NET::ERR_CERT_DATE_INVALID` hatasını verir.

Adımlar:

• Antivirüsün HTTPS tarama özelliğini geçici olarak devre dışı bırakın (antivirüsün tamamını değil)
• Etkilenen web sitesini test edin
• Hata çözülürse, antivirüsü en son sürüme güncelleyin (bu genellikle dahili CA sertifikasını yeniler)
• Düzeltmeyi onayladıktan sonra HTTPS taramayı yeniden etkinleştirin

HTTPS taramayı kalıcı olarak devre dışı bırakmayın. Bunun yerine, site güvenilirse sorunlu alan adını antivirüsün hariç tutma listesine ekleyin.

Düzeltme 5: Tarayıcı Uzantılarını Denetleyin ve Devre Dışı Bırakın

Gizlilik odaklı uzantılar (VPN’ler, reklam engelleyiciler, betik engelleyiciler), istek başlıklarını değiştirerek veya trafiği kendi sertifika altyapısına sahip proxy’ler üzerinden yönlendirerek sertifika doğrulamasına müdahale edebilir.

Sistematik izolasyon süreci:

• `chrome://extensions/` adresini açın
• Tüm uzantıları aynı anda kapatın
• Etkilenen URL’yi test edin
• Hata kaybolursa, sorumluyu belirlemek için uzantıları tek tek yeniden etkinleştirin
• Sorunlu uzantının proxy veya HTTPS müdahale seçenekleri için ayarlarını kontrol edin

Kendi DNS-over-HTTPS (DoH) veya proxy yönlendirmesini uygulayan uzantılar en yaygın suçlulardır. Temiz bir tarayıcı profili kullanmak (`chrome://settings/manageProfile`), uzantıları tek tek değiştirmekten daha hızlı bir izolasyon yöntemidir.

Düzeltme 6: DNS Önbelleğini Temizleyin

DNS önbellek bozulması doğrudan sertifika doğrulama hatalarına neden olmasa da trafiği yanlış bir IP adresine yönlendirebilir; bu IP adresi, alan adı için farklı (ve geçersiz) bir sertifika sunuyor olabilir. Bu durum, IP adreslerinin sık değiştiği CDN ortamlarında özellikle geçerlidir.

Windows:

“`

ipconfig /flushdns

“`

macOS:

“`bash

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for older systems:

sudo service nscd restart

“`

Temizledikten sonra, `nslookup yourdomain.com` veya `dig yourdomain.com` ile doğru IP’yi çözümlediğinizi doğrulayın ve IP’nin hosting sağlayıcınızın kayıtlarıyla eşleştiğini onaylayın.

Düzeltme 7: TLS Protokol Ayarlarını Doğrulayın ve Düzenleyin

Modern tarayıcılar TLS 1.0 ve TLS 1.1’i kullanımdan kaldırmıştır. Bir sunucu yalnızca kullanımdan kaldırılmış protokoller sunacak şekilde yapılandırılmışsa, tarayıcı bağlantıyı tamamen reddedebilir. Öte yandan, bazı kurumsal ağ cihazları TLS 1.3 başlıklarını kaldırarak doğrulama hatalarını tetikleyebilecek bir düşürmeye zorlar.

Chrome’un TLS bayraklarını kontrol etme:

• `chrome://flags/` adresine gidin
• “TLS” için arama yapın ve hiçbir deneysel bayrağın düşürmeyi zorlamadığını doğrulayın

Sunucu tarafı TLS yapılandırmasını kontrol etme (site sahipleri için):

Sunucunuzun protokol desteğini denetlemek için `ssllabs.com/ssltest/` adresindeki SSL Labs Sunucu Testini kullanın. Düzgün yapılandırılmış bir sunucu, TLS 1.0/1.1 açıkça devre dışı bırakılmış şekilde TLS 1.2 ve TLS 1.3’ü desteklemelidir.

Nginx örneği — modern TLS’yi zorunlu kılma:

“`nginx

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

ssl_prefer_server_ciphers off;

“`

Apache eşdeğeri:

“`apache

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

“`

Düzeltme 8: SSL Sertifikasını İnceleyin ve Yenileyin (Sunucu Sahipleri)

Sunucuyu yönetiyorsanız, bu en doğrudan sunucu tarafı düzeltmesidir. Süresi dolmuş bir sertifika, sunucu tarafından `NET::ERR_CERT_DATE_INVALID` hatasının en basit nedenidir.

Tarayıcıdan sertifikayı inceleme:

• Adres çubuğundaki kilit simgesine (veya uyarı simgesine) tıklayın
• Bağlantı güvenli değil > Sertifika geçerli değil‘i seçin
• Geçerlilik başlangıcı ve Geçerlilik sonu alanlarını kontrol edin

Komut satırı aracılığıyla inceleme (daha güvenilir):

“`bash

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

“`

Bu, sunulan canlı sertifikadan doğrudan `notBefore` ve `notAfter` zaman damgalarını çıktılar.

Certbot ile Let’s Encrypt sertifikasını yenileme:

“`bash

certbot renew –force-renewal

systemctl reload nginx # or apache2

“`

Yenilemeyi otomatikleştirme (doğru uzun vadeli çözüm):

“`bash

Add to crontab or systemd timer

0 3 * * * certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Let’s Encrypt sertifikaları her 90 günde bir sona erer. Otomatik yenileme, ilk sona erme sonrasında değil, dağıtım sırasında yapılandırılmalıdır. cPanel ile VPS çalıştırıyorsanız, AutoSSL bunu otomatik olarak yönetir; ancak etkinleştirildiğini ve yenileme işinin sessizce başarısız olmadığını doğrulayın.

Yaygın sunucu tarafı tuzakları:

• Eksik sertifika zinciri: Sunucu, yaprak sertifikayı sunuyor ancak ara CA sertifikasını sunmuyor. Arayı önbelleğe almamış tarayıcılar doğrulamayı başaramayacaktır. Her zaman tam zinciri birleştirin: `cat yourdomain.crt intermediate.crt > fullchain.crt`
• Sanal ana bilgisayara bağlı yanlış sertifika: Birden fazla sanal ana bilgisayara sahip Nginx veya Apache’de, alan adı için yanlış `ssl_certificate` yönergesi etkin olabilir. `nginx -T | grep ssl_certificate` ile doğrulayın
• Yanlış alan adı için verilen sertifika: `*.example.com` joker karakteri `example.com`’yi (apex alan adı) kapsamaz; her ikisi de SAN olarak açıkça listelenmelidir

Sertifika seçeneklerini değerlendiriyorsanız, güvenilir bir sağlayıcıdan alınan SSL Sertifikaları, tüm büyük tarayıcılarla uyumlu uygun zincir yapılandırması içerir.

Düzeltme 9: Gizli / Özel Tarama Modunda Test Edin

Gizli mod, tarayıcı oturumunu uzantısız, önbelleğe alınmış veri olmadan ve depolanmış çerezler olmadan başlatır. Hatanın çevresel (önbellek, uzantı) mi yoksa yapısal (sunucu sertifikası) mı olduğunu belirlemenin en hızlı yoludur.

Chrome: `Ctrl + Shift + N` (Windows/Linux) veya `Command + Shift + N` (macOS)

Firefox: `Ctrl + Shift + P`

Edge: `Ctrl + Shift + N`

Sonucu yorumlama:

• Gizli modda hata kayboluyor: Neden, önbelleğe alınmış bir yanıt, depolanmış bir HSTS politikası veya tarayıcı uzantısıdır. Düzeltme 2 ve 5 ile devam edin.
• Gizli modda hata devam ediyor: Neden sunucu tarafı veya ağ düzeyindedir. Düzeltme 8, 10 ve 12 ile devam edin.

Düzeltme 10: Farklı Ağlarda Test Edin

Ağ düzeyindeki cihazlar — kurumsal güvenlik duvarları, İSS şeffaf proxy’leri ve bazı ev yönlendiricileri — sertifika hatalarına yol açabilecek SSL denetimi veya DNS manipülasyonu gerçekleştirir. Farklı ağlarda test yapmak bu değişkeni izole eder.

Test metodolojisi:

1. Mevcut ağınızda test edin (örn. ofis Wi-Fi)
2. Mobil veride test edin (yerel ağı tamamen atlar)
3. VPN üzerinden test edin (hem ağ yolunu hem de DNS çözümleyiciyi değiştirir)
4. Farklı bir DNS çözümleyici kullanarak test edin: DNS’inizi `1.1.1.1` (Cloudflare) veya `8.8.8.8` (Google) olarak ayarlayın ve yeniden test edin

Hata yalnızca belirli bir ağda görünüyorsa, sorun o ağın SSL denetimi veya DNS yapılandırmasındadır; sunucu sertifikasında veya tarayıcınızda değil.

Site sahipleri için: Kurumsal ağlardaki kullanıcılar bu hatayı bildirirken diğerleri bildirmiyorsa, sertifikanız kurumsal güven deposunda bulunmayan bir CA kullanıyor olabilir veya kurumsal proxy sertifikanızı doğru şekilde yeniden imzalamakta başarısız oluyor olabilir. Yaygın olarak güvenilen bir CA’ya (DigiCert, Sectigo, Let’s Encrypt) geçmek, kurumsal güven deposu sorunlarının çoğunu çözer.

Düzeltme 11: Windows SSL Durumunu Temizleyin

Windows SSL durumu, tarayıcı önbelleğinden ayrı bir sistem düzeyinde önbellektir. SSL bağlantıları için oturum anahtarlarını ve sertifika bilgilerini depolar. Buradaki bozuk bir giriş, tarayıcı önbelleği temizlendikten sonra bile kalıcı doğrulama hatalarına neden olabilir.

Adımlar:

• Denetim Masası‘nı açın (Başlat menüsünde arayın)
• Ağ ve İnternet > İnternet Seçenekleri‘ne gidin
• İçerik sekmesine tıklayın
• SSL Durumunu Temizle‘ye tıklayın
• Tamam‘a tıklayın
• Tüm tarayıcı örneklerini yeniden başlatın

Bu, Windows SSL/TLS yığınını kullanan tüm tarayıcıları etkiler (Internet Explorer, Edge Legacy ve belirli yapılandırmalarda bazı Chromium tabanlı tarayıcılar). Chrome ve Firefox kendi sertifika depolarını bağımsız olarak yönetir, bu nedenle bu düzeltme Edge ve IE tabanlı kurumsal ortamlar için en çok geçerlidir.

Düzeltme 12: Web Sitesi Yöneticisine Başvurun

Tüm istemci tarafı düzeltmeler tüketilmiş ve hata birden fazla cihaz ve ağda devam ediyorsa, sorun kesinlikle sunucu tarafındadır. Web sitesi sahibinin, çözümü hızlandırmak için belirli teknik ayrıntılarla bilgilendirilmesi gerekir.

Raporunuza dahil edilecekler:

• Tam hata kodu (`NET::ERR_CERT_DATE_INVALID`)
• Tarayıcı denetçisinden sertifika ayrıntıları (veren, geçerlilik tarihleri, SAN’lar)
• Çalıştırabiliyorsanız `openssl s_client -connect domain.com:443` çıktısı
• Hatanın birden fazla tarayıcı ve cihazda görünüp görünmediği
• Hatanın tutarlı mı yoksa aralıklı mı olduğu (aralıklı hatalar genellikle yalnızca bir kısmının süresi dolmuş birden fazla sertifika sunan bir yük dengeleyiciye işaret eder)

Bu tür raporlar alan site yöneticileri için: Sertifika yenileme otomasyonunuzun çalışıp çalışmadığını kontrol edin. Yaygın bir hata modu, Certbot yenilemesinin başarılı olması ancak web sunucusunun yeniden yüklenmemesidir; bu nedenle bellekten eski süresi dolmuş sertifikayı sunmaya devam eder. Yenilemeyi her zaman bir sunucu yeniden yükleme kancasıyla eşleştirin.

Bir Dedicated Server veya VPS ortamı yönetiyorsanız, `check_ssl_cert`, Nagios eklentileri veya UptimeRobot’un SSL izleme hizmeti gibi araçları kullanarak sertifika sona erme için izleme uyarıları ayarlayın; bu hizmet sona ermeden 30, 14 ve 7 gün önce uyarı gönderir.

Sunucu Tarafı Sertifika Yönetimi: Site Sahipleri İçin En İyi Uygulamalar

Kendi altyapısını yöneten yöneticiler için reaktif sertifika yenileme bir sorumluluktur. Aşağıdaki uygulamalar `NET::ERR_CERT_DATE_INVALID` hatasını tekrarlayan bir sorun olmaktan çıkarır.

Proaktif sertifika yaşam döngüsü yönetimi:

• Yenilemeyi otomatikleştirin: Certbot’u systemd zamanlayıcısı veya cron işiyle kullanın. Ticari sertifikalar için CA’nızın API’siyle uyumlu ACME istemcilerini kullanın
• Son kullanma tarihlerini izleyin: Sertifika son kullanma kontrollerini izleme yığınınıza entegre edin. `blackbox_exporter` ile Prometheus, TLS son kullanma metriklerini toplayabilir
• Kritik altyapı için daha uzun geçerlilik süreli sertifikalar kullanın: Let’s Encrypt’in 90 günlük döngüsü çoğu kullanım durumu için uygun olsa da, 1 yıl geçerliliğe sahip OV ve EV sertifikaları yüksek riskli alan adları için yenileme sıklığını azaltır
• Tam zinciri doğrulayın: Her yenilemeden sonra, zincir bütünlüğünü onaylamak için `openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted intermediate.crt yourdomain.crt` komutunu çalıştırın
• Harici bir perspektiften test edin: Tarayıcıların gördüklerini simüle etmek için sunucunuz olmayan bir makineden `curl -v https://yourdomain.com` kullanın

VPS Kontrol Panelleri kullanan ortamlar için: Modern kontrol panellerinin çoğu (cPanel, Plesk, DirectAdmin), AutoSSL veya eşdeğeriyle yerleşik SSL yönetimi içerir. AutoSSL görevinin zamanlandığını doğrulayın ve günlüklerini aylık olarak inceleyin.

Çok alan adlı ve joker sertifika değerlendirmeleri:

• Joker sertifikalar (`*.example.com`), açıkça SAN olarak eklenmediği sürece apex alan adını (`example.com`) kapsamaz
• Çok alan adlı (SAN) sertifikalar, yeni alt alan adları eklendiğinde yalnızca yenilenmemeli, yeniden düzenlenmelidir
• Sertifika sabitleme (HPKP) kullanımdan kaldırılmıştır ve kullanılmamalıdır; sabitlenen sertifikanın süresi dolarsa kalıcı erişim engeliyle sonuçlanabilir

Karşılaştırma: İstemci Tarafı ve Sunucu Tarafı Düzeltmelerine Genel Bakış

Karar Matrisi ve Teknik Kontrol Listesi

`NET::ERR_CERT_DATE_INVALID` hatasını rastgele düzeltmeler uygulamak yerine sistematik olarak çözmek için bu kontrol listesini kullanın.

Adım 1 — Kapsamı izole edin:

• [ ] Hata gizli modda görünüyor mu?
• [ ] Hata ikinci bir cihazda (telefon, başka bir bilgisayar) görünüyor mu?
• [ ] Hata mobil veride görünüyor mu?

Adım 2 — Yalnızca istemci tarafıysa (hata diğer cihazlarda kayboluyor):

• [ ] Sistem saatini doğrulayın ve senkronize edin (NTP)
• [ ] Tarayıcı önbelleğini, çerezleri ve HSTS girişlerini temizleyin
• [ ] Windows SSL durumunu temizleyin (yalnızca Windows)
• [ ] Tüm uzantıları devre dışı bırakın ve yeniden test edin
• [ ] Antivirüs HTTPS taramasını devre dışı bırakın ve yeniden test edin
• [ ] DNS önbelleğini temizleyin

Adım 3 — Sunucu tarafıysa (hata tüm cihazlarda/ağlarda devam ediyor):

• [ ] `openssl s_client -connect domain.com:443` komutunu çalıştırın ve `notAfter`’yi kontrol edin
• [ ] Tam sertifika zincirinin sunulduğunu doğrulayın (yalnızca yaprak sertifika değil)
• [ ] Doğru sertifikanın doğru sanal ana bilgisayara bağlı olduğunu onaylayın
• [ ] Sertifikayı yenileyin ve web sunucusunu yeniden yükleyin
• [ ] SAN’ların gerekli tüm ana bilgisayar adlarını kapsadığını doğrulayın (apex + www + alt alan adları)
• [ ] Yenileme sonrası A veya A+ derecelendirmesini onaylamak için SSL Labs testini çalıştırın

Adım 4 — Tekrarı önleyin:

• [ ] Sunucu yeniden yükleme kancasıyla otomatik sertifika yenilemeyi yapılandırın
• [ ] 30/14/7 gün öncesinde uyarılarla harici sertifika son kullanma izlemesi kurun
• [ ] Sertifika yenileme prosedürlerini çalışma kitabınızda belgeleyin

Birden fazla alan adı yöneten ekipler için, Alan Adı Kaydı ve sertifika yönetimi, bireysel alan adı sertifikalarının fark edilmeden sona ermesini önlemek amacıyla tek bir yönetim arayüzü altında merkezileştirilmelidir.

SSS

S: Sertifikanın süresi dolmamış olsa bile NET::ERR_CERT_DATE_INVALID hatası görünebilir mi?

Evet. Bu hata, tarayıcının TLS kütüphanesi sertifikanın zaman penceresini doğrulayamadığında tetiklenir; bu durum, sistem saatiniz sertifikanın `notBefore`–`notAfter` aralığının dışında bir tarihe ayarlanmışsa gerçekleşir; sertifikanın kendisi teknik olarak geçerli olsa bile. İki yıl ileriye ayarlanmış bir saat, geçerli bir sertifikanın süresi dolmuş gibi görünmesine neden olur.

S: Hata aynı makinede bir tarayıcıda görünürken diğerinde neden görünmüyor?

Chrome, Firefox ve Edge kısmen bağımsız sertifika depoları ve TLS yığınları kullanır. Firefox, Windows ve macOS’ta işletim sistemi sertifika deposunu kullanan Chrome’un aksine kendi NSS kütüphanesini ve kök deposunu kullanır. Bir tarayıcıya yüklenmiş bir uzantı veya bir tarayıcının deposunda önbelleğe alınmış bir HSTS politikası, hatanın yalnızca bir tarayıcıda görünmesine neden olabilirken diğerleri normal çalışmaya devam eder.

S: Bu hata göründüğünde “Yine de devam et”e tıklamak güvenli midir?

Hayır. Diğer bazı sertifika hatalarının aksine, `NET::ERR_CERT_DATE_INVALID` şifreli güven zincirinde gerçek bir başarısızlığa işaret eder. Devam etmek, bağlantınızın doğrulanmadığı anlamına gelir; meşru sunucuyla iletişim kurduğunuzu onaylayamazsınız ve bağlantı ele geçirilmiş olabilir. Yalnızca bakım penceresi sırasında kendi sunucunuzu test eden site sahibiyseniz devam edin.

S: Yönettiğim bir sunucuda SSL sertifikasının sona ermesini nasıl önlerim?

Certbot veya eşdeğer bir ACME istemcisi kullanarak otomatik yenilemeyi yapılandırın ve web sunucunuzu yeniden yükleyen bir yenileme sonrası kancası ekleyin. Ayrıca, sona ermeden 30 gün önce uyarı verecek harici izleme (UptimeRobot, Datadog veya özel bir `check_ssl_cert` betiği) kurun. Manuel yenilemeye güvenmek operasyonel açıdan sağlıksızdır; otomasyon tek güvenilir çözümdür.

S: Bu hata SEO sıralamalarını etkiler mi?

Doğrudan ve dolaylı olarak. Googlebot, geçersiz sertifikayla sunulan HTTPS kaynaklarını dizine eklemez; bu da söz konusu sayfaları tamamen dizinden kaldırır. Ayrıca sitenizde HSTS yapılandırılmışsa, tarayıcılar yedek olarak HTTP üzerinden yüklemeyi reddeder ve sertifika düzeltilinceye kadar siteyi kullanıcılar ve tarayıcılar için tamamen erişilemez hale getirir. Sertifika sağlığı, arama görünürlüğünü sürdürmek için isteğe bağlı bir endişe değil, bir ön koşuldur.