TLS (Transport Layer Security) sertifikası, bir alan adı veya hizmet kimliğini açık anahtarla ilişkilendiren dijital kimlik belgesidir. Yaygın “SSL sertifikası” sözü, SSL (Secure Sockets Layer) protokolünden kalan tarihsel bir adlandırmadır; modern bağlantılarda kullanılan protokol TLS'dir. SSL ile TLS 1.0 ve TLS 1.1 güncel güvenli dağıtım için kullanılmamalıdır.

Web'de kullanılan sertifikalar genellikle açık anahtarlı sertifika yapısını tanımlayan X.509 biçimindedir. İstemci sertifikadaki kimliği, geçerlilik aralığını, kullanım kısıtlarını, dijital imzaları ve güven zincirini denetler. Sunucu da sertifikadaki açık anahtara karşılık gelen özel anahtara sahip olduğunu TLS el sıkışmasında kanıtlar. El sıkışması sırasında türetilen simetrik anahtarlar trafiği korur; sertifika ve özel anahtar kanıtı ise bağlantının beklenen hizmetle kurulduğunu doğrulamaya yarar.

TLS sertifikası tek başına siteyi güvenilir, zararsız veya hatasız yapmaz. Sağladığı temel kanıt, istemcinin beklediği hizmet kimliği ile bir açık anahtar arasındaki doğrulanabilir bağdır.

TLS Sertifikası Ne İşe Yarar?

TLS güvenli kanalında üç temel özellik hedeflenir. Kimlik doğrulama, istemcinin beklenen sunucu kimliğini denetlemesine yardım eder. Gizlilik, bağlantı dışındaki tarafların taşınan içeriği okumasını engellemeyi amaçlar. Bütünlük ise verinin aktarım sırasında fark edilmeden değiştirilmesini önlemeyi amaçlar.

Sertifika bu yapının kimlik doğrulama parçasında kullanılır. Sertifika yetkilisinin dijital imzası sertifika içeriğinin değiştirilip değiştirilmediğinin ve belirtilen kimlik-açık anahtar bağının doğrulanabilmesini sağlar. Sunucunun özel anahtara sahip olduğunu kanıtlaması, yalnız kopyalanmış bir sertifika dosyasının kimliğe bürünmek için yeterli olmasını engeller.

Modern TLS bağlantısında sertifikanın açık anahtarı bütün web trafiğini doğrudan şifrelemez. El sıkışmasında taraflar ortak anahtar malzemesi oluşturur ve sunucu kimliği doğrulanır; uygulama verisi daha sonra bağlantıya özel simetrik trafik anahtarlarıyla korunur.

Sertifikada Hangi Bilgiler Bulunur?

Bir X.509 sertifikasında sürüm, seri numarası, sertifikayı veren kuruluş, geçerlilik başlangıç-bitiş zamanı, açık anahtar, imza algoritması ve çeşitli uzantılar bulunur. Temel kısıtlar bir sertifikanın başka sertifikalar verebilen bir sertifika yetkilisine ait olup olmadığını; anahtar kullanımı ve genişletilmiş anahtar kullanımı alanları da anahtarın hangi işlemler için kabul edilebileceğini sınırlar.

Web hizmetinde kapsanan DNS adları, SAN (Subject Alternative Name) uzantısındaki dNSName girdileriyle gösterilir. İstemci adres çubuğunda veya bağlantı ayarında beklediği adı bu girdilerle karşılaştırır. Yalnız sertifikanın “konu” alanındaki eski CN (Common Name) bilgisine güvenmek güncel kimlik eşleştirme yöntemi değildir.

Alan adı başka bir IP adresine taşınsa da sertifika geçerli kalabilir; çünkü DNS adı doğrulaması IP adresinden ayrıdır. Doğrudan bir IP adresiyle bağlantı kurulacaksa sertifikada uygun iPAddress SAN girdisi bulunmalıdır. DNS adı için verilmiş sertifika IP adresini otomatik olarak kapsamaz.

Alan Adı Eşleşmesi ve Wildcard Kuralı Nasıl Çalışır?

İstemci, beklediği DNS adındaki bütün etiketleri sertifikadaki adla karşılaştırır. ASCII, temel Latin harflerini, rakamları ve çeşitli işaretleri kodlayan karakter kümesidir. Uluslararasılaştırılmış alan adlarında ASCII karakter kümesinin dışında karakter içeren etiketler, uygulamalar için uluslararasılaştırılmış alan adları (IDNA) kurallarına göre A-label biçimine çevrilir. Geçerli bir A-label her zaman xn-- ile başlar ve yalnız ASCII karakterlerini kullanır; alan adının zaten ASCII biçimindeki diğer etiketleri aynı kalabilir. Büyük-küçük harf farkı DNS adı karşılaştırmasını değiştirmez.

Wildcard sertifikası, yıldız karakterini yalnız en soldaki etiketin tamamı olarak kullanabilir. *.ornek.com kimliği www.ornek.com ve api.ornek.com gibi tek etiketli alt alanları kapsayabilir; ornek.com ana alanını veya a.b.ornek.com gibi daha derin bir adı kapsamaz. Ana alan gerekiyorsa SAN listesine ayrıca eklenmelidir.

Tek sertifikada birden fazla SAN girdisi bulunabilir. Böyle bir çok adlı sertifika farklı alanları ve alt alanları kapsayabilir; ancak sertifikayı gören taraf bütün SAN listesini de görebilir. Aynı özel anahtar birden fazla sistemde kullanılıyorsa bu sistemlerden birinde ele geçirilmesi, sertifikanın kapsadığı bütün adlar için risk oluşturur.

Açık Anahtar, Özel Anahtar ve Dijital İmza Nasıl Ayrılır?

Sertifikanın içinde açık anahtar bulunur ve istemciye gönderilir. Karşılık gelen özel anahtar sunucuda veya güvenli anahtar hizmetinde tutulur; sertifika zinciriyle birlikte istemciye gönderilmez. Özel anahtarı ele geçiren kişi, sertifika geçerli olduğu sürece ilgili sunucu kimliğine bürünmeye çalışabilir.

Sertifika yetkilisi sertifikanın imzalanan bölümünü kendi özel anahtarıyla imzalar. İstemci bir üst sertifikanın açık anahtarıyla bu imzayı doğrular. TLS 1.3'te sunucu ayrıca el sıkışma dökümünü kendi özel anahtarıyla imzalayan CertificateVerify mesajını göndererek sertifikadaki açık anahtara karşılık gelen anahtarı elinde tuttuğunu kanıtlar.

Özel anahtar dosyası yedeklenirken ve dağıtılırken erişim sınırlandırılmalı, uygulamanın desteklediği güvenli anahtar deposu kullanılmalı ve anahtarın günlük ya da hata çıktısına yazılması engellenmelidir. Açığa çıkma şüphesinde yalnız sertifikayı yenilemek yetmez; yeni anahtar üretilmeli, eski sertifika iptal sürecine alınmalı ve bütün uçlar güncellenmelidir.

Güven Zinciri Nasıl Doğrulanır?

Sunucu sertifikası çoğunlukla bir ara sertifika yetkilisi tarafından imzalanır. Ara sertifika da başka bir ara sertifika veya kök sertifika yetkilisine bağlanır. İstemci her imzayı, geçerlilik zamanını, temel kısıtları, kullanım amacını ve algoritma politikasını denetleyerek güven deposundaki bir kök sertifikaya kadar doğrulama yolu kurar.

Kök sertifikanın kendinden imzalı olması onu kendiliğinden güvenilir yapmaz. Güven, kökün işletim sistemi, tarayıcı veya uygulama tarafından güven deposuna alınmasından gelir. Özel bir kurum kökü yalnız o kökü açıkça güvenilir sayan cihazlarda kabul edilir.

Sunucu genellikle kendi sertifikasını ve gerekli ara sertifikaları yollar; güvenilir kök istemcinin deposundan gelir. Eksik, yanlış sıralanmış veya uyumsuz ara sertifika bazı istemcilerin doğrulama yolu kuramamasına neden olabilir. CRL (Certificate Revocation List) ve OCSP (Online Certificate Status Protocol) gibi yöntemler iptal bilgisi taşır; istemcilerin hata ve erişilememe davranışı politikalarına göre değişebilir.

TLS 1.3 El Sıkışması Nasıl İlerler?

Sertifikayla sunucu kimliği doğrulanan, istemci sertifikası istenmeyen tam bir TLS 1.3 el sıkışmasının temel adımları şöyledir:

  1. İstemci ClientHello mesajıyla desteklediği sürümleri, kriptografik seçenekleri, anahtar paylaşımını ve gerekiyorsa hedef sunucu adını gönderir.
  2. Sunucu ServerHello mesajıyla ortak sürüm ve seçenekleri belirler; anahtar paylaşımı üzerinden ortak el sıkışma sırları türetilir.
  3. Sunucu, şifreli el sıkışma mesajları içinde kendi sertifikasını ve gerekli ara sertifikaları gönderir; CertificateVerify mesajıyla özel anahtara sahip olduğunu kanıtlar ve Finished mesajını iletir.
  4. İstemci alan adı eşleşmesini, zaman aralığını, kullanım amaçlarını, sertifika zincirini ve CertificateVerify imzasını denetler; sunucunun Finished mesajını doğrular.
  5. İstemci kendi Finished mesajını gönderir; sunucu da bu mesajı doğrular. Finished mesajları el sıkışma dökümünün bütünlüğünü ve tarafların ortak anahtar malzemesine sahip olduğunu denetler.
  6. Taraflar, el sıkışma anahtarlarından ayrı türettikleri simetrik trafik anahtarlarıyla uygulama verisini korur. Sunucu, kendi Finished mesajından sonra ve istemcininkini beklemeden de uygulama verisi gönderebilir.

TLS 1.3'te ServerHello sonrasındaki el sıkışma mesajlarının çoğu el sıkışma anahtarlarıyla korunur. Geçici anahtar değişimi geçmiş oturum anahtarlarının sonradan sunucu özel anahtarı ele geçirilse bile doğrudan çıkarılamamasına yardım eden ileri gizlilik sağlar. Oturum devam ettirme ve erken veri gibi seçeneklerin ayrı güvenlik koşulları vardır.

Güncel dağıtımda TLS 1.2 ve TLS 1.3 desteği denetlenir; iki taraf da destekliyorsa TLS 1.3 tercih edilir. TLS 1.0 ile TLS 1.1 devre dışı bırakılmalıdır. Yalnız sürüm numarası yeterli değildir; kullanılan algoritmalar, anahtar boyutları ve kitaplık güncellemeleri de denetlenmelidir.

Sertifika Türleri Hangi Açıdan Farklıdır?

SınıflandırmaKapsam veya doğrulamaÖnemli sınır
Tek adlı sertifikaBelirli bir DNS adı veya kimlikListede olmayan başka adları kapsamaz
Çok adlı sertifikaBirden fazla SAN girdisiBütün adlar sertifikada görünür; özel anahtar ele geçirilirse hepsi etkilenebilir
Wildcard sertifikasıEn soldaki tek etikette yıldızAna alanı ve birden fazla alt düzeyi otomatik kapsamaz
DV (Domain Validation) sertifikasıAlan üzerindeki denetim doğrulanırKuruluşun ticari güvenilirliğini kanıtlamaz
OV (Organization Validation) sertifikasıAlan denetimine ek kuruluş bilgisi incelenirTrafik şifrelemesi sırf doğrulama türü nedeniyle daha güçlü olmaz

EV (Extended Validation) sertifikalarında sertifika yetkilisi ek kuruluş kimliği kontrolleri yapar; tarayıcının kullanıcı arayüzü ve gösterdiği bilgiler ürüne göre değişebilir. Alan, kuruluş veya genişletilmiş doğrulama sınıfı bir web uygulamasının güvenlik açığı içermediğini garanti etmez. Doğrulama kapsamı ile TLS protokolünün şifreleme gücü ayrı kavramlardır.

Sertifika Nasıl Alınır ve Yenilenir?

Önce güvenli bir anahtar çifti üretilir. CSR (Certificate Signing Request), açık anahtarı ve istenen kimlikleri taşır; özel anahtar isteğe eklenmez. Sertifika yetkilisi alan denetimini ve seçilen türe göre ek kimlik bilgilerini doğruladıktan sonra sertifikayı imzalar.

ACME (Automated Certificate Management Environment), hesap oluşturma, sipariş, yetkilendirme, alan denetimi, sertifika istemi ve indirme adımlarını otomatikleştiren protokoldür. Sertifika yetkilisinin desteklediği yönteme göre HTTP üzerinden doğrulama dosyası sunulur, DNS'e geçici TXT kaydı eklenir veya TLS tabanlı doğrulama yapılır. Wildcard için yöntem ayrıca kontrol edilmelidir; örneğin Let's Encrypt yalnız DNS-01 doğrulamasını kabul eder, HTTP-01 ve TLS-ALPN-01 wildcard kapsamını doğrulamaz.

Geçerlilik süresi sabit bir evrensel değer değildir; sertifika politikası ve istemci ekosistemi zamanla değişebilir. Yenileme son güne bırakılmamalı, otomatik süreç düzenli sınanmalı ve hata uyarıları izlenmelidir. Yeni sertifika bütün web sunucularına, yük dengeleyicilere ve CDN uçlarına dağıtıldıktan sonra her noktadan sunulan zincir ayrıca doğrulanmalıdır.

SNI ve CDN Kullanımında Sertifika Seçimi

Aynı IP adresinde birden fazla TLS sitesi çalışıyorsa SNI (Server Name Indication), istemcinin hedef adı el sıkışmada bildirmesine ve sunucunun doğru sertifikayı seçmesine yardım eder. Varsayılan sanal sunucu veya eski istemci davranışı yanlış sertifika gösterilmesine neden olabileceği için gerçek alan adlarıyla test yapılmalıdır.

CDN, ters proxy veya yük dengeleyici TLS bağlantısını sonlandırıyorsa ziyaretçi o uç noktanın sertifikasını görür. Uç ile kaynak sunucu arasındaki bağlantı ayrı TLS ayarı ve sertifika doğrulaması gerektirir. Dış bağlantının geçerli olması iç bağlantının da aynı biçimde korunduğunu kanıtlamaz.

HTTPS Yönlendirmesi ve HSTS

HTTP adresleri kalıcı olarak HTTPS adreslerine yönlendirilmeli, fakat yönlendirme etkinleştirilmeden önce HTTPS bütün adlarda çalışmalıdır. HSTS (HTTP Strict Transport Security) tarayıcıya sonraki bağlantılarda yalnız HTTPS kullanmasını bildirir; uzun süre veya alt alan kapsamı geri dönüşü zorlaştırabileceğinden hazırlık yapılmadan açılmamalıdır. HTTPS sayfasındaki güvensiz HTTP kaynakları da karma içerik hatası oluşturabilir.

Sertifika Hataları Nasıl Teşhis Edilir?

  • Ad uyuşmazlığı: Ziyaret edilen DNS adı veya IP adresi sertifikanın uygun SAN girdisinde yoktur.
  • Süre hatası: Sertifikanın süresi dolmuştur, başlangıç zamanı gelmemiştir veya istemci saati ciddi biçimde yanlıştır.
  • Sertifika yetkilisine güvenilmemesi: Zincir güven deposundaki bir köke ulaşmıyordur ya da özel kök istemcide kurulmamıştır.
  • Eksik ara sertifika: Sunucu doğrulama yolu için gereken ara sertifikalardan birini göndermiyordur.
  • Özel anahtar uyuşmazlığı: Sunucudaki özel anahtar yüklenen sertifikanın açık anahtarıyla eşleşmiyordur.
  • Eski uç noktası: Yük dengeleyici veya CDN düğümlerinden biri yenilenmemiş sertifikayı sunuyordur.
  • Protokol sorunu: İstemci ve sunucu ortak güncel TLS sürümü ya da algoritması bulamıyordur.
  • İptal veya politika: Sertifika iptal edilmiş, kullanım amacı uygun değil ya da istemci politikasınca reddedilmiş olabilir.

Testte hedef alan adını, IP adresini, portu, SNI değerini, sunulan sertifika zincirini ve anlık zamanı kaydedin. DNS farklı uçlara yönlendiriyorsa her adresi ayrı sınayın. Bir noktada başarı, bütün düğümlerin doğru sertifikayı verdiğini kanıtlamaz. SSL Sertifika ve Zincir Kontrolü aracı sunulan sertifika ile zinciri incelemeye yardım eder; sonuç bütün uygulama güvenliğinin denetimi değildir.

Geçerli TLS Sertifikası Neyi Garanti Etmez?

Geçerli sertifika, istemcinin güven kurallarına göre hizmet kimliği ile açık anahtar bağının kabul edildiğini gösterir. Sitenin zararlı içerik barındırmadığını, işletmenin dürüst olduğunu, uygulamada güvenlik açığı bulunmadığını veya sunucuda saklanan verinin şifreli olduğunu garanti etmez. Saldırgan da kontrol ettiği alan için geçerli bir sertifika alabilir.

Koruma istemci ile TLS'nin sonlandığı uç nokta arasındadır. Sunucu yöneticisi yazılımı güncel tutmalı, erişim yetkilerini sınırlandırmalı; veri tabanını, parolaları, yedekleri ve kaynak sunucu bağlantılarını ayrıca korumalıdır. TLS, DNS yanıtını da kendiliğinden doğrulamaz. DNSSEC, DNS verisinin kaynağını ve bütünlüğünü doğrular; şifreli DNS taşıması ise ilgili DNS bağlantısını korur.