OCSP Stapling Nedir ve Web Sunucu Performansına Etkisi

SSL sertifika doğrulama mekanizmaları, web güvenliğinin temel taşlarından biri olmakla birlikte, çoğu sysadmin için performans kaygılarının da başladığı noktadır. Bir kullanıcı sitenize bağlandığında, tarayıcısı arka planda sessiz sedasız bir sürü iş yapar ve bu işlerin bir kısmı ciddi gecikmelere yol açabilir. OCSP Stapling tam da bu noktada devreye girerek hem güvenliği korur hem de kullanıcı deneyimini iyileştirir.

Sertifika İptal Kontrolü Neden Gerekli?

Bir SSL/TLS sertifikası alındığında, bu sertifikanın geçerlilik süresi boyunca güvenilir olması beklenir. Ancak gerçek dünyada işler her zaman bu kadar düzgün gitmez. Özel anahtar ele geçirilmiş olabilir, şirketi temsil eden kişi kurumdan ayrılmış olabilir ya da sertifika bir şekilde yanlış yapılandırılmış olabilir. Bu gibi durumlarda sertifikanın süresinin dolmasını beklemek yerine hemen iptal edilmesi gerekir.

İşte bu iptal durumunu kontrol etmek için iki klasik yöntem geliştirilmiştir:

  • CRL (Certificate Revocation List): Sertifika otoritesi, iptal edilen sertifikaların bir listesini yayınlar. Tarayıcı bu listeyi indirir ve sertifikanın listede olup olmadığını kontrol eder.
  • OCSP (Online Certificate Status Protocol): Tarayıcı, sertifika otoritesinin OCSP sunucusuna direkt sorgu atar ve “Bu sertifika geçerli mi?” diye sorar.

CRL yöntemi zamanla kullanışsız hale geldi çünkü bu listeler büyüdükçe indirme süreleri de uzadı. OCSP daha pratik bir çözüm sundu ama kendi içinde başka problemler getirdi.

Klasik OCSP’nin Problemi: Gizlilik ve Gecikme

Tarayıcı OCSP sorgusu gönderdiğinde ne olduğunu bir düşünün. Kullanıcı sitenize bağlanmak istiyor, tarayıcı önce sertifika otoritesinin OCSP sunucusuna gidiyor (örneğin Let’s Encrypt için ocsp.int-x3.letsencrypt.org), sorgu gönderiyor, cevap bekliyor ve ancak ondan sonra bağlantıyı kuruyor. Bu süreç:

  • Ek DNS çözümlemesi gerektirir
  • Ek TCP bağlantısı açılmasına neden olur
  • Coğrafi gecikme yaratır (OCSP sunucusu başka bir ülkede olabilir)
  • Gizlilik ihlali oluşturur (CA hangi siteye gittiğinizi öğrenir)

Bir web sitesini ziyaret ettiğinizde tarayıcınız o sitenin sertifika otoritesine “Hey, şu an example.com’u ziyaret ediyorum, bu sertifika geçerli mi?” der gibi bir mesaj gönderiyor aslında. Bu durum ciddi bir privacy problemi.

Dahası, OCSP sunucusu yavaşsa ya da geçici olarak erişilemez durumdaysa ne olur? Çoğu tarayıcı “soft-fail” modunu uygular, yani hata durumunda sertifikayı geçerli sayar. Bu da güvenlik açısından tartışmalı bir yaklaşım.

OCSP Stapling: Sunucu Devreye Giriyor

OCSP Stapling (RFC 6066 ile standartlaştırılmış) bu problemi zarif bir şekilde çözer. Mekanizma şu şekilde çalışır:

Web sunucunuz periyodik olarak kendi adına OCSP sorgusunu yapar ve CA’dan aldığı imzalı yanıtı önbelleğe alır. Ardından bir istemci TLS el sıkışması (handshake) başlattığında, sunucu bu imzalı OCSP yanıtını sertifikayla birlikte “zımba gibi” (staple) istemciye iletir. İstemci artık CA’ya ayrıca sorgu göndermek zorunda kalmaz.

Bu yaklaşımın avantajları:

  • Gizlilik korunur: CA artık kullanıcının hangi siteyi ziyaret ettiğini bilemez
  • Gecikme azalır: Ekstra bir network round-trip ortadan kalkar
  • Güvenilirlik artar: OCSP sunucusu down olsa bile önbellekteki yanıt geçerli kalmaya devam eder
  • Sunucu kontrolü: Birden fazla istemci için tek bir OCSP sorgusu yeterlidir

Nginx’te OCSP Stapling Yapılandırması

Nginx’te OCSP Stapling’i etkinleştirmek oldukça basittir. Önce mevcut konfigürasyonu inceleyelim:

# Mevcut SSL konfigürasyonunu kontrol et
nginx -T | grep -A 20 "ssl_"

# SSL modülünün derlenip derlenmediğini kontrol et
nginx -V 2>&1 | grep -o "with-http_ssl_module"

Ana konfigürasyon bloğuna aşağıdaki direktifleri ekleyin:

# /etc/nginx/sites-available/example.com

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # OCSP Stapling aktif et
    ssl_stapling on;
    ssl_stapling_verify on;

    # CA zincir sertifikası (fullchain kullanıyorsan genellikle otomatik çözülür)
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    # DNS resolver - OCSP sunucusunu resolve etmek için
    resolver 8.8.8.8 8.8.4.4 1.1.1.1 valid=300s;
    resolver_timeout 5s;

    # Diğer SSL ayarları
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
}

Konfigürasyonu test edip yeniden yükleyin:

# Syntax kontrolü
nginx -t

# Konfigürasyonu yeniden yükle (bağlantıları kesmeden)
systemctl reload nginx

# Ya da
nginx -s reload

Apache’de OCSP Stapling Yapılandırması

Apache için süreç biraz farklıdır. Apache 2.3.3 ve üzeri sürümlerde mod_ssl modülü OCSP Stapling desteği sunar:

# Gerekli modüllerin yüklü olup olmadığını kontrol et
apachectl -M | grep -E "ssl|socache"

# Modülleri etkinleştir (Debian/Ubuntu)
a2enmod ssl
a2enmod socache_shmcb

Virtual host konfigürasyonu:

# /etc/apache2/sites-available/example.com.conf

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/example

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    # OCSP Stapling aktif et
    SSLUseStapling On
    SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors Off

    # Önbellek süresi ayarı (saniye cinsinden)
    SSLStaplingStandardCacheTimeout 3600
    SSLStaplingErrorCacheTimeout 300

    # SSL protokol ve cipher ayarları
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
</VirtualHost>

Apache’yi yeniden başlat:

# Syntax kontrolü
apachectl configtest

# Graceful restart
apachectl graceful

OCSP Stapling’i Test Etme

Yapılandırmayı tamamladıktan sonra düzgün çalışıp çalışmadığını doğrulamak kritik önem taşır. Bunun için birkaç yöntem kullanabilirsiniz:

# OpenSSL ile OCSP Stapling kontrolü
# -status parametresi OCSP stapling yanıtını talep eder
echo QUIT | openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 20 "OCSP Response"

# Daha detaylı çıktı için
openssl s_client -connect example.com:443 
  -servername example.com 
  -status 
  -tlsextdebug 2>&1 | grep -E "OCSP|TLS"

Başarılı bir OCSP Stapling çıktısı şuna benzer görünmelidir:

OCSP response:
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: ...
    Produced At: Oct  1 10:00:00 2024 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: ...
    Cert Status: good
    This Update: Oct  1 10:00:00 2024 GMT
    Next Update: Oct  8 10:00:00 2024 GMT

Eğer çıktıda OCSP response: no response sent görüyorsanız, stapling henüz aktif değildir veya bir sorun var demektir.

Neden “Resolver” Direktifi Önemli?

Nginx’te resolver direktifini unutmak çok sık yapılan bir hata. Nginx, OCSP yanıtını önbelleğe almak için OCSP sunucusunun adresini çözümlemesi gerekir. Bu direktif olmadan stapling sessiz sedasız başarısız olur:

# Nginx log'larını kontrol et - OCSP hatalarını görmek için
tail -f /var/log/nginx/error.log | grep -i ocsp

# Resolver çalışıyor mu kontrol et
dig @8.8.8.8 ocsp.int-x3.letsencrypt.org

# Yerel DNS resolver kullanmak istiyorsanız (dikkatli olun, bazen sorun çıkarır)
# resolver 127.0.0.1 valid=300s;

# Şirket içi DNS'iniz varsa onu da ekleyebilirsiniz
# resolver 192.168.1.1 8.8.8.8 valid=300s;

Let’s Encrypt ile OCSP Stapling: Özel Durumlar

Let’s Encrypt kullanıyorsanız birkaç noktaya dikkat etmeniz gerekir. Let’s Encrypt sertifikaları için zincir dosyası genellikle chain.pem veya fullchain.pem olarak gelir:

# Let's Encrypt sertifika dosyalarını incele
ls -la /etc/letsencrypt/live/example.com/
# cert.pem - Sertifikanın kendisi
# chain.pem - Ara sertifika zinciri
# fullchain.pem - cert.pem + chain.pem birleşimi
# privkey.pem - Özel anahtar

# Sertifikanın OCSP URL'ini kontrol et
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem 
  -noout -text | grep -A 5 "OCSP"

# Çıktıda şunu görmelisiniz:
# OCSP - URI:http://ocsp.int-x3.letsencrypt.org

Certbot ile sertifika yenileme sırasında OCSP stapling konfigürasyonunun bozulmaması için:

# Certbot post-hook scripti oluştur
cat > /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh << 'EOF'
#!/bin/bash
# Sertifika yenilendikten sonra Nginx'i reload et
nginx -t && systemctl reload nginx
echo "$(date): Nginx reloaded after certificate renewal" >> /var/log/letsencrypt/reload.log
EOF

chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

Performans Etkisini Ölçme

OCSP Stapling’in gerçek performans etkisini görmek için karşılaştırmalı test yapmak gerekir. Basit bir script ile bunu ölçebilirsiniz:

#!/bin/bash
# ocsp_perf_test.sh
# OCSP Stapling performans karşılaştırması

TARGET="example.com"
ITERATIONS=10

echo "=== OCSP Stapling Performans Testi ==="
echo "Hedef: $TARGET"
echo ""

total_time=0

for i in $(seq 1 $ITERATIONS); do
    # TLS handshake süresini ölç
    result=$(curl -w "%{time_connect},%{time_appconnect},%{time_total}" 
        -o /dev/null -s "https://$TARGET")
    
    time_connect=$(echo $result | cut -d',' -f1)
    time_appconnect=$(echo $result | cut -d',' -f2)
    time_total=$(echo $result | cut -d',' -f3)
    
    tls_time=$(echo "$time_appconnect - $time_connect" | bc)
    
    echo "İterasyon $i: TLS handshake = ${tls_time}s, Toplam = ${time_total}s"
    total_time=$(echo "$total_time + $tls_time" | bc)
done

avg_time=$(echo "scale=4; $total_time / $ITERATIONS" | bc)
echo ""
echo "Ortalama TLS Handshake Süresi: ${avg_time}s"

Gerçek dünya rakamlarına bakıldığında, OCSP Stapling etkinleştirildiğinde TLS handshake süresinde genellikle 50-200ms arasında iyileşme görülür. Bu değer özellikle OCSP sunucusunun farklı bir coğrafyada bulunduğu durumlarda daha belirgin olur.

Sorun Giderme: Yaygın Hatalar

OCSP Yanıtı Alınamıyor

# Sunucudan OCSP sunucusuna erişimi test et
curl -v http://ocsp.int-x3.letsencrypt.org

# Firewall kurallarını kontrol et - giden HTTP trafiğine izin var mı?
iptables -L OUTPUT -n | grep -E "80|443"

# Outbound HTTP izni ver (gerekiyorsa)
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

Sertifika Zinciri Eksik

# Zincir sertifikasının doğruluğunu kontrol et
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt 
  /etc/letsencrypt/live/example.com/fullchain.pem

# Zincirdeki sertifikaları listele
openssl crl2pkcs7 -nocrl 
  -certfile /etc/letsencrypt/live/example.com/fullchain.pem | 
  openssl pkcs7 -print_certs -noout

Must-Staple Özelliği: Bir Adım Öteye

Eğer güvenliği daha da sıkılaştırmak istiyorsanız, sertifikanıza “TLS Feature” uzantısı ekleyebilirsiniz. Bu uzantı tarayıcılara “Bu sertifika için her zaman OCSP Stapling beklemelisiniz” mesajını verir:

# Certbot ile Must-Staple destekleyen sertifika al
certbot certonly 
  --must-staple 
  --standalone 
  -d example.com 
  -d www.example.com

# Mevcut sertifikanın Must-Staple içerip içermediğini kontrol et
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem 
  -noout -text | grep -A 3 "TLS Feature"

Must-Staple dikkatli kullanılması gereken bir özelliktir. Eğer sunucunuzda OCSP Stapling düzgün çalışmıyorsa ve sertifikanızda Must-Staple varsa, tarayıcılar bağlantıyı reddedecektir. Üretim ortamında önce staging/test ortamında denemenizi öneririm.

Monitoring: OCSP Stapling’i Takip Altına Almak

OCSP Stapling’in sürekli çalışıp çalışmadığını izlemek için basit bir monitoring scripti işinize yarar:

#!/bin/bash
# check_ocsp_stapling.sh
# Cron ile her saat çalıştırabilirsiniz

DOMAIN="example.com"
ALERT_EMAIL="[email protected]"
LOG_FILE="/var/log/ocsp_check.log"

check_ocsp() {
    local domain=$1
    local result
    
    result=$(echo QUIT | openssl s_client 
        -connect "${domain}:443" 
        -servername "${domain}" 
        -status 2>/dev/null | grep "OCSP Response Status")
    
    if echo "$result" | grep -q "successful"; then
        echo "$(date): OK - $domain OCSP stapling çalışıyor" >> "$LOG_FILE"
        return 0
    else
        echo "$(date): HATA - $domain OCSP stapling yanıt vermiyor" >> "$LOG_FILE"
        echo "UYARI: $domain için OCSP Stapling çalışmıyor!" | 
            mail -s "OCSP Stapling Hatası" "$ALERT_EMAIL"
        return 1
    fi
}

check_ocsp "$DOMAIN"

Bu scripti cron’a ekleyin:

# Her saat başı kontrol et
echo "0 * * * * root /usr/local/bin/check_ocsp_stapling.sh" >> /etc/cron.d/ocsp-check

Kurumsal Ortamlarda OCSP Stapling

Büyük kurumsal ortamlarda genellikle kendi CA’larından (örneğin Microsoft AD CS veya HashiCorp Vault) sertifika alırsınız. Bu durumda iç OCSP sunucularının Nginx veya Apache tarafından erişilebilir olması gerekir. Şirket içi proxy kullanıyorsanız Nginx’in OCSP sorgularını bu proxy üzerinden yapması gerekebilir:

# Nginx, proxy ortam değişkenlerini doğrudan kullanmaz
# Ancak OCSP sunucusuna erişim için özel resolver kullanabilirsiniz

# /etc/nginx/nginx.conf içinde global resolver ayarı
http {
    resolver 10.0.0.10 10.0.0.11 valid=300s;  # İç DNS sunucuları
    resolver_timeout 10s;
    
    # Diğer ayarlar...
}

Sonuç

OCSP Stapling, kurulumu ve yönetimi açısından düşük maliyetli ama etkisi son derece yüksek bir güvenlik ve performans iyileştirmesidir. Özet olarak bakacak olursak:

  • Sunucu taraflı OCSP sorgulama, istemcilerden kaynaklanan ek gecikmeleri ortadan kaldırır
  • Kullanıcı gizliliği korunur çünkü CA artık hangi sitelerin ziyaret edildiğini öğrenemez
  • Nginx’te ssl_stapling on ve ssl_stapling_verify on ile birkaç satırda aktif edilebilir
  • resolver direktifini unutmamak kritik önem taşır
  • Monitoring ile OCSP Stapling’in sağlıklı çalışıp çalışmadığını takip altında tutmak gerekir
  • Must-Staple ek güvenlik katmanı sunar ama üretimde dikkatli uygulanmalıdır

Bir sistemi yönetirken TLS performansı genellikle göz ardı edilen alanlardan biridir. Oysa OCSP Stapling gibi küçük bir konfigürasyon değişikliği, özellikle yüksek trafikli sitelerde hem sunucu kaynaklarını hem de son kullanıcı deneyimini gözle görülür biçimde iyileştirir. Let’s Encrypt kullananlar için bu konfigürasyonu yapmak artık neredeyse zorunluluk haline geldi diyebilirim.

Yorum yapın