Certificate Transparency (CT) Nedir?

Diyelim ki alan adınız için asla bir sertifika talep etmediniz, ama bir gün birileri sizin adınıza geçerli bir SSL sertifikası çıkardı. Bu sertifikayla kurulan sahte bir site, tarayıcıda yeşil kilit gösterir ve ziyaretçileriniz hiçbir uyarı almadan sahte sayfaya güvenir. Peki bu yetkisiz sertifikadan nasıl haberiniz olacak? Klasik SSL modelinde cevabı acıdır: çoğu zaman hiç haberiniz olmaz. Sertifika Otoriteleri (CA) sertifikaları sessizce çıkarır, hangi CA'nın hangi alan adına ne sertifika verdiğini gösteren merkezi ve herkese açık bir kayıt yoktur.

Certificate Transparency (CT), yani Sertifika Şeffaflığı, tam olarak bu görünmezlik sorununu çözmek için tasarlandı. Temel fikri çarpıcı derecede basittir: bir CA sertifika çıkardığında, bunu herkesin okuyabildiği, değiştirilemez, herkese açık kayıt defterlerine (CT loglarına) yazmak zorundadır. Böylece internetteki her geçerli sertifika kamuya mal olur ve siz de kendi alan adınıza ait sertifikaları izleyerek yetkisiz olanları erken yakalarsınız. Bu rehberde CT'nin neden doğduğunu, nasıl çalıştığını, crt.sh ile alan adınızı nasıl sorgulayacağınızı, izlemeyi nasıl otomatikleştireceğinizi ve CAA kaydıyla birlikte nasıl güçlü bir savunma kuracağınızı bir sistem yöneticisinin gözünden anlatacağım.

Certificate Transparency Neden Ortaya Çıktı?#

CT'nin doğuşunu anlamak için önce SSL'in güven modelindeki kör noktayı görmek gerekir. Tarayıcınız bir sertifikaya, onu imzalayan CA'ya güvendiği için güvenir. Sisteminizde yüzlerce köklü CA vardır ve bunların herhangi biri, teknik olarak, herhangi bir alan adı için sertifika çıkarabilir. Yani bir tek CA hack'lenirse ya da kötü niyetli davranırsa, dünyadaki her alan adı için sahte ama "geçerli" sertifikalar üretilebilir. Sertifikanın mantığını hatırlamak isterseniz SSL sertifikası nedir yazısı iyi bir temel sunar.

Bu teorik risk 2011'de gerçeğe dönüştü. DigiNotar adlı bir Hollanda CA'sı ele geçirildi ve saldırganlar *.google.com dahil yüzlerce alan adı için sahte sertifika çıkardı. Bu sertifikalar İran'da gerçek kullanıcıların Gmail trafiğini dinlemek için kullanıldı. Olayın en ürkütücü yanı, sahte sertifikaların haftalarca fark edilmeden kullanılabilmesiydi; çünkü hiçbir yerde "Google için hangi sertifikalar çıkarıldı?" sorusuna cevap verecek bir kayıt yoktu. DigiNotar sonunda güvenini tamamen kaybetti ve iflas etti, ama zarar çoktan verilmişti.

İşte Google mühendisleri bu olaydan sonra CT'yi ortaya attı. Mantık şuydu: madem kötü niyetli sertifikayı çıkarılmadan engelleyemiyoruz, o zaman en azından çıkarılan her sertifikayı görünür yapalım. Görünürlük, hesap verebilirlik getirir. Bir sertifika herkesin gördüğü bir log'a yazılmak zorundaysa, sahte bir sertifika saatler içinde fark edilebilir ve iptal edilebilir. 2018'e gelindiğinde Chrome, güvenilir sayılmak için sertifikaların CT loglarında yer almasını zorunlu kıldı; bugün Safari ve diğer büyük tarayıcılar da benzer şekilde davranır. Yani CT artık isteğe bağlı bir güzellik değil, SSL ekosisteminin bel kemiğidir.

Certificate Transparency Tam Olarak Nasıl Çalışır?#

CT sistemi üç ana bileşen üzerine kuruludur ve bunların birlikte nasıl çalıştığını anlamak, sistemin gücünü kavramanın anahtarıdır.

• Loglar (Logs): Sertifikaların kaydedildiği, yalnızca ekleme yapılabilen (append-only) herkese açık sunuculardır. Google, Cloudflare, DigiCert, Let's Encrypt gibi kuruluşlar bu logları işletir. Bir kayıt log'a girdikten sonra asla değiştirilemez veya silinemez.
• İzleyiciler (Monitors): Logları sürekli tarayan ve içindeki sertifikaları inceleyen servislerdir. crt.sh gibi araçlar aslında birer izleyicidir; logları toplar, indeksler ve aranabilir hale getirir.
• Denetleyiciler (Auditors): Genellikle tarayıcıların içinde çalışan ve bir log'un dürüst davranıp davranmadığını, yani bir kaydı gizlice geri çekip çekmediğini matematiksel olarak doğrulayan bileşenlerdir.

Logların değiştirilemez olmasını sağlayan mekanizma, Merkle ağacı (Merkle tree) adı verilen bir kriptografik veri yapısıdır. Bu yapıda her yeni sertifika, ağacın bir yaprağı olarak eklenir ve tüm yaprakların özetleri yukarıya doğru birleşerek tek bir kök özet (root hash) oluşturur. Eğer geçmişteki bir kayıt sonradan değiştirilmeye ya da silinmeye çalışılırsa kök özet değişir ve bu tutarsızlık anında tespit edilir. Yani log operatörü bile "şu sertifikayı hiç görmedim" diye yalan söyleyemez; matematik buna izin vermez. Bu tam olarak DNSSEC gibi güven zincirlerinde gördüğümüz "değiştirilemezlik ispatı" mantığının bir başka uygulamasıdır.

Sürecin pratik akışı şöyledir: bir CA sertifika çıkarmadan hemen önce, sertifikanın bir ön sürümünü (precertificate) bir veya birkaç CT log'una gönderir. Log, bu kaydı aldığına dair imzalı bir makbuz döndürür. Sertifika yayınlandıktan sonra izleyiciler bu kaydı görebilir; artık o sertifika kamuya maldır.

SCT Nedir ve Tarayıcı Neyi Kontrol Eder?#

CT'nin işleyişindeki en kritik kavram SCT (Signed Certificate Timestamp), yani İmzalı Sertifika Zaman Damgasıdır. Bir CA, sertifikayı bir log'a gönderdiğinde log ona imzalı bir SCT verir. Bu SCT, "bu sertifikayı şu tarihte kayda aldım ve yayınlamaya söz veriyorum" anlamına gelen kriptografik bir taahhüttür. Tarayıcı bir siteye bağlandığında, sertifikanın yanında en az iki farklı log'dan alınmış geçerli SCT'ler görmek ister; yoksa sertifikayı güvenilir saymaz ve kullanıcıya uyarı gösterir.

SCT, sertifikaya üç farklı yoldan iliştirilebilir. Sizin bir yönetici olarak bunları bilmeniz, özellikle özel sertifika kurulumları yaparken işe yarar.

Uygulamada Let's Encrypt, DigiCert gibi otoritelerin çıkardığı modern sertifikaların neredeyse tamamı SCT'yi doğrudan sertifikaya gömer, yani sizin ekstra bir yapılandırma yapmanıza gerek kalmaz. Bir sertifikanın içindeki gömülü SCT'leri OpenSSL ile şöyle görüntüleyebilirsiniz:

# Canlı bir siteden sertifikayı çekip SCT bölümünü inceleyin
echo | openssl s_client -connect clou.tr:443 -servername clou.tr 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -A 4 "CT Precertificate SCTs"

Çıktıda birden fazla log operatörünün adını ve zaman damgasını görürseniz, sertifikanız CT gereksinimlerini karşılıyor demektir. Bu kontrolü sunucu kurulumlarınızın standart bir parçası haline getirmek, tarayıcı uyarılarıyla karşılaşma riskini ortadan kaldırır.

crt.sh ile Alan Adınızı Sorgulama#

CT'nin size sağladığı en pratik güç, kendi alan adınıza ait tüm sertifikaları tek bir yerden görebilmenizdir. Bunun için en yaygın kullanılan araç, Sectigo'nun işlettiği ücretsiz crt.sh izleyicisidir. crt.sh, dünyadaki CT loglarını toplar ve size basit bir arama arayüzü sunar.

En temel kullanımı tarayıcıdan yapabilirsiniz. crt.sh adresine gidip alan adınızı %.ornek.com biçiminde (yüzde işareti joker karakterdir) yazdığınızda, bu alan adı ve tüm alt alan adları için çıkarılmış her sertifikayı listeler. Ama gerçek gücü, JSON API'sini komut satırından kullandığınızda ortaya çıkar. Bu, sonuçları otomatik işlemenizi sağlar:

# ornek.com ve tüm alt alan adları için tüm sertifikaları JSON olarak çek
curl -s 'https://crt.sh/?q=%25.ornek.com&output=json' | \
  jq -r '.[] | "\(.not_before)  \(.issuer_name)  \(.common_name)"' | \
  sort -u

Bu komut size her satırda sertifikanın çıkarılma tarihini, hangi CA'nın çıkardığını ve hangi alan adını kapsadığını verir. Çıktıyı incelerken kendinize sormanız gereken soru nettir: Bu listedeki her sertifikayı ben mi talep ettim, yoksa tanımadığım bir CA veya beklemediğim bir alt alan adı var mı? Örneğin siz yalnızca Let's Encrypt kullanıyorsanız ve listede bambaşka bir CA'dan vpn.ornek.com için bir sertifika görürseniz, alarm zilleri çalmalıdır.

Yalnızca son birkaç güne ait yeni sertifikaları izlemek için sorguyu tarihe göre filtreleyebilirsiniz. Aşağıdaki örnek, son 7 gün içinde çıkarılmış sertifikaları ayıklar:

# Son 7 günde çıkarılan sertifikaları tespit et
SINCE=$(date -d '7 days ago' +%Y-%m-%d)
curl -s 'https://crt.sh/?q=%25.ornek.com&output=json' | \
  jq -r --arg since "$SINCE" \
    '.[] | select(.not_before >= $since) | "\(.not_before)  \(.common_name)"'

Alt alan adı keşfi açısından da crt.sh son derece değerlidir. Bir alan adının geçmişte çıkarılmış tüm sertifikalarına bakarak, unuttuğunuz eski subdomain'leri veya başkalarının kurduğu servisleri ortaya çıkarabilirsiniz. Bu yüzden CT sorgusu, hem savunma hem de altyapı envanteri için düzenli olarak yapmanız gereken bir alışkanlıktır. Benzer keşif ihtiyaçları için ücretsiz araçlar sayfamızdaki DNS ve alan adı yardımcılarına da göz atabilirsiniz.

CT İzlemeyi Otomatikleştirme#

Elle sorgu atmak farkındalık için iyidir ama gerçek koruma, izlemenin otomatik ve sürekli olmasıyla gelir. Amaç şu: sizin adınıza yeni bir sertifika çıkarıldığı anda haberiniz olsun. İki temel yaklaşım vardır.

Birincisi, hazır izleme servislerini kullanmaktır. Meta'nın açtığı ücretsiz servis ve benzeri araçlar, tanımladığınız alan adları için CT loglarında yeni bir sertifika belirdiğinde size e-posta gönderir. Kurulumu birkaç dakikadır ve teknik yük gerektirmez; küçük ve orta ölçekli çoğu site için fazlasıyla yeterlidir.

İkincisi, kendi izleme betiğinizi kurmaktır. Basit bir yaklaşım, crt.sh sonuçlarını periyodik olarak çekip bilinen sertifika kimliklerini bir yerde saklamak ve listede yeni bir kimlik belirdiğinde uyarı üretmektir. Aşağıda bunu bir cron işi olarak çalıştırabileceğiniz sade bir örnek var:

#!/usr/bin/env bash
# ct-watch.sh — yeni sertifikaları tespit edip uyarır
DOMAIN="ornek.com"
STATE="/var/lib/ct-watch/${DOMAIN}.seen"
mkdir -p "$(dirname "$STATE")"; touch "$STATE"

curl -s "https://crt.sh/?q=%25.${DOMAIN}&output=json" \
  | jq -r '.[].id' | sort -u > /tmp/ct.now

# Daha önce görülmeyen yeni kayıtları bul
comm -13 "$STATE" /tmp/ct.now > /tmp/ct.new

if [ -s /tmp/ct.new ]; then
  echo "UYARI: ${DOMAIN} için $(wc -l < /tmp/ct.new) yeni sertifika bulundu" \
    | mail -s "CT uyarısı: ${DOMAIN}" [email protected]
fi

cp /tmp/ct.now "$STATE"

Bu betiği saatte bir çalıştıran bir cron satırı, size düşük maliyetli ama etkili bir erken uyarı sistemi kurar:

# /etc/crontab — CT izlemeyi her saat başı çalıştır
0 * * * * root /usr/local/bin/ct-watch.sh

Kendi altyapınızı yönetmek yerine bu işleri profesyonel bir ekibe bırakmak isterseniz, sunucu yönetimi hizmetimiz izleme ve uyarı kurulumlarını sizin için yapılandırabilir. Yeni bir sertifika uyarısı geldiğinde ilk yapmanız gereken, o sertifikayı gerçekten sizin mi (veya CDN/hosting sağlayıcınızın mı) talep ettiğini teyit etmektir; çünkü Let's Encrypt otomatik yenilemeleri ya da bir CDN entegrasyonu da meşru şekilde yeni kayıtlar oluşturur.

CAA Kaydı ve CT'yi Birlikte Kullanmak#

CT güçlü bir araçtır ama tek başına önleyici değil, tespit edici bir sistemdir; yani yetkisiz sertifikanın çıkarılmasını engellemez, sadece çıkarıldıktan sonra görünür kılar. Bu boşluğu kapatmak için CT'yi CAA (Certification Authority Authorization) kaydıyla birlikte kullanmak gerekir. CAA, DNS bölgenize eklediğiniz bir kayıttır ve "alan adım için yalnızca şu CA'lar sertifika çıkarabilir" der. Standartlara uyan her CA, sertifika çıkarmadan önce bu kaydı kontrol etmek zorundadır.

İkisinin birlikte oluşturduğu savunma katmanı şöyle işler: CAA kaydı yetkisiz CA'ların sertifika çıkarmasını baştan engeller (önleme), CT ise buna rağmen (örneğin bir CA'nın hatası ya da ihlali sonucu) çıkarılan bir sertifikayı yakalar (tespit). Örnek bir CAA kaydı şöyle görünür:

; Sadece Let's Encrypt ve DigiCert sertifika çıkarabilsin
ornek.com.  IN  CAA  0 issue "letsencrypt.org"
ornek.com.  IN  CAA  0 issue "digicert.com"
; İhlal durumunda buraya bildirim gitsin
ornek.com.  IN  CAA  0 iodef "mailto:[email protected]"

Buradaki iodef etiketi özellikle değerlidir: bir CA, CAA kuralınızı ihlal eden bir talep aldığında bu adrese bildirim göndermeye çalışır. Yani CAA yalnızca engellemez, aynı zamanda bir istihbarat kanalı da açar. CAA kaydının tüm inceliklerini ve söz dizimini ayrı bir yazıda ele alıyoruz, ama pratik kural nettir: CT'yi izleme için, CAA'yı sınırlama için kullanın. İkisi birlikte, hem sertifikanızı hem de alan adınızın itibarını korur. Alan adı ve DNS yönetiminizi tek panelden yapmak isterseniz alan adı hizmetlerimiz CAA dahil tüm kayıt türlerini destekler.

Yetkisiz Sertifika Bulursanız Ne Yapmalısınız?#

CT izlemenizin bir gün gerçekten yetkisiz bir sertifika yakaladığını varsayalım. Panik yapmadan, sırayla ilerlemek önemlidir. İlk adım, sertifikanın gerçekten yetkisiz olduğunu doğrulamaktır: CDN sağlayıcınız, hosting paneliniz veya bir ekip arkadaşınızın kurduğu bir servis olabilir. Meşru bir kaynak bulamazsanız, o sertifikanın kimliğini (crt.sh üzerindeki ID'sini, seri numarasını, çıkaran CA'yı) not alın.

İkinci adım, sertifikayı çıkaran CA ile iletişime geçip iptal (revocation) talep etmektir. CA'lar, kötüye kullanım bildirimleri için ayrı kanallar işletir ve yetkisiz bir sertifikayı iptal etmekle yükümlüdür. Aynı zamanda, ihlalin nasıl gerçekleştiğini (örneğin CA'nın alan adı doğrulamasının atlatılıp atlatılmadığını) sorgulamak, sorunun tekrarını önlemek açısından değerlidir. Bu sırada kendi tarafınızda da DNS ayarlarınızı, e-posta erişimlerinizi ve alan adı kayıt hesabınızın güvenliğini gözden geçirin; çünkü çoğu yetkisiz sertifika, bir alan adı doğrulama zafiyetinden ya da hesap ele geçirmeden kaynaklanır.

Bu tür saldırılara karşı katmanlı bir savunma, sürekli koruma gerektirir. Uygulama katmanındaki saldırıları filtrelemek için bir WAF hizmeti, hacimsel saldırılara karşı DDoS koruması ve düzenli yedekleme altyapısı, sertifika güvenliğini tamamlayan bileşenlerdir. Güvenlik tek bir kaleyle değil, üst üste binen birçok savunma hattıyla sağlanır; CT de bu hatlardan görünürlük sağlayanıdır.

Sıkça Sorulan Sorular#

Certificate Transparency sertifikalarımı daha güvenli mi yapar?#

Doğrudan sertifikanızın kriptografik gücünü artırmaz, ama ekosistemi çok daha güvenli hale getirir. CT'nin sağladığı şey görünürlüktür: sizin adınıza çıkarılan her sertifika kamuya mal olur, böylece yetkisiz veya sahte sertifikalar saatler içinde fark edilip iptal edilebilir. Yani CT, tek bir sertifikayı değil, tüm SSL güven modelini hesap verebilir kılarak korur. Bu görünürlük olmadan, DigiNotar örneğinde olduğu gibi sahte sertifikalar haftalarca sessizce kullanılabilir.

crt.sh'te alan adıma ait tanımadığım bir sertifika gördüm, saldırıya mı uğradım?#

Hemen paniğe kapılmayın; çoğu durumda açıklaması masumdur. Hosting sağlayıcınız, CDN'iniz (örneğin Cloudflare) ya da bir e-posta servisi, sizin adınıza otomatik olarak sertifika çıkarmış olabilir. Let's Encrypt'in otomatik yenilemeleri de sık sık yeni kayıtlar üretir. Önce çıkaran CA'yı ve kapsadığı alan adını inceleyin; kullandığınız servislerle eşleşiyorsa sorun yoktur. Hiçbir meşru kaynakla bağdaştıramadığınız, tanımadığınız bir CA'dan çıkmış bir sertifika görürseniz, o zaman ciddiye alıp CA'dan iptal talep etmelisiniz.

CT loglarındaki bir kaydı sildirebilir miyim?#

Hayır, bu mümkün değildir ve zaten sistemin tüm amacı budur. CT logları yalnızca ekleme yapılabilen (append-only) yapılardır ve Merkle ağacı sayesinde geçmiş kayıtlar değiştirilemez ya da silinemez. Bir sertifika bir kez log'a girdiğinde kalıcı olarak oradadır; bu, log operatörünün bile bir kaydı gizlice geri çekemeyeceği anlamına gelir. Değiştirilemezlik, tespit edilemeyen manipülasyonu imkânsız kıldığı için CT'nin güvenilirliğinin temelidir.

Certificate Transparency ile CAA kaydı arasındaki fark nedir?#

İkisi farklı ama tamamlayıcı işler yapar. CAA, DNS bölgenize eklediğiniz ve "alan adım için yalnızca şu CA'lar sertifika çıkarabilir" diyen önleyici bir kayıttır; yetkisiz bir CA'nın sertifika çıkarmasını baştan engeller. CT ise tespit edicidir: buna rağmen çıkarılmış her sertifikayı herkese açık loglarda görünür kılar. Yani CAA kapıyı kilitler, CT ise kapının açılıp açılmadığını izleyen kameradır. En güçlü koruma ikisini birlikte kullanmakla elde edilir.

CT izlemek için ücret ödemem gerekir mi?#

Hayır, temel CT izleme tamamen ücretsizdir. crt.sh gibi izleyiciler herkese açık ve bedavadır; JSON API'siyle kendi betiklerinizi kurabilir, sıfır maliyetle bir cron işiyle otomatik uyarı sistemi oluşturabilirsiniz. Meta ve çeşitli güvenlik firmalarının sunduğu ücretsiz e-posta uyarı servisleri de vardır. Yalnızca çok sayıda alan adını merkezî bir panelden, ekip özellikleriyle yönetmek isteyen büyük kuruluşlar için ücretli kurumsal izleme çözümleri devreye girer; bireysel ve KOBİ ölçeğinde ücretsiz araçlar fazlasıyla yeterlidir.

Sertifikamda SCT yoksa ne olur?#

Modern tarayıcılar, yeterli sayıda geçerli SCT içermeyen sertifikaları güvenilir saymaz ve ziyaretçilere güvenlik uyarısı gösterir; bu da sitenizin erişilemez görünmesine yol açar. Ancak iyi haber şu ki, Let's Encrypt ve DigiCert gibi CA'ların çıkardığı güncel sertifikaların neredeyse tamamı SCT'yi doğrudan sertifikaya gömer, yani sizin ekstra bir işlem yapmanıza gerek kalmaz. SCT sorununu genellikle yalnızca çok eski sertifikalarda ya da kendi özel CA'nızı işletiyorsanız yaşarsınız. Şüpheye düşerseniz, yazıda gösterdiğimiz OpenSSL komutuyla sertifikanızdaki SCT'leri kontrol edebilirsiniz.

Kapanış#

Certificate Transparency, SSL güven modelinin en büyük kör noktasını, yani "kim benim adıma sertifika çıkardı?" sorusunu, herkese açık ve değiştirilemez loglarla aydınlatır. Tek başına yetkisiz bir sertifikayı engellemez ama onu saatler içinde görünür kılar; CAA kaydıyla birleştiğinde ise hem önleme hem tespit sağlayan güçlü bir savunma hattı oluşturur. crt.sh ile alan adınızı düzenli sorgulamak, basit bir cron betiğiyle yeni sertifikaları izlemek ve CAA ile hangi CA'ların yetkili olduğunu sınırlamak; hepsi ücretsiz ama son derece etkili adımlardır. Bu üçünü rutininize aldığınızda, alan adınızın sertifika güvenliği artık bir kör nokta değil, izlediğiniz bir gösterge tablosu olur.

Alan adı, DNS ve SSL yönetimini tek bir panelden, CAA kaydı desteği ve otomatik sertifika yenilemeleriyle birlikte yürütmek isterseniz alan adı ve hosting hizmetlerimiz bu işi kolaylaştırır. İzleme, WAF ve DDoS koruması dahil uçtan uca güvenliği bizim üstlenmemizi isterseniz sunucu yönetimi ekibimiz kurulumu sizin için yapılandırır; böylece siz işinize odaklanırken sertifika şeffaflığı arka planda sizin için çalışır.