Adres çubuğundaki asma kilit basit görünür ama arkasında bir TLS handshake, bir kimlik doğrulama ve uçtan uca bir güven zinciri çalışır. Bu sayfada TLS'in neyi nasıl güvence altına aldığından sertifika türlerine, güven zincirinden ACME ile otomatik yenilemeye ve sunucu sertleştirmeye kadar — bağlantınızın altındaki şifreleme katmanını birlikte sadeleştirelim.
TLS (Transport Layer Security), HTTP başta olmak üzere uygulama trafiğini saran şifreleme katmanıdır; tarayıcının gösterdiği https:// bu katmanın çalıştığı anlamına gelir. "SSL sertifikası" dediğimiz şey de aslında TLS sertifikasıdır — isim, protokolün eski adı olan SSL'den kalmıştır. SSL'in tüm sürümleri ve TLS 1.0/1.1 bugün güvensiz kabul edilir; modern bir sunucu yalnızca TLS 1.2 ve TLS 1.3 konuşur.
Handshake sırasında üretilen oturum anahtarıyla trafik simetrik olarak şifrelenir. Aradaki ağ — Wi-Fi, ISP, proxy — yalnızca anlamsız şifreli baytları görür; içerik aktarımda okunamaz.
Sertifika, karşı uçtaki sunucunun gerçekten o alan adının sahibi olduğunu kanıtlar. Şifreleme tek başına yetmez; doğrulama olmadan ortadaki adam (MITM) saldırganıyla şifreli ama yanlış bir konuşma kurabilirsiniz.
AEAD şifreleme, aktarılan her kaydın değiştirilmediğini doğrular. Saldırgan baytları sessizce değiştiremez; oynanan bir paket doğrulamadan geçemez ve bağlantı kesilir.
# istemci → sunucu
ClientHello desteklenen sürümler, cipher'lar, anahtar payı
key_share + supported_versions: TLS 1.3
# sunucu → istemci (tek turda)
ServerHello key_share — ortak anahtar burada belirlenir
{Certificate} sunucu sertifikası + ara sertifikalar
{CertificateVerify} özel anahtarla imza — kimlik kanıtı
{Finished}
# istemci doğrular ve tamamlar
{Finished} ↓
Application Data # şifreli HTTP trafiği akmaya başlarBütün sertifikalar aynı şifrelemeyi sağlar — DV de EV de bağlantınızı aynı güçte korur. Aralarındaki fark şifrelemede değil, kimliğin ne kadar doğrulandığındadır. İkinci eksen ise kapsamdır: sertifikanın kaç alan adını ve alt alanı kapsadığı.
Yalnızca alan adına hâkim olduğunuz doğrulanır (DNS kaydı ya da HTTP dosyası ile). Dakikalar içinde, otomatik ve çoğunlukla ücretsiz alınır. Web sitelerinin büyük çoğunluğu için doğru seçimdir; Let's Encrypt bunu sunar.
Alan adına ek olarak kuruluşun varlığı (ticaret sicili, adres) CA tarafından doğrulanır. Sertifika ayrıntılarında şirket adı görünür. Kurumsal portallar ve B2B sistemleri için tercih edilir; günler sürebilir.
En kapsamlı kimlik incelemesi; CA/Browser Forum'un sıkı kurallarına tabidir. Eskiden adres çubuğunda yeşil şirket adı gösterirdi — tarayıcılar bu görsel ayrıcalığı kaldırdı. Bugün ayrımı yalnızca sertifika ayrıntılarında görürsünüz.
*.sirketadi.com tek bir sertifikada tüm birinci seviye alt alanları (api., app., blog.) kapsar. İç içe alt alanları (a.b.sirketadi.com) kapsamaz. Özel anahtarın tek noktada toplanması bir merkezî risktir.
Subject Alternative Name alanı, tek sertifikada birbirinden bağımsız alan adlarını listeler (sirketadi.com, sirketadi.net, urun.com). Modern sertifikalarda alan adı yalnızca burada geçerlidir; eski Common Name (CN) alanı artık doğrulamada dikkate alınmaz.
Tarayıcınız sunucunuzun sertifikasına doğrudan güvenmez — onu bir zincirle, işletim sistemine ya da tarayıcıya önceden gömülü bir kök sertifikaya kadar takip eder. Her halka bir üstündeki anahtarla imzalanmıştır; zincir kök depodaki güvenilir bir sertifikada sonlanırsa bağlantı doğrulanır.
En sık yaşanan TLS hatası "geçersiz sertifika" değil, eksik ara sertifikadır: sunucu yalnızca kendi uç sertifikasını sunar, ara sertifikayı eklemeyi unutur. Bazı tarayıcılar bunu telafi eder, bazıları etmez — bu yüzden "bende çalışıyor" yanıltıcıdır.
# sunucunun sunduğu sertifika zinciri
Certificate chain
0 s:CN = sirketadi.com # uç (leaf) — sizin sertifikanız
i:C = US, O = Let's Encrypt, CN = R11
1 s:C = US, O = Let's Encrypt, CN = R11 # ara (intermediate)
i:C = US, O = ISRG, CN = ISRG Root X1
2 s:C = US, O = ISRG, CN = ISRG Root X1 # kök (root) — depoda gömülü
i:C = US, O = ISRG, CN = ISRG Root X1
# doğrulama sonucu
Verify return code: 0 (ok)
↑ zincir köke kadar tamamlandı, güven kurulduSertifikalar bilinçli olarak kısa ömürlüdür: süresi dolan bir sertifika, çalınmış bir anahtarın sonsuza dek kullanılmasını engeller. Ama bu, yenilemeyi unutmanın bedelinin de ağır olduğu anlamına gelir — süresi dolmuş tek bir sertifika tüm siteyi erişilemez kılar. Çözüm disiplin değil, otomasyondur.
Sunucu anahtar çifti üretir, bir CSR ile CA'ya başvurur. CA, alan adı sahipliğini ACME challenge (HTTP-01 ya da DNS-01) ile doğrular.
saniyelerSertifika sunucuda kuruludur ve geçerlilik penceresinde (notBefore–notAfter) trafiği şifreler. Let's Encrypt'te bu pencere 90 gündür.
~90 günSüre dolmadan önce (genelde son 1/3'te) istemci sertifikayı otomatik yeniler ve sessizce devreye alır. Manuel müdahale gerekmez.
~30 gün önceYenilenmezse notAfter geçtiğinde tarayıcı bağlantıyı reddeder. Anahtar sızarsa süre dolmadan da CRL/OCSP ile iptal edilir.
Azami geçerlilik süresi yıllar içinde kısalıyor: CA/Browser Forum kararıyla üst sınır 398 günden kademeli olarak düşürülüyor ve 2029'a doğru 47 güne inmesi planlanıyor. Bu eğilim, otomatik yenilemeyi bir kolaylık olmaktan çıkarıp zorunluluk hâline getiriyor — manuel yenilemeyle artık sürdürülebilir değil.
Certbot, acme.sh ya da Caddy'nin yerleşik ACME desteği yenilemeyi zamanlanmış görevle yürütür. Kurulumdan sonra "unutun" — ama sessizce başarısız olmaması için yenileme sonrası servis yeniden yükleme kancasını (deploy-hook) bağlayın.
Otomasyon kurulu olsa bile bağımsız bir kontrol kalkanınız olsun: notAfter tarihini dışarıdan izleyen bir uyarı (ör. 21/14/7 gün kala) sessiz yenileme hatalarını siz değil, sistem yakalar.
Wildcard sertifikalar yalnızca DNS-01 challenge ile alınır. DNS sağlayıcınızın API'siyle TXT kaydını otomatik koyup kaldıran bir eklenti kullanın; el ile DNS düzenlemek otomasyonu kırar. DNS kayıt türleri için Domain & DNS.
Bir sertifikanın özel anahtarı çalınırsa süresinin dolmasını beklemek seçenek değildir; sertifikanın vaktinden önce geçersiz kılınması gerekir. Asıl zor soru şudur: tarayıcı, elindeki sertifikanın iptal edildiğini nasıl öğrenir? Bu sorunun yıllar içinde değişen birkaç yanıtı vardır ve her birinin kendi gizlilik, hız ve güvenilirlik ödünleşmesi bulunur.
CA'nın yayımladığı, iptal edilmiş sertifika seri numaralarının toplu listesi. Tarayıcı bu listeyi indirip kontrol eder. En eski yöntemdir; liste zamanla büyür, indirilmesi pahalıdır ve tazeliği gecikir — bir iptal, bir sonraki liste yayımlanana dek görünmez kalabilir.
Tek bir sertifikanın durumunu CA'nın OCSP sunucusundan canlı sorgular: "bu seri numarası hâlâ geçerli mi?". CRL'den hafiftir, ama her ziyarette CA'ya yapılan bu sorgu hem gecikme ekler hem de bir gizlilik sızıntısıdır — CA, kullanıcının hangi siteyi ziyaret ettiğini görebilir.
Sunucu, OCSP yanıtını kendisi periyodik olarak alır ve CA imzalı bu taze durumu handshake'e ekler ("staple" eder). Tarayıcı CA'ya ayrı bir sorgu atmaz; gizlilik korunur, gecikme ortadan kalkar, CA yükü azalır. Bugün önerilen yol budur. Sunucu yapılandırması için Sertleştirme.
Sertifikaya işlenen bir bayrak, tarayıcıya "bu sertifika her zaman staple edilmiş gelmeli; gelmezse bağlantıyı reddet" der. Stapling'in soft-fail boşluğunu kapatır, ama yanlış yapılandırmada (staple üretilemediğinde) siteyi erişilemez kılma riski taşır; dikkatli kurulum ister.
# sunucu OCSP yanıtını handshake'e ekliyor mu?
OCSP response:
======================================
OCSP Response Status: successful (0x0)
Cert Status: good # iptal edilmemiş
This Update: May 31 10:00 2026 GMT
Next Update: Jun 7 10:00 2026 GMT # taze, CA imzalı
# yanıt boş gelseydi:
OCSP response: no response sent # stapling kapalı ya da çalışmıyorGeçerli bir sertifika işin yarısıdır; diğer yarısı sunucunun nasıl yapılandırıldığıdır. Doğru sertifika eski bir protokol sürümüyle ya da zayıf bir cipher'la sunulursa güvenlik aşağı çekilir. Aşağıdaki ayarlar, bir bağlantının güçlü başlamasını ve güçlü kalmasını sağlayan temel sertleştirme katmanını oluşturur.
# yalnızca modern protokol sürümleri
ssl_protocols TLSv1.2 TLSv1.3;
# TLS 1.3'te cipher'lar sabit; 1.2 için güçlü liste
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:...;
# OCSP stapling — iptal durumunu sunucu taşır
ssl_stapling on;
ssl_stapling_verify on;
# HSTS — tarayıcıyı HTTPS'e kilitle
add_header Strict-Transport-Security
"max-age=63072000; includeSubDomains; preload";Strict-Transport-Security başlığı, tarayıcıya "bu siteye yalnızca HTTPS ile bağlan" der ve düşürme saldırılarını kapatır. preload ile ilk istekten önce de korunur — ama geri almak zordur, önce kısa max-age ile sınayın. CSP ve diğer güvenli başlıklar için Web Uygulama Güvenliği.
SSL protokolün eski adıdır ve tüm sürümleri güvensizdir; bugün hiçbir yerde kullanılmamalıdır. TLS onun halefidir (1.2 ve 1.3 güncel sürümler). "SSL sertifikası" yerleşmiş bir tabirdir ama teknik olarak yanlıştır — sertifikalar TLS ile kullanılır.
Şifreleme trafiğin okunamamasını sağlar; "kimse dinleyemesin". Kimlik doğrulama ise karşı ucun doğru taraf olduğunu kanıtlar; "doğru sunucuyla konuşayım". Self-signed bir sertifika şifreler ama kimliği doğrulatmaz — bu yüzden tarayıcı uyarı verir.
DV yalnızca alan adı sahipliğini, EV ek olarak kuruluş kimliğini doğrular. İkisi de aynı şifrelemeyi sağlar; fark yalnızca kimlik güvencesindedir. Tarayıcılar EV'nin görsel ayrıcalığını (yeşil çubuk) kaldırdığı için bugün çoğu site için DV yeterlidir.
Süre dolması sertifikanın notAfter tarihini geçmesidir — planlı ve takvime bağlıdır. İptal ise anahtar çalınması gibi durumlarda süre dolmadan CA'nın sertifikayı geçersiz kılmasıdır (CRL / OCSP). Biri zamanla, diğeri olayla tetiklenir.
Self-signed sertifika kendini imzalar; güven zinciri yoktur, tarayıcı güvenmez. Yerel geliştirme ve iç servisler için uygundur. CA imzalı sertifika ise güvenilir bir köke kadar uzanan zincire sahiptir; halka açık tüm siteler bunu gerektirir.
HTTPS bağlantının TLS ile şifrelendiği durumdur. HSTS ise tarayıcıya "bu siteye bundan sonra yalnızca HTTPS ile bağlan" diyen bir politikadır. HTTPS'i açmak ilk adım; HSTS, HTTP'ye düşmeyi (downgrade) kapatan ikinci kilittir.
TLS protokolü, ACME otomasyonu, sertifika kuralları ve sunucu yapılandırması için resmi kaynaklar.
Protokol sürümlerinizi, cipher yapılandırmanızı, zincir bütünlüğünüzü ve otomatik yenileme akışınızı gözden geçirelim — bağlantınızın altındaki güven katmanını birlikte sağlamlaştıralım.