Apache TLS 1.3 Yapılandırması ve Eski Protokol Devre Dışı Bırakma

Güvenli bir web sunucusu kurmak sadece SSL sertifikası yüklemekten ibaret değil. Asıl iş, hangi protokol versiyonlarına izin verdiğinizi, hangi cipher suite’leri kabul ettiğinizi ve eski, zayıf bağlantıları nasıl engellediğinizi doğru yapılandırmaktan geçiyor. TLS 1.0 ve TLS 1.1 artık resmi olarak deprecated edilmiş durumda ve bu protokolleri hâlâ açık bırakan sunucular hem güvenlik açığı barındırıyor hem de PCI-DSS, HIPAA gibi uyumluluk denetimlerinde ciddi sorunlarla karşılaşıyor. Bu yazıda Apache üzerinde TLS 1.3’ü nasıl etkinleştireceğinizi, eski protokolleri nasıl devre dışı bırakacağınızı ve tüm bunları production ortamında güvenli şekilde nasıl uygulayacağınızı ele alacağız.

Neden TLS 1.3 Önemli

TLS 1.2 hâlâ güvenli kabul ediliyor ancak TLS 1.3 buna kıyasla ciddi avantajlar sunuyor. Handshake süreci sadeleştirildi, gereksiz round-trip sayısı azaltıldı ve bağlantı kurma hızı belirgin şekilde arttı. Bunun yanında zayıf cipher’lar tamamen protokolden çıkarıldı, yani yanlışlıkla kötü bir cipher etkinleştirme ihtimaliniz ortadan kalktı.

Gerçek dünyadan bir örnek verelim: E-ticaret sitesi yöneten bir müşterimizin sunucusunu incelediğimizde TLS 1.0 açık durumdaydı ve POODLE, BEAST gibi saldırılara karşı savunmasız bir yapı vardı. Aynı zamanda tarayıcılar bu siteyi “güvensiz” olarak işaretlemeye başlamıştı. Basit bir yapılandırma değişikliği ile hem güvenlik skoru A+’ya çıktı hem de sayfa yükleme süreleri kısaldı çünkü TLS 1.3’ün 0-RTT özelliği devreye girdi.

Ön Gereksinimler

Başlamadan önce ortamınızın hazır olup olmadığını kontrol etmeniz gerekiyor.

OpenSSL versiyonu kritik: TLS 1.3 desteği için OpenSSL 1.1.1 veya üzeri gerekiyor. Daha eski OpenSSL versiyonlarında TLS 1.3 direktifi yazılsa bile çalışmıyor.

# OpenSSL versiyonunu kontrol edin
openssl version -a

# Apache'nin hangi OpenSSL ile derlendiğini öğrenin
apache2 -v
# veya RHEL/CentOS için
httpd -v

# Daha detaylı bilgi için
apache2ctl -M | grep ssl

Apache versiyonu: TLS 1.3 için Apache 2.4.36 veya üzeri gerekiyor. Çoğu modern dağıtımda bu versiyon mevcut ama eski CentOS 7 kurulumlarında sorunla karşılaşabilirsiniz.

# Apache versiyonunu kontrol edin
apache2 -v
httpd -v

# mod_ssl'in yüklü olduğunu doğrulayın
apache2ctl -M | grep ssl_module

Eğer ssl_module (shared) çıktısını görüyorsanız hazırsınız demektir. Ubuntu/Debian sistemlerde mod_ssl genellikle ayrı bir paket olarak geliyor:

# Ubuntu/Debian
sudo a2enmod ssl
sudo systemctl restart apache2

# RHEL/CentOS
sudo yum install mod_ssl
# veya
sudo dnf install mod_ssl

Mevcut TLS Yapılandırmasını Analiz Etme

Değişiklik yapmadan önce mevcut durumu belgelemeniz hem güvenli geçiş hem de geri dönüş senaryosu için önemli.

# Sunucunuzun hangi protokolleri desteklediğini test edin
# nmap ile
nmap --script ssl-enum-ciphers -p 443 yourdomain.com

# openssl ile TLS 1.0 test
openssl s_client -connect yourdomain.com:443 -tls1

# openssl ile TLS 1.1 test
openssl s_client -connect yourdomain.com:443 -tls1_1

# openssl ile TLS 1.2 test
openssl s_client -connect yourdomain.com:443 -tls1_2

# openssl ile TLS 1.3 test
openssl s_client -connect yourdomain.com:443 -tls1_3

Bu komutlardan gelen çıktıyı kaydedin. “Handshake failure” görüyorsanız o protokol desteklenmiyor demektir. Eğer bağlantı başarılı kuruluyorsa o protokol aktif demektir.

Online araçları da kullanabilirsiniz: SSL Labs’ın ssllabs.com/ssltest adresi detaylı bir rapor sunuyor. Değişiklik öncesi ve sonrası rapor alarak karşılaştırma yapmanızı şiddetle tavsiye ederim.

Temel TLS Yapılandırması

Apache’de SSL/TLS yapılandırması genellikle birkaç farklı yerde yapılabiliyor:

  • /etc/apache2/mods-enabled/ssl.conf (Ubuntu/Debian)
  • /etc/httpd/conf.d/ssl.conf (RHEL/CentOS)
  • VirtualHost bloklarının içinde

En temiz yaklaşım global SSL ayarlarını merkezi bir dosyada tutmak, site spesifik ayarları ise VirtualHost içinde yapmak. Şimdi adım adım yapılandırmayı görelim.

Global SSL Ayarları

# Ubuntu/Debian için
sudo nano /etc/apache2/mods-enabled/ssl.conf

# RHEL/CentOS için
sudo nano /etc/httpd/conf.d/ssl.conf

Dosyanın içeriği şu şekilde olmalı:

# Sadece TLS 1.2 ve TLS 1.3'e izin ver
# TLS 1.0 ve TLS 1.1 tamamen devre dışı
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Cipher suite'leri sunucu tercihine bırak
SSLHonorCipherOrder on

# TLS 1.2 için güvenli cipher suite'ler
# TLS 1.3 kendi cipher'larını otomatik kullanıyor
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

# TLS 1.3 cipher suite'leri (opsiyonel, genellikle varsayılan yeterli)
SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

# Session cache ayarları - performans için önemli
SSLSessionCache shmcb:/var/cache/apache2/ssl_scache(512000)
SSLSessionCacheTimeout 300

# OCSP Stapling - sertifika doğrulama hızlandırma
SSLUseStapling on
SSLStaplingCache shmcb:/var/cache/apache2/ssl_stapling(32768)
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off

SSLProtocol -all +TLSv1.2 +TLSv1.3: Bu satır önce tüm protokolleri devre dışı bırakıyor (-all), ardından sadece TLS 1.2 ve TLS 1.3’ü aktif ediyor. Syntax’a dikkat: artı ve eksi işaretleri kritik.

SSLHonorCipherOrder: Sunucunun cipher tercihini öne çıkarıyor. Böylece client zayıf bir cipher tercih etse bile sunucu daha güçlü olanı seçiyor. Ancak TLS 1.3’te bu direktifin etkisi yok çünkü protokol zaten sadece güvenli cipher’lara izin veriyor.

VirtualHost Yapılandırması

Global ayarlar tüm siteler için geçerli olsa da, kritik uygulamalar için VirtualHost bazında ek kısıtlamalar eklemek iyi bir pratik.

<VirtualHost *:443>
    ServerName secure.example.com
    ServerAlias www.secure.example.com
    
    DocumentRoot /var/www/secure
    
    # SSL sertifika ayarları
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/example.com.chain.crt
    
    # VirtualHost seviyesinde protokol kısıtlaması
    # Global ayarı ezebilirsiniz (override)
    SSLProtocol -all +TLSv1.3
    
    # Sadece TLS 1.3 kabul eden strict yapılandırma
    # Bunu sadece modern client'ların kullandığı API endpoint'lerinde yapın
    
    # HSTS header - tarayıcıya her zaman HTTPS kullan demek
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    
    # Ek güvenlik header'ları
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-XSS-Protection "1; mode=block"
    
    # Loglar
    ErrorLog ${APACHE_LOG_DIR}/secure-error.log
    CustomLog ${APACHE_LOG_DIR}/secure-access.log combined
    
</VirtualHost>

HTTP’den HTTPS’e Yönlendirme

TLS’i aktif ettikten sonra tüm HTTP trafiğini HTTPS’e yönlendirmeniz gerekiyor. Bunu yapmadan kullanıcılar hâlâ HTTP ile bağlanabilir.

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    
    # Tüm HTTP isteklerini HTTPS'e yönlendir
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
    
    # Alternatif yöntem - daha basit
    # Redirect permanent / https://example.com/
    
    # Let's Encrypt doğrulaması için istisna ekleyebilirsiniz
    # RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
</VirtualHost>

Burada 301 (kalıcı) yönlendirme kullanıyoruz. Test aşamasında 302 (geçici) kullanıp her şeyin doğru çalıştığından emin olduktan sonra 301’e geçin. Tarayıcılar 301’i cache’ledikleri için geri dönmek zor olabiliyor.

DH Parameters Oluşturma

Diffie-Hellman parametrelerini kendiniz oluşturmak ek bir güvenlik katmanı ekliyor. Özellikle DHE cipher’ları kullanıyorsanız bu zorunlu.

# 2048-bit DH parametresi oluştur (minimum)
# Bu işlem birkaç dakika sürebilir
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

# Daha güçlü 4096-bit (production için önerilen, ama daha uzun sürer)
sudo openssl dhparam -out /etc/ssl/certs/dhparam4096.pem 4096

# Dosya izinlerini ayarla
sudo chmod 644 /etc/ssl/certs/dhparam.pem

Oluşturduğunuz dosyayı Apache yapılandırmasına ekleyin:

# ssl.conf veya VirtualHost içinde
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

Yapılandırmayı Test Etme ve Uygulama

Production’da değişiklik yapmadan önce her zaman syntax kontrolü yapın. Bu basit adım sizi büyük bir outage’dan kurtarabilir.

# Apache syntax kontrolü - hata varsa servisi yeniden başlatmadan gösterir
sudo apache2ctl configtest
# veya
sudo httpd -t

# Hata yoksa "Syntax OK" göreceksiniz
# Ardından servisi yeniden yükleyin (restart yerine reload tercih edin)
sudo systemctl reload apache2
# veya RHEL/CentOS
sudo systemctl reload httpd

# Graceful restart da kullanabilirsiniz
sudo apache2ctl graceful

reload ve restart arasındaki fark önemli: restart tüm bağlantıları keser ve servisi yeniden başlatır. reload ise mevcut bağlantıları koruyarak sadece yapılandırmayı yeniden yükler. Production’da reload veya graceful kullanın.

Değişiklikten sonra testi tekrarlayın:

# TLS 1.0'ın bloke edildiğini doğrula
openssl s_client -connect yourdomain.com:443 -tls1
# "handshake failure" bekliyoruz

# TLS 1.1'in bloke edildiğini doğrula
openssl s_client -connect yourdomain.com:443 -tls1_1
# "handshake failure" bekliyoruz

# TLS 1.2'nin çalıştığını doğrula
openssl s_client -connect yourdomain.com:443 -tls1_2
# Başarılı bağlantı bekliyoruz

# TLS 1.3'ün çalıştığını doğrula
openssl s_client -connect yourdomain.com:443 -tls1_3
# Başarılı bağlantı bekliyoruz

# Hangi protokol ve cipher ile bağlandığınızı görün
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | grep -E "Protocol|Cipher"

OCSP Stapling ve Session Resumption

Bu iki özellik doğrudan güvenlikle ilgili olmasa da TLS performansını ciddi ölçüde etkiliyor ve kurumsal ortamlarda ihmal edilmemesi gereken konular.

OCSP Stapling: Sertifika geçerliliğini client’ın her seferinde doğrulama sunucusuna sorması yerine, web sunucusunun bu bilgiyi önceden alıp “zımbalayarak” client’a sunması. Hem bağlantı hızı artıyor hem de kullanıcı gizliliği korunuyor çünkü üçüncü parti bir sunucuya sorgu gönderilmiyor.

# VirtualHost içine ekleyin
SSLUseStapling on
SSLStaplingCache shmcb:/run/apache2/ssl_stapling(32768)

# Timeout ve hata yönetimi
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingFakeTryLater off

OCSP Stapling’in çalışıp çalışmadığını test etmek için:

openssl s_client -connect yourdomain.com:443 -status 2>/dev/null | grep -A 17 "OCSP Response"

Çıktıda OCSP Response Status: successful görüyorsanız çalışıyor demektir.

Güvenlik Header’larını Tamamlama

TLS yapılandırması tek başına yeterli değil. HTTP güvenlik header’larıyla bütünleşik bir güvenlik katmanı oluşturmanız gerekiyor. mod_headers modülünün aktif olduğundan emin olun:

# Ubuntu/Debian
sudo a2enmod headers
sudo systemctl reload apache2

Kapsamlı bir header yapılandırması:

<IfModule mod_headers.c>
    # HSTS - 2 yıl, subdomain'leri de kapsıyor, preload listesine giriş için hazır
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    
    # Content-Type sniffing'i engelle
    Header always set X-Content-Type-Options "nosniff"
    
    # Referrer bilgisini kısıtla
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    
    # Permissions Policy
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    
    # HTTPS bağlantıda SSL header'ını kaldır (versiyon gizleme)
    Header unset X-Powered-By
    ServerTokens Prod
    ServerSignature Off
</IfModule>

HSTS için önemli uyarı: max-age=63072000 (2 yıl) ile başlamayın. Önce 300 saniye gibi düşük bir değerle test edin, her şey yolundaysa artırın. HSTS’yi etkinleştirdikten sonra sitenizdeki tüm kaynakların HTTPS üzerinden sunulduğundan emin olun, aksi takdirde mixed content hataları çıkar.

Yaygın Sorunlar ve Çözümleri

Eski client’lar bağlanamıyor: TLS 1.0 ve 1.1’i kapattıktan sonra bazı eski cihazların (özellikle Android 4.x, eski IE) bağlanamadığını görebilirsiniz. Bu cihazları desteklemek zorundaysanız TLS 1.2’yi açık tutun ama TLS 1.0’ı kapalı bırakın. Günümüzde TLS 1.0 için artık gerçekten geçerli bir gerekçe yok.

OCSP Stapling çalışmıyor: Güvenlik duvarı OCSP sunucusuna giden 80. porta izin vermiyorsa stapling başarısız olur. Apache log’larını kontrol edin:

sudo tail -f /var/log/apache2/error.log | grep -i ocsp

Sertifika zinciri eksik: TLS handshake başarısız oluyorsa genellikle intermediate sertifika eksiktir. SSLCertificateChainFile direktifini kontrol edin.

# Sertifika zincirini doğrula
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt 
  -untrusted /etc/ssl/certs/intermediate.crt 
  /etc/ssl/certs/yourdomain.crt

Apache başlamıyor – DHparam hatası: DH parametre dosyası yanlış yerde veya izinleri hatalıysa Apache başlamaz. Log’a bakın ve dosya izinlerini kontrol edin:

ls -la /etc/ssl/certs/dhparam.pem
sudo chmod 644 /etc/ssl/certs/dhparam.pem

Monitoring ve Sertifika Yenileme Süreci

Yapılandırmayı tamamladıktan sonra düzenli takip şart. Sertifika sona erme tarihini gözden kaçırmak ciddi bir outage’a yol açabilir.

# Sertifika sona erme tarihini kontrol et
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | 
  openssl x509 -noout -dates

# Lokal sertifika dosyasını kontrol et
sudo openssl x509 -in /etc/ssl/certs/yourdomain.crt -noout -enddate

# 30 gün içinde sona erecek sertifikaları bul (script için)
sudo openssl x509 -in /etc/ssl/certs/yourdomain.crt -noout -checkend 2592000
# Çıkış kodu 0 ise sertifika hâlâ geçerli, 1 ise 30 gün içinde sona eriyor

Cron job ile otomatik sertifika kontrolü:

# /etc/cron.d/ssl-check dosyası
0 8 * * * root /usr/local/bin/check-ssl-expiry.sh >> /var/log/ssl-check.log 2>&1

Let’s Encrypt kullanıyorsanız Certbot otomatik yenileme yapıyor ama yenileme sonrası Apache’nin reload edilmesi gerekiyor:

# /etc/letsencrypt/renewal-hooks/deploy/ dizinine script ekleyin
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh << 'EOF'
#!/bin/bash
systemctl reload apache2
EOF
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-apache.sh

Tüm Yapılandırmayı Bir Arada Görme

Parça parça anlattıklarımızı bir araya getiren referans yapılandırma:

# /etc/apache2/sites-available/secure-site.conf

# HTTP -> HTTPS yönlendirme
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

# HTTPS VirtualHost
<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example
    
    # SSL temel ayarlar
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    
    # Protokol kısıtlaması
    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLHonorCipherOrder on
    
    # TLS 1.2 cipher'ları
    SSLCipherSuite HIGH:!aNULL:!MD5:!3DES:!RC4:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA
    
    # DH parametreleri
    SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"
    
    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    
    # Güvenlik header'ları
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    
    ErrorLog ${APACHE_LOG_DIR}/example-error.log
    CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

Sonuç

TLS 1.3 yapılandırması ve eski protokollerin devre dışı bırakılması tek seferlik bir iş değil, sürekli takip gerektiren bir süreç. Bugün yaptığınız yapılandırma 2 yıl sonra yetersiz kalabilir. Bu yüzden düzenli olarak SSL Labs testini tekrarlayın, cipher suite güncellemelerini takip edin ve OpenSSL/Apache güvenlik yamalarını zamanında uygulayın.

Özetlemek gerekirse kritik adımlar şunlar: TLS 1.0 ve 1.1’i kesinlikle kapatın, DHparam dosyası oluşturun, OCSP Stapling’i aktif edin, HSTS header’ını ekleyin ve sertifika yenileme sürecini otomasyona bağlayın. Bu adımların tamamını uyguladığınızda SSL Labs’tan A+ notu almanız gerekiyor. A+ notu sadece bir rozet değil, sunucunuzun gerçekten güvenli olduğunun somut bir göstergesi.

Production ortamında değişiklik yaparken daima: yapılandırmayı test sunucusunda deneyin, syntax kontrolü yapın, reload kullanın ve değişiklik öncesi/sonrası test raporlarını saklayın. Bu disiplini korursanız TLS geçişi sizi hiç tedirgin etmez.

Yorum yapın