İki sertifika bütün eski istemcileri destekler mi?

Hayır. RSA seçeneği yardımcı olabilir; istemcinin protokol, şifre, imza ve güven zinciri desteği de uygun olmalıdır. Temsilî cihazları ve iki sertifika yolunu ayrı test edin.

ECDSA sertifikası mutlaka ECDSA issuer ister mi?

Hayır. Yaprak anahtarının türü ile CA’nın imza anahtarı ayrı konulardır. Sertifikayı gerçekten imzalayan CA zincirini ve istemcinin güven yolunu doğrulayın.

Let’s Encrypt için OCSP stapling gerekli mi?

Hayır. Let’s Encrypt OCSP hizmetini Ağustos 2025’te kapattı. Güncel sertifikalar için staple beklenmez; OCSP parçaları yalnız bu hizmeti sürdüren CA sertifikalarına uygulanır.

Nginx ve Apache’de RSA ve ECDSA İkili Sertifika

ECDSA + RSA ile TLS Performansı ve Uyumluluk

ECDSA ve RSA sertifikalarını aynı hostta sunmak, farklı kimlik doğrulama desteğine sahip istemcileri karşılamak için değerlendirilebilir. Bu yöntem her eski cihazın bağlanacağını veya sayfaların hızlanacağını garanti etmez; protokol, şifre takımı, sertifika zinciri ve güven deposu da uyumlu olmalıdır.

Sunucu, istemcinin bildirdiği yetenekleri ve kendi yapılandırmasını kullanarak sertifikalardan birini seçer. Modern istemci daima ECDSA seçmez; RSA sertifikasının bulunması da desteklenmeyen TLS sürümünü veya güvenilmeyen zinciri düzeltmez. İki sertifikanın faydasını gerçek istemciler ve ölçülen yükle değerlendirin.

Bu rehber aynı alan adı kapsamı için ayrı ECDSA ve RSA anahtarları ve sertifikaları hazırlamayı, Nginx/Apache’de sunmayı ve her iki yolu sınamayı açıklar. Türkçe uygulama örnekleri, zaten çalışan yerel HTTP uygulamasına ters vekillik eder; TLS ayarları uygulama kurulumu yerine geçmez. İngilizce sürümdeki statik dosya örnekleri gibi uygulama işleyicileri ayrıca seçilmelidir.

ECDSA ve RSA’yı Birlikte Kullanmanın Sınırları

ECDSA bazı iş yüklerinde daha küçük anahtar ve imzalarla el sıkışma maliyetini azaltabilir. RSA, ECDSA desteği olmayan ancak diğer TLS ve güven koşullarını karşılayan istemciler için seçenek sağlar. Kazanım donanım, TLS kütüphanesi, sertifika zinciri, istemci dağılımı ve bağlantı yeniden kullanımına bağlıdır.

TLS 1.2’de seçilen şifre takımı kimlik doğrulama türünü de etkiler; örnekte hem ECDHE-ECDSA hem ECDHE-RSA takımları bulunur. TLS 1.3’te şifre takımı sertifika türünü seçmez; imza algoritmaları ve sertifika seçimi ayrı değerlendirilir. CA’nın sertifikaya attığı imza sabittir, el sıkışma sırasında yeniden seçilmez.

İki sertifika, iki özel anahtarın korunması ve iki yenileme kaydının izlenmesi anlamına gelir. Her sertifikanın süresini, SAN kapsamını, zincirini ve dağıtım sonucunu ayrı doğrulayın. Birinin çalışması diğerinin hazır olduğunu kanıtlamaz.

İki Sertifika ve Anahtar Çiftini Hazırlama

Anahtar Türü, Boyutu ve Alan Adı Kapsamı

Örnekte ECDSA için P-256 (prime256v1/secp256r1), RSA için 2048 bit anahtar kullanılır. Gerekli anahtar boyutunu güvenlik politikanız ve istemci desteğiniz belirlemelidir. X25519 bir anahtar anlaşması grubudur, ECDSA imza anahtarı değildir. İki sertifikada aynı gerekli host adları SAN içinde yer almalıdır.

Let’s Encrypt ile İkili Sertifika

Let’s Encrypt veya başka bir ACME CA’dan aynı hostlar için ayrı ECDSA ve RSA sertifikaları alınabilir. İstemcinin iki ayrı sertifika kaydını ve yenileme yolunu nasıl yönettiğini kontrol edin. Let’s Encrypt OCSP hizmetini Ağustos 2025’te kapattığından bu CA’nın güncel sertifikalarında stapling yanıtı beklenmez.

OpenSSL ile Anahtar ve CSR Üretimi

Aşağıdaki OpenSSL 1.1.1+ uyumlu örneği ayrı bir kabuk betiği olarak, dual-cert-work dizini henüz yokken çalıştırın. Kod yeni, özel izinli bir çalışma dizininde anahtar ve CSR üretir; mevcut sunucu anahtarlarının üzerine yazmayın. Özel anahtarlar şifrelenmemiştir ve 0600 izinle saklanır. Host adlarını değiştirin. CSR, CA tarafından imzalanmış sertifika değildir.

#!/bin/sh
# Run as a separate script in a directory where dual-cert-work does not exist.
set -eu
umask 077
mkdir -m 700 dual-cert-work
cd dual-cert-work

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out site-ecdsa.key
openssl req -new -sha256 -key site-ecdsa.key -out site-ecdsa.csr \
  -subj '/CN=example.com' \
  -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out site-rsa.key
openssl req -new -sha256 -key site-rsa.key -out site-rsa.csr \
  -subj '/CN=example.com' \
  -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'
chmod 600 site-ecdsa.key site-rsa.key

openssl req -in site-ecdsa.csr -noout -verify -text
openssl req -in site-rsa.csr -noout -verify -text

CSR’ları CA’nın doğrulama sürecine gönderin. İstenen SAN’ların gerçekten verilen sertifikalarda bulunduğunu kontrol edin; CA her istenen uzantıyı otomatik kabul etmek zorunda değildir. Sunucuyu yapılandırmadan önce her verilen sertifikayı doğru özel anahtar ve CA’nın sağladığı ara zincirle eşleştirin, dosyaları örnek dağıtım yollarına uygun izinlerle yerleştirin. Özel anahtarları public web köküne koymayın.

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

Nginx’te farklı türler için tekrarlanan ssl_certificate desteği 1.11.0’dan, ayrı sertifika zincirleri OpenSSL 1.0.2’den itibaren vardır. Aşağıdaki modern http2 on örneği Nginx 1.25.1+ ve SSL/HTTP2 modüllerini, TLS 1.3 ise uyumlu OpenSSL 1.1.1+ gerektirir. Bunlar özellik sınırlarıdır; bakım alan sürümleri kullanın. 127.0.0.1:8080 üzerinde çalışan güvenilir uygulamayı önce doğrulayın. Sertifika dosyaları CSR değil, verilmiş yaprak ve gerçek ara sertifika zinciridir.

server {
    listen 443 ssl;
    http2 on;
    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 ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    # Anahtar anlaşması grupları; X25519 ECDSA imza eğrisi değildir
    ssl_ecdh_curve X25519:prime256v1;

    # Baseline for certificates without an active OCSP service, including Let’s Encrypt.
    ssl_stapling off;

    # HSTS (canlıya almadan önce iyi düşün; CDN/alt alanlar vs.)
    # After HTTPS is verified, opt in with a short lifetime:
    # add_header Strict-Transport-Security "max-age=300" always;

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

ssl_ciphers TLS 1.2 ve öncesine uygulanır; TLS 1.3 burada kütüphane varsayılanlarını kullanır. ssl_ecdh_curve anahtar anlaşması gruplarını belirler; ECDSA sertifikanızın eğrisiyle uyumu da koruyun. HTTP/2 performansı iş yüküne bağlıdır ve ALPN ile müzakere edilir. İki sertifika satırının sırası tek başına hangi türün seçileceğini garanti etmez.

mTLS istemci sertifikası doğrulaması, sunucunun RSA/ECDSA sertifika seçimine ek bir akıştır. Nginx ve Caddy mTLS rehberindeki istemci güven ve kimlik eşleme kurallarını ayrıca yapılandırıp iki sunucu sertifikası yoluyla birlikte test edin.

Apache’de RSA ve ECDSA Sertifikaları

Apache, farklı kimlik doğrulama türleri için SSLCertificateFile direktifini tekrarlayabilir. 2.4.8 sürümü özellikle ara sertifikaların aynı dosyada bulunmasını destekler; bu tarih ilk çoklu sertifika desteğiyle karıştırılmamalıdır. Sertifika başına ayrı zincir için OpenSSL 1.0.2+, TLS 1.3 için 1.1.1+ gerekir. Bakım alan, TLS 1.3 destekli Apache 2.4 kullanın. Bu ters vekil örneği mod_ssl, mod_proxy ve mod_proxy_http ile önceden çalışan yerel uygulamayı gerektirir.

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on

    # 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 +TLSv1.2 +TLSv1.3
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
    SSLHonorCipherOrder off

    # No OCSP service is assumed for this baseline.
    SSLUseStapling Off

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

Her sertifika/anahtar çiftinin eşleşmesini ve SAN kapsamını doğrulayın. Apache örneğinde SSLProtocol açıkça yalnız TLS 1.2 ve 1.3’ü seçer. TLS 1.3 şifreleri TLS 1.2 listesinden ayrıdır. Mevcut sanal hostlar, varsayılan host ve SNI davranışını da denetleyin; SNI göndermeyen istemciler için ayrı uyumluluk testi gerekir.

Performans ve İstemci Uyumluluğunu Ölçme

Temsilî istemci gruplarını belirleyin: kullandıkları TLS sürümü, imza ve şifre desteği, SNI davranışı ve CA güven deposu farklı olabilir. Başarısızlıkları bu özelliklerle ilişkilendirin; yalnız modern/eski ayrımına göre sertifika tercih sırası varsaymayın.

ECDSA ve RSA için el sıkışma süresi, CPU, hata oranı ve sertifika zinciri boyutunu aynı koşullarda ölçün. Oturum yeniden kullanımı tam el sıkışma sayısını değiştirdiğinden ilk ve tekrar bağlantıları ayrı değerlendirin. Anahtar boyutunu sırf ölçümü iyileştirmek için politika gereksiniminin altına düşürmeyin.

Oturum yeniden kullanımı ve HTTP/2 ayrı performans kararlarıdır. OCSP stapling yalnız CA sunuyorsa ve istemci bundan yararlanıyorsa ayrı durum sorgusunu azaltabilir. Let’s Encrypt için yanıt eksikliği arıza değildir. Kaynağın OCSP sunucusuna ulaşamaması, bütün Nginx el sıkışmalarının mutlaka yavaşladığını kanıtlamaz.

TLS Sonlandırma ve Kademeli Dağıtım

Önce test ortamında iki sertifikayı, zincirleri, anahtarları ve uygulama yanıtlarını doğrulayın. Sözdizimi kontrolünden sonra küçük bir trafik dilimiyle dağıtım yapın. Varsa sertifika türü dağılımını, bağlantı hatalarını ve gecikmeyi izleyin. ECDSA oranının artması tek başına hız veya uyumluluk kanıtı değildir.

TLS’in nerede sonlandığını belirleyin. Uçta sonlandırılıyorsa ziyaretçiye sunulan sertifikaları o bileşen seçer; backend bağlantısının şifrelemesi ayrı karardır. TLS passthrough kullanılıyorsa sertifika seçimi Nginx/Apache’ye ulaşır. SNI ve ALPN ile gerçek uçtan uca davranışı test edin. HAProxy TLS passthrough ve sağlık kontrolleri rehberi bu ayrımı açıklar.

CDN sertifikası ile origin sertifikası farklı bağlantılarda kullanılır. Origin’de iki sertifika kurmak CDN’in ziyaretçiye hangi sertifikayı sunacağını değiştirmez. Uç ve origin güven politikalarını ayrı doğrulayın; ilgili uygulama bağlantıları için Cloudflare ile WebSocket ve gRPC rehberini inceleyebilirsiniz.

İki Sertifika Yolunu Test Etme

Aşağıdaki genel görüntüleme komutları yalnız seçilen bağlantıyı gösterir; ikisinin de çalıştığını veya zincirin doğrulandığını tek başına kanıtlamaz. Tanıda hata çıktısını saklayın. TLS 1.2’de iki kimlik doğrulama yolunu ayrı zorlayarak ayrıca sınayın:

openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -verify_hostname example.com -verify_return_error -showcerts < /dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 -verify_hostname example.com -verify_return_error -showcerts < /dev/null

Bu testler iki şifre/sertifika yolunu sınar; bütün eski cihazları taklit etmez. Doğru istemci CA deposunu kullanın ve gerekirse uygun CA dosyasını belirtin. showcerts sunucunun gönderdiği listeyi gösterir; doğrulamayı dönüş kodu ve hatalarla değerlendirin.

# 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="

Temsilî cihaz testlerini SSL Labs değerlendirmesi ile tamamlayın. Sürüme uygun ayarlar için Mozilla TLS oluşturucusunu, CA zincirleri ve sertifika işlemleri için Let’s Encrypt belgelerini kullanın.

Zincir, OCSP ve HSTS Kontrolleri

Her yaprak sertifikayı onu gerçekten imzalayan CA zinciriyle birleştirin. ECDSA yaprak mutlaka ECDSA anahtarlı issuer ile, RSA yaprak mutlaka RSA issuer ile gelmek zorunda değildir. Sunucu anahtar türüyle CA imzasını ayırın; zinciri isim etiketlerine göre değil imza ve güven yolu üzerinden doğrulayın.

HSTS varsayılan örnekte kapalıdır. HTTPS ve aynı hosta yönlendirme doğrulandıktan sonra yalnız host için max-age=300 ile başlayıp gözlenen aşamalarla artırabilirsiniz. includeSubDomains için iç sistemler dahil bütün alt alanlar HTTPS’e hazır olmalı; preload ayrı bir uzun vadeli tercihtir. OCSP sunan başka bir CA için aşağıdaki parçaların yerlerini ve önkoşullarını izleyin. Nginx parçasını uygularken mevcut ssl_stapling off; satırını ssl_stapling on; ile değiştirin; ikisini aynı server bloğunda bırakmayın. Apache’de de ilgili VirtualHost içindeki SSLUseStapling Off satırını SSLUseStapling On ile değiştirin. Nginx güven paketine iki sertifikanın gerekli issuer, ara ve köklerini koyun; örnek DNS ve dosya yollarını değiştirin. Apache shmcb önbelleği mod_socache_shmcb ister ve VirtualHost dışında olmalıdır. Güncel Let’s Encrypt için bu parçaları kullanmayın.

# Nginx: inside an OCSP-capable certificate server block only.
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /path/to/issuers-intermediates-roots.pem;
resolver 192.0.2.53 valid=300s;
resolver_timeout 5s;

# Apache: global configuration, outside ALL VirtualHost blocks.
# Load mod_socache_shmcb; use an existing Apache runtime directory.
SSLStaplingCache shmcb:/path/to/apache-run/ocsp(128000)

# Apache: inside the applicable OCSP-capable VirtualHost only.
SSLUseStapling On
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors Off

mTLS’de istemci sertifikası güveni ve erişim kararı ayrıca test edilmelidir; iki sunucu sertifikası tüm istemci doğrulama durumlarında sorunsuzluğu garanti etmez. Yönetim panellerini mTLS ile koruma rehberi bu ayrı yapılandırmayı ele alır.

Uyumluluk ve Politika

İki sertifika sunmak tek başına PCI DSS veya başka bir standarda uyumluluk sağlamaz. Protokol ve şifre politikası, sertifika yaşam döngüsü, uygulama güvenliği ve denetim kapsamı birlikte değerlendirilir.

İlgili gereksinimler için WooCommerce ve PCI DSS başlangıç rehberini inceleyin; ikili sertifika ayarını genel uyumluluk çalışmasının yalnız bir parçası olarak ele alın.

Yenileme ve Yeniden Yükleme Kontrolleri

İki ayrı sertifika kaydının yenilemesini, SAN kapsamını ve dağıtımını izleyin. Yenilemeden sonra Nginx için nginx -t, Apache için apachectl configtest çalıştırıp desteklenen servis yöntemiyle yeniden yükleyin. Mevcut bağlantılar hemen yeni sertifikayla el sıkışmaz; yeni bağlantılarda iki sertifika yolunu da tekrar test edin. Reload başarısını varsaymayın, kaydını kontrol edin.

Her iki sertifikanın son kullanma tarihi, yenileme hataları ve TLS bağlantı sonuçları izlenmelidir. Stapling yalnız ilgili CA’da sağlık kontrolüne dahil edilir. Yeni istemci veya kütüphane sürümleri geldiğinde temsilî testleri tekrarlayın.

Dağıtım Kontrol Listesi

RSA ve ECDSA’yı birlikte sunmak bir uyumluluk seçeneğidir. Gerçek sonuç; istemci ve sunucu yetenekleri, sertifika zinciri, güven deposu ve politika ayarlarına bağlıdır. Her iki yolu ayrıca doğrulayıp performansı ölçün.

Dağıtım öncesinde iki doğru anahtar/sertifika çiftini, eşleşen SAN’ları ve geçerli zincirleri hazırlayın. Sözdizimi ve istemci kontrollerinden sonra kademeli yükleyin. OCSP yalnız destekleyen CA’da uygulanır; HSTS ve HTTP/2 kararlarını ayrı test edin.

Yenileme ve geri dönüş prosedürlerini kayıt altında tutun. Web TLS dışında e-posta taşımacılığı için SMTP TLS güvenliği rehberindeki ayrı protokol ve doğrulama koşullarını inceleyebilirsiniz.