SSL Labs ile Sunucu SSL Yapılandırması Nasıl Test Edilir?

Sunucunuza geçerli bir SSL sertifikası kurmak, işin yalnızca yarısıdır. Tarayıcının adres çubuğunda kilit simgesi görünüyor diye HTTPS yapılandırmanızın gerçekten güçlü olduğunu düşünmek, en sık yapılan yanılgılardan biridir. Bir sertifika teknik olarak "geçerli" olabilir ama arkasında hâlâ on yıl önce kırılmış TLS 1.0 protokolü açık dursa, sunucu zayıf bir şifreyle bağlantı kabul etse ya da ara sertifika zinciri eksik olsa, bağlantı düşündüğünüz kadar güvenli değildir. İşte bu görünmeyen ayrıntıları tek tek denetleyip size somut bir not veren araç, Qualys SSL Labs'in ünlü "SSL Server Test" hizmetidir. Sektörde bir sunucunun TLS yapılandırmasını değerlendirmenin fiili standardı hâline gelmiştir.

Bu rehberde SSL Labs testinin kaputun altında neye baktığını, rapordaki her bölümün (protokoller, şifre paketleri, anahtar değişimi, sertifika zinciri) ne anlama geldiğini ve en önemlisi notunuzu düşüren tipik hataları tek tek nasıl düzelteceğinizi anlatacağım. Sonunda A+ notunu almak için Nginx ve Apache üzerinde uygulayabileceğiniz somut, kopyalanabilir yapılandırma örnekleri bulacaksınız. SSL'in temel mantığını henüz kavramadıysanız önce SSL sertifikası nedir yazımıza göz atmanız bu rehberi çok daha anlamlı kılacaktır.

SSL Labs Testi Nedir ve Neyi Ölçer?#

SSL Labs testi, dışarıdan sunucunuza gerçek bir TLS bağlantısı kurarak yapılandırmanızın güvenlik kalitesini ölçen, ücretsiz ve tarayıcı tabanlı bir denetim aracıdır. Alan adınızı yazıp testi başlattığınızda, Qualys'in sunucuları tıpkı bir ziyaretçi gibi sizinle onlarca farklı senaryoda el sıkışması dener: hangi protokol sürümlerini kabul ediyorsunuz, hangi şifre paketlerini destekliyorsunuz, sertifika zinciriniz tam mı, bilinen saldırılara (BEAST, POODLE, Heartbleed gibi) karşı savunmasız mısınız. Tüm bu gözlemleri bir araya getirip size A+'tan F'ye kadar uzanan tek bir harf notu verir.

Buradaki önemli nokta, testin sunucu tarafını değerlendirmesidir — sizin sertifikanızın hangi firmadan alındığı ya da ne kadara mal olduğu değil, sunucunun o sertifikayı nasıl sunduğu puanlanır. Bu yüzden ücretsiz bir Let's Encrypt sertifikası ile doğru yapılandırılmış bir sunucu, pahalı bir sertifikaya sahip ama kötü yapılandırılmış bir sunucudan çok daha yüksek not alır. Not, dört ana başlıktaki performansınızın bir bileşkesidir:

Sertifika kategorisi bir çarpan gibi çalışır: sertifikanızda temel bir sorun varsa (süresi dolmuş, alan adı uymuyor, güvenilmeyen otorite) not doğrudan sıfıra iner ve diğer kategoriler hiç önem taşımaz. Diğer üç kategori 0-100 arası puanlanır ve ağırlıklı ortalamaları harf notunuza dönüşür.

Raporun Bölümleri: Neye Bakmalısınız?#

Test tamamlandığında karşınıza uzun ve detaylı bir rapor çıkar. İlk kez bakan biri için yoğun görünebilir ama aslında birkaç kilit bölümü okumayı öğrenince tanılama çok kolaylaşır. Şimdi bölümleri sırayla gezelim.

Summary (Özet). Sayfanın en üstünde harf notunuz ve dört kategorinin yatay çubuk grafiği bulunur. Herhangi bir çubuk kısa kalmışsa zayıf halkanız orasıdır. Notun hemen altında, varsa notu tavan yapan uyarılar kırmızı/turuncu kutucuklarla listelenir — örneğin "This server supports TLS 1.0" ya da "This server does not support Forward Secrecy". Sorun avına buradan başlayın.

Certificate (Sertifika). Sunulan sertifikanın konusu (Subject), kapsadığı alan adları (SAN), geçerlilik tarihleri, anahtar tipi ve boyutu (ör. RSA 2048, EC 256), imza algoritması (SHA-256 olmalı, SHA-1 asla) burada görünür. Alan adı uyuşmazlığı ya da süre gibi sorunlar bu bölümde kırmızıyla işaretlenir; bu tür hataların çözümünü SSL hatalarının çözümü yazımızda ayrıntılı ele aldık.

Certification Paths (Sertifika Zinciri). Sunucunuzun tarayıcıya gönderdiği sertifika zincirini kök otoriteye kadar çizer. Burada "Extra download" veya "Incomplete chain" uyarısı görmeniz, ara sertifikayı doğru kurmadığınızın en net işaretidir.

Configuration (Yapılandırma). Raporun en zengin bölümüdür. Alt başlıklarına tek tek bakalım.

Protocols. Sunucunuzun kabul ettiği tüm TLS/SSL sürümleri "Yes/No" olarak listelenir. Görmek istediğiniz tablo şudur: TLS 1.3 ve TLS 1.2 için "Yes", TLS 1.1, TLS 1.0 ve tüm SSL sürümleri için "No".

Cipher Suites. Her protokol sürümü için sunucunun kabul ettiği şifre paketleri, güçlü olanlar yeşil, zayıf olanlar sarı/kırmızı olacak şekilde listelenir. WEAK etiketli bir paket görürseniz onu kapatmanız gerekir.

Handshake Simulation. Farklı tarayıcı ve işletim sistemlerinin sunucunuzla nasıl el sıkıştığını simüle eder; hangi protokol ve şifreyi seçtiklerini, hangi eski istemcilerin artık bağlanamayacağını gösterir. Uyumluluk ile güvenlik arasındaki dengeyi burada tartarsınız.

Protocol Details. Bilinen saldırılara karşı durumunuzu (BEAST, POODLE, Heartbleed, ROBOT), OCSP Stapling, HSTS, oturum yeniden kullanımı gibi ileri güvenlik özelliklerini özetler. A+ notunun "artı"sı genellikle burada, HSTS ile kazanılır.

Protokoller: Notu Düşüren En Büyük Neden#

Bir sunucunun SSL Labs notunu düşüren en yaygın sebep, artık güvensiz sayılan eski protokolleri hâlâ açık tutmasıdır. SSL Labs, sizi kabul ettiğiniz en zayıf protokole göre cezalandırır. Yani sunucunuz hem TLS 1.3'ü hem de TLS 1.0'ı destekliyorsa, TLS 1.3 desteğiniz sizi kurtarmaz; TLS 1.0'ın varlığı Protocol Support puanınızı tavana vurdurur ve olası notunuzu B ile sınırlar.

İşte kabaca protokol-not ilişkisi:

Çözüm nettir: SSL 2.0, SSL 3.0, TLS 1.0 ve TLS 1.1'i tamamen kapatıp yalnızca TLS 1.2 ve TLS 1.3'ü bırakın. Nginx'te tek satır:

# /etc/nginx/nginx.conf içinde http bloğunda veya site server bloğunda
ssl_protocols TLSv1.2 TLSv1.3;

Apache tarafında karşılığı şudur:

# SSL VirtualHost içinde
SSLProtocol -all +TLSv1.2 +TLSv1.3

Değişikliği yapmadan önce Handshake Simulation bölümüne bir kez daha bakın: TLS 1.0/1.1'i kapatmak Windows XP üzerindeki Internet Explorer gibi çok eski istemcileri dışarıda bırakır. 2026 itibarıyla bu istemcilerin oranı istatistiksel olarak sıfıra yakındır ve PCI-DSS gibi uyum standartları zaten TLS 1.0/1.1'i yasaklar — yani bunları kapatmak bugün doğru karardır. Yapılandırmayı test edip yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx
# Apache için:
sudo apachectl configtest && sudo systemctl reload apache2

Bu tek değişiklik, birçok sunucuyu bir gecede B'den A'ya taşır. TLS sürümleri arasındaki farkları merak ediyorsanız TLS 1.3 nedir yazımız konuyu derinlemesine açıklar.

Şifre Paketleri ve Anahtar Değişimi: Zayıf Halkaları Temizlemek#

Protokolleri düzelttikten sonra sıra, o protokoller içinde sunucunun kabul ettiği şifre paketlerine gelir. SSL Labs, listenizde zayıf bir şifre gördüğünde Cipher Strength puanınızı düşürür ve raporda o paketi WEAK olarak etiketler. Kritik olan, ileri gizlilik (Forward Secrecy) sağlamayan ve modern olmayan şifreleri elemektir.

Kaçınmanız gereken başlıca zayıf öğeler şunlardır:

• RC4 — tamamen kırık, hiçbir bağlamda kullanılmamalı.
• 3DES / DES — SWEET32 saldırısına açık, artık zayıf sayılır.
• CBC modundaki eski şifreler — özellikle TLS 1.0/1.1 ile birleşince sorunlu.
• Export-grade / NULL şifreler — şifreleme yok denecek kadar zayıf ya da hiç yok.
• RSA anahtar değişimi (ECDHE olmayan) — ileri gizlilik sağlamaz.

Görmek istediğiniz şifreler ise yalnızca AEAD aileleridir: AES-GCM ve ChaCha20-Poly1305, hepsi ECDHE anahtar değişimiyle. Nginx'te üretime hazır, güvenli ve modern bir şifre listesi şöyle görünür:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers 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;

Not: TLS 1.3'ün kendi şifreleri (TLS_AES_256_GCM_SHA384 gibi) zaten yalnızca güvenli AEAD'lerden oluşur; onları elle belirtmenize gerek yoktur, ssl_ciphers yalnızca TLS 1.2 tarafını etkiler. Modern OpenSSL sürümlerinde ssl_prefer_server_ciphers off; tercih edilir çünkü istemcinin (özellikle mobil cihazların) kendi donanımına en uygun şifreyi seçmesine izin verir.

Anahtar Değişimi (Key Exchange) puanı ise büyük ölçüde iki şeye bağlıdır: sertifika anahtarınızın boyutu ve ileri gizlilik. RSA anahtarınız en az 2048 bit olmalı (Let's Encrypt varsayılanı zaten budur); 1024 bit anahtarlar çoktan kırık sayılır. Eğer klasik DHE şifreleri de destekliyorsanız, zayıf DH parametreleri (Logjam saldırısı) puanınızı düşürebilir — bunu ECDHE'ye tam geçerek ya da güçlü bir DH grubu tanımlayarak çözersiniz. Şifre paketlerinin bileşenlerini daha derinlemesine anlamak isterseniz cipher suite nedir yazımızı öneririm.

Sertifika Zinciri: Sessiz Not Kırıcı#

SSL Labs raporunda en çok kafa karıştıran uyarılardan biri, sertifikanın kendisi geçerli olduğu hâlde çıkan "Chain issues: Incomplete" ya da "Extra download" notudur. Bu, sertifikanın süresiyle veya alan adıyla ilgili değil, sunucunun tarayıcıya hangi sertifikaları gönderdiğiyle ilgilidir.

Bir sertifika tek başına güvenilir olmaz; kök otoriteye kadar uzanan bir zincir ile doğrulanır: sizin sertifikanız → ara sertifika (intermediate) → kök sertifika. Sunucunun görevi, kendi sertifikasıyla birlikte ara sertifikayı da göndermektir; kök sertifika zaten her tarayıcıda gömülüdür. Sunucu ara sertifikayı göndermezse, masaüstü tarayıcılar eksik halkayı bazen kendi önbelleğinden tamamlar ve site sorunsuz açılır — ama mobil cihazlar, eski işletim sistemleri ve curl gibi araçlar bunu yapamaz. SSL Labs bu eksikliği hemen fark eder ve "Incomplete chain" der.

Zincirin kaç sertifikadan oluştuğunu komut satırından hızlıca kontrol edebilirsiniz:

openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"

Sonuç 1 ise yalnızca kendi sertifikanız gönderiliyor demektir; sağlıklı bir kurulumda genelde en az 2 (kendi sertifikanız + ara sertifika) görmelisiniz. Çözüm, sunucuya kendi sertifikanız yerine fullchain dosyasını göstermektir. Let's Encrypt / Certbot bunu zaten fullchain.pem olarak üretir:

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

Elle kurulum yapıyorsanız kendi sertifikanızı ara sertifikayla doğru sırada birleştirin (önce kendi sertifikanız, sonra ara):

cat alanadiniz.crt intermediate.crt > fullchain.crt

Bir de "Extra download" uyarısı vardır: bu, sunucunun ara sertifikayı göndermeyip yerine bir URL bıraktığı ve tarayıcının onu ayrıca indirmek zorunda kaldığı anlamına gelir — hem yavaşlatır hem de bazı istemcilerde başarısız olur. Çözümü yine aynıdır: ara sertifikayı doğrudan fullchain içinde sunun. Sertifika zincirinin nasıl kurulduğunu sertifika zinciri nedir yazımızda parça parça anlattık.

A+ Notu İçin Önerilen Yapılandırma#

Buraya kadarki adımlar sizi büyük ihtimalle A notuna taşır. Peki o "artı"yı ne kazandırır? A+ notunun neredeyse tek şartı, doğru yapılandırılmış bir HSTS (HTTP Strict Transport Security) başlığıdır. HSTS, tarayıcıya "bu siteye bundan sonra yalnızca HTTPS ile bağlan, HTTP'yi hiç deneme" der ve böylece protokol düşürme (SSL stripping) saldırılarını engeller. SSL Labs, en az altı aylık (max-age=15768000 ve üzeri) geçerli bir HSTS başlığı gördüğünde notu A'dan A+'ya çıkarır.

Nginx'te üretime hazır, A+ hedefli tam bir SSL bloğu şöyle olur:

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

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

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers 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;

    # OCSP Stapling — sertifika iptal kontrolünü hızlandırır
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # HSTS — A+ notunun anahtarı (önce dikkatle test edin!)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Apache karşılığında da aynı ilkeler geçerlidir:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off
SSLUseStapling on
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Kritik uyarı: HSTS'i etkinleştirmeden önce HTTPS'inizin ve tüm alt alan adlarınızın kusursuz çalıştığından kesinlikle emin olun. includeSubDomains eklediğinizde, HTTPS sunmayan tek bir alt alan adı bile erişilemez hâle gelir ve tarayıcı max-age süresi boyunca "devam et" seçeneği bile sunmaz. Bu yüzden HSTS'i her zaman önce kısa bir süreyle (max-age=300) test ederek başlatmak akıllıcadır. HSTS'in detaylarını HSTS nedir yazımızda bulabilirsiniz. OCSP Stapling'in ne işe yaradığını da OCSP Stapling nedir yazımızda ele aldık.

Bu yapılandırmayı Mozilla'nın "SSL Configuration Generator" gibi araçlarından üretilen çıktıyla da karşılaştırabilirsiniz; ürettiğiniz her yapılandırmayı canlıya almadan önce mutlaka nginx -t ile sözdizimi kontrolünden geçirin.

Testi Otomatikleştirmek ve Sürekli İzlemek#

SSL Labs testini tarayıcıdan tek seferlik çalıştırmak güzeldir ama gerçek dünyada asıl sorun, dün A+ olan bir sunucunun bir yapılandırma değişikliği ya da otomatik yenileme hatasıyla sessizce B'ye düşmesidir. Bu tür kaymaları erken yakalamak için testi düzenli olarak, tercihen otomatik çalıştırmak gerekir.

SSL Labs bir de resmi komut satırı aracı sunar (ssllabs-scan). Onu CI/CD hattınıza ya da bir zamanlanmış göreve bağlayarak notunuz belirli bir eşiğin altına düştüğünde uyarı üretebilirsiniz:

# JSON çıktı alıp notu bir betikle kontrol edin
ssllabs-scan --grade alanadiniz.com

Hızlı, dışa bağımlılık olmadan bir kontrol için openssl tek başına da çok iş görür. Örneğin sertifikanın ne zaman dolacağını bir cron göreviyle her gün kontrol edip 15 günden az kaldığında haber verebilirsiniz:

#!/bin/bash
DOMAIN="alanadiniz.com"
END=$(echo | openssl s_client -connect "$DOMAIN":443 -servername "$DOMAIN" 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ( $(date -d "$END" +%s) - $(date +%s) ) / 86400 ))
echo "Sertifika $DAYS gün sonra dolacak."
[ "$DAYS" -lt 15 ] && echo "UYARI: Yenileme zamanı yaklaştı!"

Bunu bir crontab satırıyla günlük çalıştırabilirsiniz:

# her sabah 07:00'de kontrol et
0 7 * * * /usr/local/bin/ssl-kontrol.sh

Sertifika süresinden protokole kadar her şeyi tek bir panoda takip etmek isterseniz, düzenli erişim ve uptime izleme çözümleriyle bunları birleştirmek iyi bir fikirdir. Yönetilen bir hosting paketinde ya da sunucu yönetimi hizmetinde bu denetimlerin çoğu sizin adınıza, otomatik ve sürekli yapılır — böylece A+ notunuz bir kereye mahsus bir başarı değil, kalıcı bir durum olur.

Sıkça Sorulan Sorular#

SSL Labs testinde neden A yerine A+ alamıyorum?#

Çoğu durumda tek eksik, geçerli bir HSTS başlığıdır. Sunucunuz TLS 1.2/1.3 kullanıyor, zayıf şifresi yok ve zinciri tamsa notunuz A'da takılıyor demektir; en az altı aylık max-age değerine sahip bir Strict-Transport-Security başlığı eklediğinizde SSL Labs notu A+'ya çıkarır. Bu başlığı açmadan önce HTTPS'inizin ve tüm alt alan adlarınızın kusursuz çalıştığından emin olun.

Testte "This server supports TLS 1.0" uyarısı görüyorum, ne yapmalıyım?#

Bu uyarı, sunucunuzun hâlâ kırık sayılan eski TLS 1.0 (ve muhtemelen 1.1) protokollerini kabul ettiğini ve bu yüzden notunuzun B ile sınırlandığını söyler. Nginx'te ssl_protocols TLSv1.2 TLSv1.3; satırını ayarlayıp Apache'de SSLProtocol -all +TLSv1.2 +TLSv1.3 yazarak eski sürümleri kapatın, ardından yapılandırmayı test edip yeniden yükleyin. Bu tek değişiklik çoğu sunucuyu anında A'ya taşır.

Sertifikam geçerli olduğu hâlde SSL Labs neden "Chain issues: Incomplete" diyor?#

Sorun sertifikanızda değil, sunucunuzun tarayıcıya ara sertifikayı göndermemesindedir. openssl s_client -showcerts ile kaç sertifika döndüğünü kontrol edin; yalnızca bir tane dönüyorsa zincir eksiktir. Nginx'te ssl_certificate yönergesini kendi sertifikanız yerine fullchain.pem dosyasına yönlendirerek ya da sertifikanızı ara sertifikayla birleştirerek sorunu çözersiniz.

SSL Labs testi sitemi yavaşlatır veya zarar verir mi?#

Hayır. Test tamamen dışarıdan, tıpkı sıradan bir ziyaretçi gibi sunucunuza birkaç bağlantı denemesi yapar; sunucunuzda hiçbir değişiklik yapmaz ve normal trafiğinizin yanında ihmal edilebilir bir yük oluşturur. Tek dikkat edeceğiniz şey, sonuçların herkese açık bir panoda listelenmesidir; bunu istemiyorsanız test ekranındaki "Do not show the results on the boards" seçeneğini işaretleyin.

Sadece Let's Encrypt ücretsiz sertifikayla A+ alabilir miyim?#

Kesinlikle evet. SSL Labs notu sertifikanın fiyatını değil, sunucunun onu nasıl sunduğunu ölçer. Doğru yapılandırılmış (TLS 1.2/1.3, güçlü şifreler, tam zincir, HSTS açık) bir sunucu ücretsiz bir Let's Encrypt sertifikasıyla rahatlıkla A+ alır; pahalı bir sertifika, kötü bir yapılandırmayı asla telafi etmez.

A+ notu aldım ama daha güvenli olmam gerekir mi?#

SSL Labs notu, sunucunuzun TLS taşıma katmanı güvenliğini ölçer; A+ almanız bağlantınızın şifreli ve modern olduğunu gösterir ama uygulama katmanı güvenliğinizi (SQL enjeksiyonu, zayıf parolalar, güncel olmayan yazılım) kapsamaz. Tam bir güvenlik için TLS yapılandırmasını, bir web uygulama güvenlik duvarı, DDoS koruması ve düzenli yedekleme gibi katmanlarla birlikte düşünmelisiniz.

Kapanış#

SSL Labs testi, HTTPS yapılandırmanızın gerçek durumunu size dürüstçe söyleyen bir aynadır: sertifikanızın geçerli olması yetmez, sunucunun o sertifikayı doğru protokoller, güçlü şifreler, tam zincir ve HSTS ile sunması gerekir. İyi haber şu ki A+ notu birkaç satırlık yapılandırmayla ulaşılabilir bir hedeftir — eski protokolleri kapatın, zayıf şifreleri temizleyin, zinciri tamamlayın ve dikkatlice bir HSTS başlığı ekleyin. Ardından testi düzenli çalıştırıp notunuzun sabit kaldığından emin olun.

Bu ayarlarla tek tek uğraşmak istemez, TLS yapılandırmanızın sizin adınıza sürekli A+ seviyesinde tutulmasını tercih ederseniz, otomatik SSL yenilemesi ve güvenli varsayılanlarla gelen Clou.TR hosting paketlerimizi ya da tam denetim isteyenler için sunucu çözümlerimizi ve sunucu yönetimi hizmetimizi inceleyebilirsiniz. Bir sonraki adım olarak sertifikanızın temellerini pekiştirmek için SSL sertifikası nedir ve olası uyarıları gidermek için SSL hatalarının çözümü yazılarımıza göz atmanızı öneririm.