Nginx/Apache’de ECDSA + RSA İkili SSL: Uyumluluk mu Hız mı? İkisini Birden Nasıl Alırsın?

Ofiste Başlayan Küçük Bir TLS Macerası

Hiç şöyle oldu mu? Bir gün sayfan gayet hızlı, ışıltılı açılıyor; ertesi gün bir müşteriden, “Telefonumdaki eski tarayıcıda site açılmıyor” diye bir e‑posta geliyor. İşte tam o gün, kahveni yudumlarken şunu düşünüyorsun: Hem hızdan ödün vermeden, hem de eski ve inatçı cihazları küstürmeden nasıl güvenli kalırım? Ben bu soruyu yıllar önce kendime sordum ve ECDSA + RSA ikili SSL yaklaşımıyla tanıştım. O gün bugündür yeni kurulumlarda neredeyse refleks olarak ikisini birlikte sunuyorum.

Bazen çözüm, tek bir doğruyu seçmekten değil, iki doğruyu akıllıca bir araya getirmekten geçiyor. ECDSA elin kolun gibi hafif ve çevik; RSA ise hâlâ geniş bir mahalleyle konuşabiliyor. İkisini aynı kapıda buluşturduğunda, modern tarayıcılar ECDSA’nın hızını kapıyor, daha çekingen olanlar da RSA’ya tutunup yoluna devam ediyor. Sonuç mu? Hem performans, hem uyumluluk.

Bu yazıda, Nginx ve Apache üzerinde ikili sertifika sunmayı, sahada karşıma çıkan küçük sürprizleri ve pratik ayarları adım adım anlatacağım. Dolaşık teknik terimlere boğulmadan, gerçek dünyadan örneklerle ilerleyelim. Mesela şöyle düşünün: Ziyaretçilerinize kapıda iki anahtar uzatıyorsunuz; hangisi cebe daha rahat sığıyorsa onu alıyor ve içeri giriyorlar. Hadi başlayalım.

ECDSA + RSA Neden Birlikte? Küçük Bir Yol Haritası

ECDSA, kısa ve öz imzaları seviyor. Sunucu tarafında imza atmak, elini çabuk tutan bir şef garson gibi. RSA ise yılların eskitemediği bir klasik. Halâ kimi eski cihazların ilk aşkı. Bu ikiliyi birlikte sunduğunda, modern tarayıcılar doğal olarak ECDSA’yı seçiyor. Eski dostlar da “Ben RSA’dan şaşmam” deyip bağlanıyor. Sen de performanstan taviz vermeden geniş bir uyumluluk yakalıyorsun.

Benim kafamda şöyle canlanıyor: ECDSA, özellikle mobil dünyada tıkanan anlarda ferahlatıcı bir nefes. RSA ise kurumsal duvarların arkasındaki eski TLS yığınlarıyla barış imzalıyor. İkisini birlikte sunmak, “herkese aynı ayakkabı” yerine “numarası uyana” mantığı. Bir taşla iki kuş, ama kuşları ürkütmeden.

Avantajların yanında birkaç küçük noktayı da dürüstçe söylemek gerek. Sertifika yönetimin biraz daha özen istiyor; iki sertifikayı birden yeniliyor, iki anahtarı da gözün gibi koruyorsun. Konfigürasyonda fazladan birkaç satır var, evet. Ama karşılığında aldığın konfor, özellikle trafik çeşitlendiğinde yüz güldürüyor.

Sertifikaları Nasıl Ediniyoruz? Küçük Ama Temiz Adımlar

Hangi Tür, Hangi Boyut?

ECDSA tarafında genelde secp256r1 (prime256v1) eğrisi günlük hayat için gayet dengeli. X25519 da popüler. RSA tarafında 2048 çoğu senaryo için yeterli oluyor, çok hassas ortamlarda 3072’ye uzanmak mümkün. Burada mesele, gereksiz yere ağırlaşmadan makul güvenlikte kalabilmek. ECDSA daha hafif koşuyor, RSA ise geniş camiaya sesleniyor. İkisini yan yana koyduğunda, tarayıcılar kendi kapasitelerine göre seçiyor zaten.

Let’s Encrypt ile İkili Sertifika

Ben çoğu projede Let’s Encrypt’le pratik ilerliyorum. İstersen aynı alan adı için ayrı ayrı bir ECDSA, bir de RSA sertifikası alabilirsin. Çoğu ACME istemcisi bu süreci iki komutla hallediyor. Mesela ECDSA için anahtar ve sertifika üretip, sonra RSA için de aynısını yapıyorsun. Konfigürasyonda ikisini birlikte işaretlediğinde sunucu, istemcinin desteklediğine göre doğru sertifikayı seçiyor.

OpenSSL ile Minik Bir Atölye

Diyelim ki üretimi kendin yapmak istiyorsun. Basit bir atölye kuralım:

# ECDSA özel anahtar (prime256v1) ve CSR
openssl ecparam -name prime256v1 -genkey -noout -out /etc/ssl/private/site-ecdsa.key
openssl req -new -key /etc/ssl/private/site-ecdsa.key -out /etc/ssl/csr/site-ecdsa.csr -subj "/CN=example.com"

# RSA özel anahtar ve CSR
openssl genrsa -out /etc/ssl/private/site-rsa.key 2048
openssl req -new -key /etc/ssl/private/site-rsa.key -out /etc/ssl/csr/site-rsa.csr -subj "/CN=example.com"

Oluşan CSR’ları sertifika sağlayıcına veriyorsun. Geri dönen sertifikaları da tam zinciriyle birlikte saklıyorsun. Ben klasör hiyerarşisini net tutmayı seviyorum; ecdsa ve rsa dosyalarını isimleriyle ayırınca kafa karışmıyor.

Nginx’te ECDSA + RSA İkili Sertifika Nasıl Sunulur?

Nginx, birden fazla sertifika satırını gayet olgun karşılıyor. ECDSA ve RSA sertifikalarını art arda tanımladığında, istemciye göre doğru olanı otomatik sunuyor. Ben şöyle bir yapı kullanıyorum, gayet de temiz.

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

    # ECDSA sertifika ve anahtar
    ssl_certificate     /etc/ssl/certs/site-ecdsa-fullchain.pem;
    ssl_certificate_key /etc/ssl/private/site-ecdsa.key;

    # RSA sertifika ve anahtar
    ssl_certificate     /etc/ssl/certs/site-rsa-fullchain.pem;
    ssl_certificate_key /etc/ssl/private/site-rsa.key;

    # TLS sürümleri ve şifre kümeleri (makul, sade bir yaklaşım)
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;

    # Eğriler (ECDSA için yaygın ve hızlı seçenekler)
    ssl_ecdh_curve X25519:prime256v1;

    # OCSP stapling (isteyen istemciye taze bilgi sunmak iyi hissettirir)
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # HSTS (canlıya almadan önce iyi düşün; CDN/alt alanlar vs.)
    # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

Burada akılda tutulması gereken küçük bir not: TLS 1.3 ile şifre kümeleri biraz farklı ilerliyor, ama bu temel ayar çoğu senaryoda işini görür. HTTP/2’yi de devreye almak kafadan bir nefes aldırıyor. Eğer istersen ALPN müzakeresine dokunmadan varsayılan akışla bile gayet modern bir sonuç alırsın.

İşin mTLS tarafını merak ediyorsan, Nginx tarafında istemci sertifikası doğrulamasını ayrıca kurarsın. Ben süreçleri Nginx ve Caddy’de mTLS kurulumunun püf noktaları yazısında adım adım anlatmıştım; ikili sertifika modelinle birlikte sorunsuz yürür.

Apache’de ECDSA + RSA Çoklu Sertifika: Temiz Bir Sanat

Apache 2.4.8 ve sonrası, aynı sanal host içinde birden fazla sertifika dosyası tanımlamayı destekliyor. Sahnede iki oyuncu var ve sırayla yerlerini alıyorlar. Dert yok, sadece tertipli yazmak gerekiyor. Ben en basit haliyle şu düzeni tercih ediyorum:

<VirtualHost *:443>
    ServerName example.com

    # RSA çifti
    SSLCertificateFile    /etc/ssl/certs/site-rsa-fullchain.pem
    SSLCertificateKeyFile /etc/ssl/private/site-rsa.key

    # ECDSA çifti
    SSLCertificateFile    /etc/ssl/certs/site-ecdsa-fullchain.pem
    SSLCertificateKeyFile /etc/ssl/private/site-ecdsa.key

    # Protokol ve şifreler (sade ve dengeli)
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder on

    # OCSP stapling
    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off

    ProxyPass        / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

Burada önemli olan, sertifika ve anahtarların doğru eşleştiğinden emin olmak. Ben dosya adlarında “rsa” ve “ecdsa” ibarelerini kullanarak karışıklığın önüne geçiyorum. Bir de mod_ssl’in yüklü ve etkin olduğundan emin ol. Apache esnek bir usta; doğru verdiğinde karşılığını veriyor.

Performans ve Uyumluluk: Dengeleri Nazikçe Ayarlamak

Gerçek hayatta trafik karışık. HTTP/2 sevenler var, hâlâ HTTP/1.1 ile kalanlar var. Mobil ağın nefesi dar, ofis ağları bazen şirket duvarlarıyla meşgul. İkili sertifika, bu kalabalıkta herkese bir sandalye sunuyor. Modern tarayıcı ECDSA’yı tercih ediyor, daha eski bir istemci RSA ile bağlanıyor. Sen de “tek bir yol” dayatmadan herkese kibarca alan açıyorsun.

Ben ECDSA’yı özellikle mobil sahnede hissedilir buluyorum. Kısa imzalar, daha hafif el sıkışmalar demek. RSA’nın kıymeti ise eski ve görece kısıtlı TLS yığınlarında. İkisi bir arada olunca, “ya hız ya uyumluluk” ikilemi biraz eriyor. Üstelik sunucu kaynaklarında da daha dengeli bir tablo görüyorsun. İmza atma işi ECDSA’da düşük maliyetliyken, bazı bağlantılar RSA ile ilerlese bile toplam hissiyat tatlı kalıyor.

Yapılandırmada küçük dokunuşlar da fark ettiriyor. Oturum yeniden kullanımı canlı olursa, el sıkışmanın maliyeti düşüyor. OCSP stapling’le sertifika doğrulama süresi kısalıyor. HTTP/2 etkinken aynı bağlantıda birden fazla istek taşımak gözle görülür bir rahatlık sağlıyor. Bu işte “küçük ayarlar” toplandıkça hissedilen hız büyüyor.

Canlı Geçiş: Trafiği Ürkütmeden Nasıl Taşırız?

Ben canlı geçişlerde önce kapalı ortamda doğrulamayı seviyorum. İki sertifika doğru yükleniyor mu, zincirler tam mı, OCSP stapling çalışıyor mu? Nginx’te ve Apache’de hata günlüklerine kısa bir göz atmak çoğu sürprizi daha doğmadan yakalıyor. Sonrasında küçük bir kullanıcı dilimini yeni node’a yönlendirip izlemek iyi bir yöntem. İlgili grafikleri kontrol edince, ECDSA bağlantı oranlarının arttığını görüyorsun; bu, modern istemcilerin doğal akışta ECDSA’yı benimsediğinin basit bir işareti.

Yük dengeleyici kullanıyorsan, TLS’i önde bitirip arkaya sade HTTP taşıyabilirsin. Ya da uçtan uca şifrelemeyi gözetip passthrough’la arkaya bırakabilirsin. Seçim senin mimarinin ritmine bağlı. Bu konuyu daha detaylı düşünenler için HAProxy ile TLS passthrough ve sağlık kontrolleri üzerine sahadan notlar yazısı tatlı bir eşlikçi olur.

CDN katmanında çalışan projelerde ise, ara katman da el sıkışmaya dahil olabiliyor. Cloudflare gibi hizmetler, öndeki müşteri trafiğini modernleştirirken arkaya doğru yine ikili sertifikayı sunabilirsin. Bu dengeyi konuşurken, Cloudflare ile WebSocket ve gRPC trafiğini canlı tutmanın püf noktalarını anlattığım rehberde de bağlantı sürekliliği tarafını detaylandırmıştım.

Test Etmeden Olmaz: Küçük Kontroller, Büyük Rahatlık

Kendi makinenizden şöyle küçük testler iyi fikir verir. Basit bir kontrolle sunucunun ne sunduğunu görebilirsin:

# Genel bir bakış
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | grep -E "Server public key|subject=|issuer="

# TLS 1.3 denemesi (destekliyse)
openssl s_client -connect example.com:443 -servername example.com -tls1_3 < /dev/null | grep -E "Server public key|subject=|issuer="

Dışarıdan bakan bir gözle rapor almak istediğinde, gönül rahatlığıyla SSL Labs’ın ayrıntılı testini çalıştır. Ayrıca ayarları toparlarken, sade ve güncel bir referans olarak Mozilla’nın TLS yapılandırma önerileri elini güçlendirir. Let’s Encrypt tarafında da sertifika türleri ve ipuçları için resmi doküman sayfasını kenarda açık tutmayı seviyorum.

Küçük Tuzaklar: Başımıza Gelenler ve Yoldaki Taşlar

Bir kere zincir dosyasını eksik koymuş, üst otoriteyi unuttuğum için bazı istemcilerde tuhaf hatalar görmüştüm. Gözden kaçıyor, oluyor. O yüzden “fullchain” dosyalarıyla çalışmak işini kolaylaştırıyor. Bir başka defa, OCSP stapling için resolver tanımlamayı unutup gereksiz gecikmelere sebep olmuştum. Küçük ama can sıkıcı. Bir satırla düzeliyor, yine de başta akılda tutmalı.

HSTS’i kurarken fazla atak davranıp tüm alt alanları dahil edince, ayrı bir test alanı için gereksiz engeller oluşmuştu. Canlıya almadan önce bir süre gözlem yapmak iyi geliyor. Bir de yük testlerinde, CPU grafiğine bir göz at. ECDSA imza maliyeti düşük olsa da, anlık patlamalarda beklenmedik noktalar ortaya çıkabiliyor. Bu yüzden ufak bir yoğunluk testiyle sınırlarını görmek iyi alışkanlık.

mTLS gibi gelişmiş akışlar da bu düzenle barış içinde yaşar. İstemci sertifikalarını doğrularken sunucu sertifikasının ikili olması hiçbir sorun yaratmıyor. İhtiyaç olursa yönetim panellerini mTLS ile korumak konusunda yazdığım notlar pratikte çok işe yarıyor.

Uyumluluk ve Politika: PCI-DSS ve Dış Denetimler Korkulacak Şeyler Değil

İş e‑ticarete, kart verisi dokunan akışlara geldiğinde, denetimler ve sorular kapıyı çalıyor. İkili sertifika yaklaşımı burada bir engel değil, aksine düzgün ayarlanmış bir TLS politikasıyla kartların daha temiz oynandığı bir tablo çiziyor. Eski protokolleri kapatmak, sağlam şifre kümeleri seçmek ve zincirleri tam kurmak zaten beklenen temel adımlar.

Detaylarda kaybolmadan “nereden başlamalıyım?” diyenler için kendi tecrübelerimi topladığım bir yazıyı önerebilirim: PCI-DSS uyumlu WooCommerce ortamında TLS tarafı için pratik başlangıç noktaları. Oradaki akışla, burada anlattıklarımız birbirini tamamlıyor.

Bakım Rutini: Yenile, Test Et, Günlükleri Dinle

İkili sertifika kurulumunun en güzel yanı, kurduktan sonra gerisinin bir ritme oturması. Sertifikaları birlikte yenilemeyi bir takvime bağla. Otomasyon kullanıyorsan, yenileme sonrası konfigürasyonu test edip servisi kibarca yeniden yüklemeyi sakın unutma. Kısa bir reload ile tüm trafik yeni sertifikalara döner, kimse fark etmez bile.

Günlükleri arada bir dinlemek de iyi fikir. Hata kodları, el sıkışma uyarıları, stapling mesajları küçük ipuçları veriyor. Bir de ara sıra dışarıdan test al; yeni tarayıcı sürümleri, eski cihazların kaprisleri derken, tablo zamanla değişiyor. İkili yaklaşım bu değişime karşı zaten esnek duruyor, ama sen yine de gözünü dört aç.

Kapanış: Hızla Barış, Uyumluluğu Kucakla

Toparlayalım. ECDSA + RSA ikili SSL, modern trafiğin hız isteğiyle eski dünyanın inadı arasında akıllı bir köprü kuruyor. Nginx ve Apache, bu köprüyü inşa etmek için yeterince olgun. Sertifikaları iki koldan hazırlayıp, konfigürasyonda yan yana tanımladığında, ziyaretçi hangi taraftan gelirse gelsin güler yüzle karşılanıyor.

Pratikte birkaç noktaya özen yetiyor: Zincir dosyalarını tam kullan, OCSP stapling’i aç, eski protokolleri kapat, HTTP/2’yi rahat rahat koştur. Canlı geçişi küçük bir trafik dilimiyle test etmek, içini iyice rahatlatır. Sonrasında zaten akış kendi dengesini buluyor.

Umarım bu rehber, kafandaki soru işaretlerini biraz olsun dağıtmıştır. Bir sonraki projende, ikili sertifikayı kurup ilk trafiği gördüğünde o tatlı ferahlığı hissedeceksin. Merak ettiklerin olursa yaz, konuşalım. Bu arada TLS dünyasının diğer köşeleri de ilginç; istersen SMTP tarafında TLS’i güçlendirme ipuçları gibi yazılara da göz at. Bir dahaki yazıda görüşmek üzere.