NET::ERR_CERT_AUTHORITY_INVALID Hatası Nasıl Düzeltilir

NET::ERR_CERT_AUTHORITY_INVALID, bir web sunucusu tarafından sunulan sertifikanın tarayıcının yerleşik güven deposu tarafından güvenilen bir kök Sertifika Yetkilisine (CA) kadar izlenememesi durumunda ortaya çıkan tarayıcı düzeyinde bir TLS el sıkışma hatasıdır. Tarayıcı, ortadaki adam (MITM) saldırılarına, veri ele geçirmeye veya sahte bir sunucudan gelen trafiğe maruz kalmayı önlemek için bu hatayı görüntüleyerek herhangi bir veri alışverişi yapılmadan bağlantıyı sonlandırır.

Bu kozmetik bir uyarı değildir. Sert bir kriptografik doğrulama hatasıdır. Tarayıcı sertifika zincirini incelemiş, güvenilen bir köke kadar her bağlantıyı doğrulamaya çalışmış ve zincirin kırık, eksik veya kriptografik olarak geçersiz olduğunu tespit etmiştir. Bu zincirin tam olarak nerede koptuğunu anlamak, beş dakikalık bir düzeltme ile saatler süren yanlış teşhis arasındaki farktır.

Bu Hatayı Gerçekte Ne Tetikler

Belgelerin çoğu yüzeysel nedenleri listeler. Gerçek tablo daha nüanslıdır ve her kök neden farklı bir düzeltme yolu gerektirir.

Kendinden İmzalı Sertifikalar

Kendinden imzalı sertifika, veren ve konu tarafların aynı olduğu bir sertifikadır — sunucu, güvenilen bir CA tarafından imzalanmak yerine kendi sertifikasını kendisi imzalamıştır. Bunlar yerel geliştirme ortamlarında, dahili hazırlık sunucularında ve özel altyapılarda standarttır. Hiçbir genel tarayıcı güven deposu bunları tanımadığından zincir doğrulaması hemen başarısız olur.

Kritik nüans: Kendinden imzalı bir sertifikayı işletim sistemi güven deponuza ekleseniz bile, bazı tarayıcılar (özellikle belirli platformlarda Chrome) kendi sertifika depolarını kullanır ve açıkça yapılandırılmadıkça yine de reddeder.

Süresi Dolmuş SSL/TLS Sertifikası

Her sertifika, X.509 yapısında kodlanmış `notBefore` ve `notAfter` alanları taşır. Sistem saati `notAfter` zaman damgasını geçtiğinde, sertifika nasıl verilmiş olursa olsun kriptografik olarak geçersiz hale gelir. Tarayıcılar bunu kesinlikle uygular.

Uç durum: Sunucunuzun saati önemli ölçüde ileri kayarsa, teknik olarak hâlâ geçerli olan bir sertifika, TLS el sıkışma müzakeresi sırasında sunucunun kendisine süresi dolmuş görünebilir ve bu hatanın istemci tarafı yerine sunucu tarafından kaynaklanmasına neden olabilir.

Eksik Sertifika Zinciri (Eksik Ara CA)

Bu, üretim ortamlarında en sık yanlış teşhis edilen nedendir. Güvenilen bir kök CA, son varlık sertifikalarını doğrudan imzalamaz. Ara CA’ları imzalar, bunlar da sizin sertifikanızı imzalar. Bir sunucuya SSL sertifikası yüklediğinizde, tam zinciri yüklemeniz gerekir: son varlık sertifikanız ve sırayla birleştirilmiş tüm ara sertifikalar.

Sunucunun TLS yanıtında ara sertifika eksikse, çoğu tarayıcı zincir yürüyüşünü güvenilen bir köke kadar tamamlayamaz. Firefox, önceki oturumlardan ara sertifikaları önbelleğe aldığı için (AIA getirme) burada biraz daha affedicidir, ancak Chrome ve Edge kesinlikle başarısız olur.

Doğrulama yöntemi: `openssl s_client -connect yourdomain.com:443 -showcerts` komutunu çalıştırın ve tam zincirin döndürülüp döndürülmediğini inceleyin.

Uyumsuz Sertifika Ortak Adı veya SAN

Bir sertifika `www.example.com` için verilmişse ancak kullanıcı `example.com` adresine erişiyorsa (veya joker karakter tarafından kapsanmayan bir alt alan adına), tarayıcı ilgili ancak farklı bir hata gösterir. Ancak bazı yapılandırmalarda bu, özellikle Konu Alternatif Adları (SAN) içermeyen eski sertifika formatlarında, ad uyuşmazlığı hatası yerine yetki geçersiz hatası olarak kendini gösterir.

İstemci Tarafı Saat Kayması

TLS sertifikaları zaman sınırlıdır. İstemci makinesinin saati sertifikanın `notBefore` alanından önceki veya `notAfter` alanından sonraki bir tarihe ayarlanmışsa, tarayıcı sertifikayı reddeder. Bu durum, sanal makinelerde, yeni sağlanan sunucularda veya NTP senkronizasyonu olmadan uzun süre kapalı kalan makinelerde son derece yaygındır.

Güvenlik Yazılımı Tarafından SSL İncelemesi

Kurumsal güvenlik duvarları, uç nokta güvenlik paketleri ve bazı antivirüs ürünleri SSL/TLS incelemesi (HTTPS müdahalesi olarak da bilinir) gerçekleştirir. TLS bağlantısını güvenlik cihazında sonlandırır, düz metni inceler, ardından cihazın kendi CA’sı tarafından imzalanmış dinamik olarak oluşturulmuş bir sertifika kullanarak yeniden şifreler. Bu cihaz CA’sı tarayıcının güven deposunda yoksa, her HTTPS sitesi bu hatayı tetikler.

Güncel Olmayan Kök Sertifika Deposu

Eski işletim sistemlerinde (güncellemesiz Windows 7, eski Linux dağıtımları), sistem kök CA paketi daha yeni kök sertifikaları içermeyebilir. Örneğin Let’s Encrypt’in ISRG Root X1’i, DST Root CA X3 çapraz imzasının Eylül 2021’de sona ermesiyle birlikte Android 7 ve altında ve yamasız Windows sistemlerinde yaygın hatalara neden oldu.

Kök Neden Karşılaştırması

Adım Adım Düzeltmeler

Adım 1: Sistem Tarih ve Saatini Senkronize Edin

Bu, hata daha önce çalışan bir makinede aniden ortaya çıktığında en hızlı düzeltmedir.

Windows:

1. Ayarlar > Saat ve Dil > Tarih ve saat bölümünü açın.
2. Saati otomatik ayarla ve Saat dilimini otomatik ayarla seçeneklerini etkinleştirin.
3. “Saatinizi senkronize edin” altındaki Şimdi senkronize et seçeneğine tıklayın.
4. Otomatik senkronizasyon başarısız olursa, Komut İstemi’ni Yönetici olarak açın ve şunu çalıştırın: `w32tm /resync /force`

macOS:

1. Sistem Ayarları > Genel > Tarih ve Saat bölümünü açın.
2. Tarih ve saati otomatik ayarla seçeneğini etkinleştirin ve yakın bir NTP sunucusu seçin (örn. `time.apple.com`).
3. Sorun devam ederse Terminal’de şunu çalıştırın: `sudo sntp -sS time.apple.com`

Linux (sunucu veya masaüstü):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

Senkronizasyondan sonra tarayıcıyı yeniden başlatın ve tekrar deneyin.

Adım 2: Tarayıcı Önbelleğini, Çerezleri ve Önbelleğe Alınmış Sertifikaları Temizleyin

Tarayıcılar HSTS (HTTP Strict Transport Security) politikalarını ve sertifika verilerini önbelleğe alır. Eski bir önbellek girişi, temel sorun çözüldükten sonra bile hatanın devam etmesine neden olabilir.

Google Chrome:

1. `chrome://settings/clearBrowserData` adresine gidin.
2. Zaman aralığını Tüm zamanlar olarak ayarlayın.
3. Çerezler ve diğer site verileri ile Önbelleğe alınmış resimler ve dosyalar seçeneklerini işaretleyin.
4. Verileri temizle seçeneğine tıklayın.

Chrome’da HSTS’ye özgü önbellek temizleme için `chrome://net-internals/#hsts` adresine gidin, “Alan adı güvenlik politikalarını sil” altına alan adını girin ve Sil seçeneğine tıklayın.

Mozilla Firefox:

1. Ayarlar > Gizlilik ve Güvenlik bölümünü açın.
2. Çerezler ve Site Verileri altında Verileri Temizle seçeneğine tıklayın.
3. Önbelleğe Alınmış Web İçeriği‘ni de temizleyin.

Microsoft Edge:

1. `edge://settings/clearBrowserData` adresine gidin.
2. Tüm zamanlar seçeneğini belirleyin ve önbelleğe alınmış verileri ile çerezleri temizleyin.

Adım 3: SSL İncelemesini Tanımlayın ve Devre Dışı Bırakın

Kurumsal bir ağdaysanız veya uç nokta güvenlik ürünü kullanıyorsanız, SSL incelemesi başlıca şüphelidir.

1. Tarayıcı adres çubuğundaki kilit simgesine (veya uyarı simgesine) tıklayın.
2. Sertifika ayrıntılarını inceleyin. Veren taraf DigiCert, Let’s Encrypt veya Sectigo gibi genel bir CA yerine antivirüs satıcınızsa (örn. “Avast Root,” “Kaspersky Anti-Virus,” “ESET SSL Filter CA”), SSL incelemesi etkindir.
3. Antivirüs veya güvenlik duvarı ayarlarınızda HTTPS tarama, SSL filtreleme veya Web Kalkanı seçeneğini bulun ve devre dışı bırakın.
4. Alternatif olarak, cihazın kök CA sertifikasını tarayıcınızın güven deposuna ekleyin.

Güvenlik yazılımınızı kalıcı olarak devre dışı bırakmayın. Test sonrasında yeniden etkinleştirin veya belirli güvenilen alan adlarını hariç tutacak şekilde yapılandırın.

Adım 4: Sunucu Tarafı Sertifika Zincirini Doğrulayın ve Onarın (Sunucu Yöneticileri)

Bu, ziyaretçilerin hatayı gördüğü üretim web siteleri için doğru düzeltmedir.

Zinciri teşhis edin:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Veya tam zincir incelemesini kullanın:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Döndürülen sertifika sayısını sayın. En az iki tane görmelisiniz (son varlık + ara). Yalnızca bir tane görünüyorsa, ara sertifika eksiktir.

Apache’de düzeltme (`httpd.conf` veya sanal ana bilgisayar dosyası):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Nginx’te düzeltme (`nginx.conf` veya sunucu bloğu):

Nginx, tam zincirin tek bir dosyada birleştirilmesini gerektirir:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Ardından referans verin:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Düzenlemeden sonra, yeniden başlatmadan önce her zaman yapılandırmayı test edin:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Ardından servisi yeniden yükleyin:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Yönetilen bir ortam çalıştırıyorsanız, cPanel ile VPS, yapılandırma dosyalarına manuel olarak dokunmadan sertifikayı, özel anahtarı ve CA paketini doğrudan yapıştırabileceğiniz SSL/TLS Yöneticisi altında bir GUI arayüzü sağlar.

Adım 5: Süresi Dolmuş Sertifikayı Yenileyin veya Değiştirin

Sertifikanın süresi dolmuşsa, istemci tarafında herhangi bir geçici çözüm yoktur. Sunucunun geçerli bir sertifika sunması gerekir.

Let’s Encrypt (Certbot) için:

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Manuel olarak yönetilen sertifikalar için: CA’nızdan yeni bir sertifika edinin, kontrol paneliniz aracılığıyla yükleyin ve yeni sertifikanın zincirinin eksiksiz olduğundan emin olun. Üretim alan adı için güvenilen bir sertifikaya ihtiyacınız varsa, tanınan bir CA’dan alınan SSL Sertifikaları kendinden imzalı sertifika sorununu tamamen ortadan kaldırır.

Yenilemeleri otomatikleştirin: Let’s Encrypt sertifikaları her 90 günde bir sona erer. Yenilemeyi otomatikleştirmek için bir cron görevi ekleyin veya systemd zamanlayıcılarını kullanın:

“`bash

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

“`

Adım 6: Dahili Kullanım için Kendinden İmzalı Sertifikaya Güvenin

Dahili araçlar, geliştirme sunucusu veya sertifikayı değiştirmenin mümkün olmadığı özel ağ hizmeti çalıştırıyorsanız, kendinden imzalı sertifikayı işletim sistemi güven deposuna ekleyebilirsiniz.

Windows:

1. Sertifikayı tarayıcıdan dışa aktarın (uyarıya tıklayın > Sertifika > Ayrıntılar > Dosyaya Kopyala).
2. `certmgr.msc` uygulamasını açın.
3. Güvenilen Kök Sertifika Yetkilileri > Sertifikalar bölümüne gidin.
4. Sağ tıklayın > Tüm Görevler > İçe Aktar ve sertifikayı içe aktarın.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Önemli: Linux ve Windows’ta Chrome, çoğu amaç için işletim sistemi güven deposunu kullanır, ancak kendi NSS veritabanını da korur. Chrome, işletim sistemi deposunu güncelledikten sonra sertifikayı hâlâ reddediyorsa, `chrome://settings/certificates` aracılığıyla doğrudan içe aktarın.

Adım 7: Tarayıcıyı ve İşletim Sistemini Güncelleyin

Güncel olmayan bir tarayıcı, daha yeni kök CA sertifikalarından yoksun olabilir veya mevcut TLS protokol sürümlerini desteklemeyebilir (minimum TLS 1.2 artık zorunludur; TLS 1.3 tercih edilir).

Chrome: `chrome://settings/help` adresine gidin. Chrome otomatik güncellenir; bekleyen bir güncelleme varsa buraya yüklenecektir.

Firefox: Yardım > Firefox Hakkında bölümüne gidin. Firefox güncellemeleri kontrol edecek ve uygulayacaktır.

İşletim Sistemi: Windows’ta Windows Update’in güncel olduğundan emin olun. Linux sunucularında şunu çalıştırın:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Bu, CA paketinin (`ca-certificates` paketi) daha yeni kök CA’ları içerecek şekilde güncellenmediği eski dağıtımları çalıştıran sunucular için özellikle önemlidir.

Adım 8: Ağ Yığınını Sıfırlayın ve DNS’i Temizleyin

Ağ düzeyindeki yanlış yapılandırmalar, bozuk DNS önbellekleri veya eski Winsock girişleri zaman zaman TLS müzakere hatalarına katkıda bulunabilir.

Windows (Komut İstemi’ni Yönetici olarak çalıştırın):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Bu komutları çalıştırdıktan sonra makineyi yeniden başlatın.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Adım 9: Uyarıyı Atlayın (Yalnızca Test Amaçlı)

Bu kesinlikle bir teşhis aracıdır, çözüm değildir. Yalnızca hatanın ağ veya uygulama sorunu değil sertifikayla ilgili olduğunu doğrulamak için veya geliştirme sırasında bilinen güvenli bir dahili sunucuya erişirken kullanın.

Chrome: Hata sayfasında Gelişmiş seçeneğine tıklayın, ardından [alan adına] git (güvensiz) seçeneğini seçin.

Firefox: Gelişmiş seçeneğine tıklayın, ardından Riski Kabul Et ve Devam Et seçeneğini seçin.

Kimlik doğrulama, ödeme veya kişisel veri işleyen sitelerde bu uyarıyı asla atlamayın. Uyarı, bağlantının gerçekten doğrulanmamış olması nedeniyle mevcuttur.

Düzeltmeyi Doğrulama

Herhangi bir sunucu tarafı değişikliği uyguladıktan sonra, sorunu çözüldü olarak ilan etmeden önce bu araçları kullanarak sonucu doğrulayın:

• SSL Labs SSL Testi (`ssllabs.com/ssltest/`): Tam zincir analizi, protokol destek notu ve belirli yapılandırma zayıflıklarını tanımlar.
• `openssl s_client`: TLS el sıkışması sırasında sunucunun tam olarak ne sunduğunu gösteren komut satırı doğrulaması.
• `curl -vI https://yourdomain.com`: TLS el sıkışma ayrıntılarını ve sertifika doğrulama sonucunu gösteren hızlı kontrol.
• `whatsmychaincert.com`: Eksik ara sertifikaları özellikle teşhis eder.

Tekrarı Önlemek için Doğru Barındırma Altyapısını Seçme

Birçok sertifika hatası, yönetici hatasından ziyade altyapı sınırlamalarından kaynaklanır. Paylaşımlı barındırma ortamları bazen sertifika zincirlerinin nasıl yapılandırıldığını kısıtlar veya web sunucusu yapılandırma dosyalarına erişimi sınırlar. Zincir veya yenileme sorunlarıyla tekrar tekrar karşılaşıyorsanız, VPS Barındırma ortamına geçmek size TLS yığınınız üzerinde tam kontrol sağlar — Nginx veya Apache’yi doğrudan yapılandırma, Certbot yenilemelerini otomatikleştirme ve özel CA paketleri yükleme dahil.

Sertifika yönetiminin kritik olduğu yüksek trafikli veya uyumluluk açısından hassas iş yükleri için, Dedicated Sunucular SSL yapılandırmasını karmaşıklaştırabilecek çok kiracılı değişkenleri ortadan kaldırır. Birden fazla alan adı veya alt alan adı yönetiyorsanız, VPS Kontrol Paneli tek bir arayüzden tümünde sertifika dağıtımını basitleştirir.

Karar Matrisi: Hangi Düzeltme Durumunuza Uygulanır

Pratik Temel Çıkarım Kontrol Listesi

• Herhangi bir işlem yapmadan önce hatanın istemci tarafı (saat, önbellek, SSL incelemesi) mi yoksa sunucu tarafı (süresi dolmuş sertifika, eksik ara sertifika) mı olduğunu doğrulayın.
• Herhangi bir sunucu tarafı araştırması için ilk teşhis adımı olarak `openssl s_client -connect domain:443 -showcerts` komutunu çalıştırın.
• Web sunucusu yapılandırmanızda her zaman tam sertifika zincirini (son varlık + tüm ara sertifikalar) birleştirin.
• Certbot cron görevleri veya eşdeğeriyle sertifika yenilemesini otomatikleştirin — manuel yenileme gelecekteki kesintilere giden garantili bir yoldur.
• Herhangi bir sertifika değişikliğinden sonra, olayı kapatmadan önce SSL Labs ile doğrulayın.
• Antivirüs SSL taramasını kalıcı olarak devre dışı bırakmayın; bunun yerine hariç tutmalar yapılandırın veya proxy CA sertifikasını düzgün şekilde yükleyin.
• Linux sunucularında, kök deposunun mevcut güvenilen CA’ları yansıttığından emin olmak için `ca-certificates` ve `openssl` paketlerini güncel tutun.
• Bir alan adının sertifikası meşru olarak değiştirildiğinde ve Chrome bağlanmayı hâlâ reddediyorsa HSTS önbellek girişlerini temizlemek için `chrome://net-internals/#hsts` kullanın.

Sıkça Sorulan Sorular

NET::ERR_CERT_AUTHORITY_INVALID ile NET::ERR_CERT_COMMON_NAME_INVALID arasındaki fark nedir?

`ERR_CERT_AUTHORITY_INVALID` sertifikanın vereninin güvenilir olmadığı anlamına gelir — zincir doğrulanamaz. `ERR_CERT_COMMON_NAME_INVALID` ise sertifikanın güvenilen bir CA’dan geldiği ancak erişilen alan adından farklı bir alan adı için verildiği anlamına gelir. Farklı düzeltmeler gerektirirler: birincisi güvenilen bir CA’dan yeni sertifika veya zincir onarımı gerektirir; ikincisi doğru Konu Alternatif Adlarıyla yeniden verilen sertifika gerektirir.

NET::ERR_CERT_AUTHORITY_INVALID geçerli, ücretli bir SSL sertifikasıyla bile görünebilir mi?

Evet. Güvenilen bir CA’dan alınan ücretli sertifika, ara sertifika sunucunun TLS yanıtına dahil edilmemişse bu hatayı tetikler. Tarayıcı eksik ara sertifikaları her zaman otomatik olarak getiremez (AIA getirme güvenilmezdir), bu nedenle zincirin sunucuda açıkça yapılandırılması gerekir.

Bu hata neden yalnızca Chrome’da görünür, Firefox’ta görünmez?

Firefox kendi sertifika güven deposunu korur ve önceki başarılı bağlantılardan ara sertifikaları önbelleğe alır (AIA getirme ve önbellekleme mekanizması). Chrome, işletim sistemi güven deposuna ve sunucu tarafından sunulan zincire daha katı biçimde dayanır. Firefox’un önceki bir oturumdan önbelleğe aldığı eksik bir ara sertifika, Chrome’un başarısız olmasına neden olmaya devam eder.

NET::ERR_CERT_AUTHORITY_INVALID uyarısında “Yine de devam et” seçeneğine tıklamak güvenli midir?

Yalnızca kontrollü senaryolarda: bilinen bir dahili sunucuya, yerel geliştirme ortamına veya yönettiğiniz bir hazırlık sunucusuna erişirken. Giriş kimlik bilgileri, ödeme bilgileri veya kişisel veri gerektiren herhangi bir genel siteye devam etmek gerçekten tehlikelidir. Bağlantı güven açısından şifrelenmemiştir, yani ağ yolundaki herhangi bir araya giren trafiği okuyabilir veya değiştirebilir.

Bu hatanın üretim sunucumda tekrarlanmasını nasıl önlerim?

Sertifika yenilemesini otomatikleştirin (Certbot ile cron görevi veya systemd zamanlayıcısı), sertifika son kullanma tarihini harici bir araçla izleyin (UptimeRobot, Zabbix veya `ssl-cert-check`), her zaman tam sertifika zincirini dağıtın ve sunucunuzun NTP senkronizasyonunu etkin tutun. Manuel yönetimin hataya açık olduğu ortamlar için entegre sertifika yönetimine sahip bir barındırma platformunu değerlendirin — cPanel ile VPS, barındırılan tüm alan adlarında AutoSSL yenilemelerini otomatik olarak yönetir.