Tarayıcı SSL Uyarılarını Anlama ve Giderme

yazar

Bir sabah işe geliyorsunuz, kullanıcılardan şikayetler yağıyor: “Siteye girmeye çalışıyorum ama tarayıcı beni uyarıyor, devam etmeli miyim?” Bu senaryoyu yaşadıysanız, SSL sertifika sorunlarının ne kadar can sıkıcı olduğunu biliyorsunuzdur. Hem kullanıcı güvenini zedeler hem de SEO’yu olumsuz etkiler. Bu yazıda tarayıcı SSL uyarılarının arkasında ne yattığını, nasıl teşhis edeceğinizi ve nasıl kalıcı olarak çözeceğinizi anlatacağım.

SSL Uyarıları Neden Oluşur?

Tarayıcılar SSL/TLS sertifikalarını doğrularken birkaç temel kontrol yapar. Bu kontrollerden herhangi biri başarısız olursa kullanıcıya uyarı gösterir. Uyarının türünü anlamak, çözüme giden en hızlı yoldur.

Sertifika Süresi Dolmuş

En yaygın sorun budur. Let’s Encrypt sertifikaları 90 günde bir yenilenmesi gerekir, ticari sertifikalar ise genellikle 1-2 yıllıktır. Otomatik yenileme ayarlanmamışsa veya bir şeyler ters gitmişse sertifika sona erer.

# Sertifikanın son kullanma tarihini kontrol et
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Yerel sertifika dosyasını kontrol et
openssl x509 -noout -dates -in /etc/ssl/certs/example.com.crt

# Kaç gün kaldığını hesapla
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -checkend 86400
# Çıktı: Certificate will not expire within 86400 seconds (1 gün)

-checkend parametresi çok kullanışlıdır. Verdiğiniz saniye sayısı içinde sertifikanın dolup dolmayacağını söyler. 0 çıktısı “süresi dolmayacak”, 1 çıktısı “süresi dolacak” anlamına gelir. Bunu bir cron job ile otomatize edebilirsiniz.

Alan Adı Uyuşmazlığı (Hostname Mismatch)

Sertifika www.example.com için düzenlenmiş ama siz example.com üzerinden erişiyorsunuz veya tam tersi. Ya da api.example.com için sertifika yok. Bu durum özellikle subdomain yapılandırmalarında sık yaşanır.

# Sertifikada hangi alan adlarının kapsandığını gör
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

# CN (Common Name) alanını kontrol et
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -subject

Modern sertifikalar artık Subject Alternative Name (SAN) kullanıyor. Eski stil Common Name (CN) tek başına yeterli değil. Wildcard sertifika (*.example.com) kullanıyorsanız, bu yalnızca tek seviye subdomain’leri kapsar. Yani sub.sub.example.com için geçerli olmaz.

Güvenilmeyen Sertifika Otoritesi

Sertifikayı imzalayan CA (Certificate Authority), tarayıcının güven listesinde yoksa bu uyarı çıkar. Self-signed sertifikalar, kendi PKI altyapınızdan üretilmiş sertifikalar veya nadir görülen CA’lardan alınan sertifikalar bu durumu tetikler.

Eksik Ara Sertifika (Intermediate Certificate)

Bu sorun özellikle acemi sistem yöneticilerini zorlayan bir durumdur. Sunucu sadece son sertifikayı sunuyor, ancak ara sertifikaları (chain) göndermiyordur. Bazı tarayıcılar bunu tolere ederken diğerleri uyarı gösterir.

# Sertifika zincirini kontrol et
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | grep "BEGIN CERTIFICATE" | wc -l
# 1 çıkıyorsa zincir eksik olabilir, 2 veya 3 beklenir

# Detaylı zincir bilgisi
openssl s_client -connect example.com:443 -showcerts 2>/dev/null

Teşhis Araçları ve Yöntemleri

Uyarının kaynağını bulmak için birkaç farklı araç kullanabilirsiniz.

openssl Komutu ile Kapsamlı Teşhis

# Tam SSL握手 simülasyonu
openssl s_client -connect example.com:443 -servername example.com

# TLS versiyonunu belirterek test et
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3

# Sertifika zincirini kaydet ve doğrula
openssl s_client -connect example.com:443 -showcerts 2>/dev/null > /tmp/chain.pem
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /tmp/chain.pem

curl ile Hızlı Kontrol

# SSL hatası alıyorsanız detaylı çıktı
curl -vvI https://example.com 2>&1 | grep -E "(SSL|TLS|certificate|expire|verify)"

# Sertifika doğrulamasını atlayarak bağlantı testi (sorun tespiti için)
curl -k https://example.com

# Belirli bir CA bundle kullanarak test
curl --cacert /path/to/ca-bundle.crt https://example.com

curl -k kullanımı yalnızca sorun tespiti içindir. Üretim ortamında asla sertifika doğrulamasını atlamayın.

nmap ile SSL Analizi

# SSL/TLS konfigürasyonunu tarama
nmap --script ssl-enum-ciphers -p 443 example.com

# Sertifika bilgilerini çekme
nmap --script ssl-cert -p 443 example.com

# Zayıf şifreleme algoritmalarını tespit etme
nmap --script ssl-dh-params -p 443 example.com

Yaygın Senaryolar ve Çözümleri

Senaryo 1: Let’s Encrypt Sertifikası Yenilenmemiş

Certbot kullanıyorsanız ve otomatik yenileme bir şekilde durmuşsa:

# Certbot'un durumunu kontrol et
systemctl status certbot.timer
certbot certificates

# Manuel yenileme dene
certbot renew --dry-run
certbot renew

# Nginx veya Apache'yi yeniden başlat
systemctl reload nginx
# veya
systemctl reload apache2

Eğer certbot timer çalışmıyorsa:

# Timer'ı yeniden etkinleştir
systemctl enable certbot.timer
systemctl start certbot.timer

# Cron ile alternatif yenileme (eğer systemd kullanmıyorsanız)
crontab -e
# Şu satırı ekle:
# 0 2 * * * /usr/bin/certbot renew --quiet && systemctl reload nginx

Senaryo 2: Nginx’te Eksik Sertifika Zinciri

Bu çok sık yaşanan bir durumdur. CA’dan sertifikanız geldi, kurulumu yaptınız ama bazı kullanıcılar hala uyarı alıyor.

# Mevcut sertifika zincirini kontrol et
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/nginx/ssl/example.com.crt

# Tam zinciri birleştir (sertifika + intermediate + root)
cat example.com.crt intermediate.crt > /etc/nginx/ssl/example.com.fullchain.crt

# Nginx konfigürasyonunu güncelle
# /etc/nginx/sites-available/example.com
# ssl_certificate /etc/nginx/ssl/example.com.fullchain.crt;  # fullchain kullan
# ssl_certificate_key /etc/nginx/ssl/example.com.key;

# Konfigürasyonu test et
nginx -t
systemctl reload nginx

Senaryo 3: Apache’de SSL Yapılandırması

# Apache SSL modülünü etkinleştir
a2enmod ssl
a2ensite default-ssl

# /etc/apache2/sites-available/example.com-ssl.conf içinde
# SSLEngine on
# SSLCertificateFile /etc/ssl/certs/example.com.crt
# SSLCertificateKeyFile /etc/ssl/private/example.com.key
# SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

# Apache konfigürasyonunu test et
apachectl configtest
systemctl reload apache2

Senaryo 4: Self-Signed Sertifika Kullanan İç Ağ Servisleri

Kurumsal ortamlarda iç servisler için kendi CA’nızdan sertifika üretip kullanıcı cihazlarına CA sertifikasını dağıtmanız gerekir.

# Kendi CA'nızı oluştur
openssl genrsa -out /etc/ssl/private/myCA.key 4096
openssl req -x509 -new -nodes -key /etc/ssl/private/myCA.key 
  -sha256 -days 3650 
  -out /etc/ssl/certs/myCA.crt 
  -subj "/C=TR/ST=Istanbul/L=Istanbul/O=Sirketim/CN=Sirketim Internal CA"

# Bu CA ile yeni sertifika imzala
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr 
  -subj "/C=TR/ST=Istanbul/O=Sirketim/CN=internal.sirketim.local"

# SAN ekleyerek imzala (bu kritik!)
cat > server.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = internal.sirketim.local
DNS.2 = *.sirketim.local
IP.1 = 192.168.1.100
EOF

openssl x509 -req -in server.csr -CA /etc/ssl/certs/myCA.crt 
  -CAkey /etc/ssl/private/myCA.key -CAcreateserial 
  -out server.crt -days 825 -sha256 -extfile server.ext

Önemli not: Chrome ve modern tarayıcılar artık 825 günden uzun geçerlilik süresine sahip sertifikalara güvenmez. Bu yüzden maksimum 825 gün kullanın.

CA sertifikasını Linux sistemlere dağıtmak için:

# Ubuntu/Debian
cp myCA.crt /usr/local/share/ca-certificates/
update-ca-certificates

# RHEL/CentOS/Rocky Linux
cp myCA.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

# Dağıtımı doğrula
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt server.crt

SSL Uyarılarını İzleme ve Proaktif Yönetim

Yangın çıktıktan sonra söndürmek yerine, önceden tedbir almak çok daha sağlıklı bir yaklaşım. İşte birkaç pratik monitoring yöntemi:

Otomatik Sertifika Kontrolü

#!/bin/bash
# /usr/local/bin/ssl-check.sh
# Cron ile günlük çalıştırın

DOMAINS="example.com api.example.com mail.example.com"
WARN_DAYS=30
ALERT_EMAIL="[email protected]"

for domain in $DOMAINS; do
    expiry=$(echo | openssl s_client -servername $domain 
        -connect $domain:443 2>/dev/null | 
        openssl x509 -noout -enddate 2>/dev/null | 
        cut -d= -f2)
    
    expiry_epoch=$(date -d "$expiry" +%s)
    now_epoch=$(date +%s)
    days_left=$(( ($expiry_epoch - $now_epoch) / 86400 ))
    
    if [ $days_left -lt $WARN_DAYS ]; then
        echo "UYARI: $domain sertifikasi $days_left gun sonra doluyor!" | 
        mail -s "SSL Sertifika Uyarisi: $domain" $ALERT_EMAIL
        echo "[$domain] $days_left gun kaldi - UYARI gonderildi"
    else
        echo "[$domain] $days_left gun kaldi - OK"
    fi
done
# Scripti çalıştırılabilir yap ve cron'a ekle
chmod +x /usr/local/bin/ssl-check.sh
echo "0 8 * * * /usr/local/bin/ssl-check.sh >> /var/log/ssl-check.log 2>&1" | crontab -

Windows Sunucuda SSL Sorunları

Windows ortamında da benzer sorunlar yaşanabilir. IIS kullananlar için:

# PowerShell ile sertifika kontrolü
$cert = Get-ChildItem -Path Cert:LocalMachineMy | Where-Object {$_.Subject -like "*example.com*"}
$cert | Select-Object Subject, NotAfter, Thumbprint

# 30 gün içinde dolacak sertifikaları bul
$threshold = (Get-Date).AddDays(30)
Get-ChildItem -Path Cert:LocalMachineMy | Where-Object {$_.NotAfter -lt $threshold} | 
Select-Object Subject, NotAfter, Thumbprint

# Sertifika zincirini doğrula
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.Build($cert)
$chain.ChainElements | ForEach-Object {$_.Certificate.Subject}

HSTS ve Önbellek Sorunları

Bazen SSL uyarısı gerçek bir sertifika sorunundan değil, HSTS önbelleğinden kaynaklanır. Özellikle test ortamlarında self-signed’dan gerçek sertifikaya geçişte bu sorun yaşanır.

Tarayıcı HSTS önbelleğini temizlemek için:

  • Chrome: chrome://net-internals/#hsts adresine gidin, domain için “Delete” yapın
  • Firefox: Profil klasöründeki SiteSecurityServiceState.txt dosyasını silin

Sunucu tarafında HSTS başlığını kontrol edin:

# HSTS başlığını kontrol et
curl -sI https://example.com | grep -i "strict-transport"

# Nginx'te HSTS ayarı
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Eğer sorun yaşıyorsanız max-age'i önce düşürün
# add_header Strict-Transport-Security "max-age=86400" always;

Cipher Suite ve TLS Versiyon Sorunları

Eski sunucular hala TLS 1.0 veya TLS 1.1 kullanıyorsa modern tarayıcılar uyarı gösterir.

# Desteklenen TLS versiyonlarını test et
nmap --script ssl-enum-ciphers -p 443 example.com | grep -E "(TLSv|SSLv)"

# Nginx'te sadece TLS 1.2 ve 1.3'ü etkinleştir
# /etc/nginx/nginx.conf içinde:
# 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;

# Değişiklikleri uygula
nginx -t && systemctl reload nginx

# Tekrar test et
openssl s_client -connect example.com:443 -tls1
# "handshake failure" almalısınız - bu iyi!

Hızlı Referans: Hata Mesajları ve Anlamları

Tarayıcıların gösterdiği hata mesajları aslında oldukça açıklayıcıdır:

  • NET::ERR_CERT_DATE_INVALID: Sertifika süresi dolmuş veya sistem saati yanlış
  • NET::ERR_CERT_AUTHORITY_INVALID: CA güvenilir değil veya self-signed
  • NET::ERR_CERT_COMMON_NAME_INVALID: Alan adı uyuşmazlığı, SAN eksik
  • NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: SHA-1 gibi zayıf algoritma kullanılmış
  • NET::ERR_SSL_PROTOCOL_ERROR: TLS handshake başarısız, versiyon uyumsuzluğu
  • NET::ERR_CERT_REVOKED: Sertifika iptal edilmiş (CRL veya OCSP kontrolü)
  • SEC_ERROR_UNKNOWN_ISSUER: Firefox’ta CA bulunamadı

Sistem saati sorunu sık atlanan bir detaydır. Sunucunun saati yanlışsa sertifika henüz geçerli olmayabilir veya süresi çoktan dolmuş görünebilir:

# NTP senkronizasyonunu kontrol et
timedatectl status
chronyc tracking

# NTP'yi yeniden başlat
systemctl restart chronyd
# veya
systemctl restart ntp

Sonuç

SSL sertifika uyarıları genellikle basit nedenlerden kaynaklanır: süresi dolmuş sertifika, eksik zincir veya alan adı uyuşmazlığı. Sorunun üstüne sistematik gidildiğinde çoğu zaman birkaç dakikada çözülür. Asıl amaç bu sorunları reaktif değil proaktif yönetmek olmalı.

Birkaç temel alışkanlık edinin: sertifika son kullanma tarihlerini izleyin, otomatik yenilemeyi mutlaka kurun ve her zaman fullchain sertifika kullanın. Let’s Encrypt için certbot, ticari sertifikalar için ise organizasyonunuza uygun bir sertifika yönetim sistemi kurmak uzun vadede çok zaman kazandırır.

Kurumsal ortamlarda kendi CA’nızı işletiyorsanız, CA sertifikasının tüm cihazlara dağıtılması için GPO veya MDM çözümleri kullanın. Böylece iç servisler için her kullanıcı ayrı ayrı uyarıya muhatap olmaz.

Son olarak, kullanıcılarınıza SSL uyarılarını geçip geçmemek konusunda kendi başlarına karar vermelerini bırakmayın. “Devam et” seçeneğini tıklamak bir alışkanlık haline gelirse, gerçek bir man-in-the-middle saldırısında da aynı şeyi yapmaları işten bile değildir.

Yorum yapın