TLSA Kaydı ve DANE ile Sertifika Doğrulama

Bir web sunucusuna ya da e-posta sunucusuna güvenli bağlandığınızda tarayıcınız veya karşı taraftaki mail sunucusu size bir TLS sertifikası sunar. Bu sertifikanın gerçekten o alan adına ait olup olmadığına, geleneksel olarak dünyada birkaç yüz kök sertifika otoritesinin oluşturduğu güven zinciri karar verir. Sorun şu ki bu modelde herhangi bir sertifika otoritesi, teorik olarak sizin izniniz olmadan alan adınız için geçerli bir sertifika üretebilir. Yanlış yapılandırılmış, ele geçirilmiş ya da devlet baskısı altındaki tek bir otorite bile bütün güven zincirini zayıflatabilir. İşte DANE (DNS-based Authentication of Named Entities) tam olarak bu boşluğu kapatmak için tasarlandı ve bunu yaparken TLSA adında özel bir DNS kaydını kullanıyor.

DANE'in temel fikri şaşırtıcı derecede basit. Alan adının sahibi olan siz, "bu alan adına bağlanan biri şu sertifikayı ya da şu sertifika otoritesini görmeli" bilgisini doğrudan kendi DNS bölgenize yazarsınız. Böylece güven kararı, tanımadığınız yüzlerce otoritenin insafına bırakılmak yerine, zaten yönettiğiniz DNS altyapısına taşınır. Ancak bu ancak bir şartla anlamlı olur: DNS cevaplarının kendisinin sahte olmadığından emin olmak gerekir. Bu yüzden DANE, DNSSEC ile ayrılmaz biçimde çalışır. Bu rehberde TLSA kaydının nasıl kurulduğunu, seçici ve eşleşme tiplerini, DNSSEC bağımlılığını ve en çok işe yaradığı e-posta senaryosunu, sahada yıllarca sunucu yöneten birinin diliyle anlatacağım.

DANE Nedir ve Hangi Sorunu Çözer#

Klasik TLS güven modelinde tarayıcınız, sunucudan gelen sertifikanın imza zincirini takip eder ve sonunda işletim sisteminde ya da tarayıcıda gömülü bir kök sertifikaya ulaşırsa bağlantıyı güvenli sayar. Bu sisteme "güven deposu" (trust store) modeli denir ve pratikte gayet iyi çalışır. Ancak yapısal bir zaafı vardır: güven, aşağıdan yukarıya değil, dışarıdan içeriye gelir. Depoda yüzlerce otorite vardır ve bunlardan herhangi biri sizin alan adınız için sertifika kesebilir. Buna "en zayıf halka" problemi denir.

DANE bu denklemi tersine çevirir. "Benim alan adım için hangi sertifikanın geçerli olduğuna ben karar veririm" der. Alan sahibi, geçerli saydığı sertifikanın veya onu imzalayan otoritenin parmak izini DNS'e koyar. İstemci bağlanırken hem sunucudan sertifikayı alır hem de DNS'ten TLSA kaydını çeker; ikisi tutmuyorsa bağlantıyı reddeder. Böylece kötü niyetli bir otoritenin kestiği "geçerli görünen ama sizin onaylamadığınız" bir sertifika, DNS kaydınızla eşleşmediği için ret yer.

Aşağıdaki tablo iki modelin farkını özetliyor.

DANE aslında yeni bir sertifika türü icat etmez. Var olan sertifikalarınızı ister Let's Encrypt'ten ister ticari bir otoriteden alın kullanmaya devam edersiniz; DANE sadece "bunu ben onayladım" damgasını DNS üzerinden ekler. Sertifikanın ne olduğunu ayrıntılı görmek isterseniz SSL sertifikası nedir rehberi iyi bir başlangıç noktasıdır.

TLSA Kaydının Yapısı ve Alanları#

TLSA kaydı, bir DNS bölgesinde özel bir isim altında tutulur. İsim formatı standarttır: _port._protokol.hostname. Örneğin 25 numaralı portta çalışan bir mail sunucusunun kaydı _25._tcp.mail.ornekalan.com altına yazılır. Bu isimlendirme sayesinde aynı hostname için farklı portlara farklı TLSA kayıtları tanımlayabilirsiniz.

Kaydın veri kısmı dört alandan oluşur. Sıralamayla usage (kullanım), selector (seçici), matching type (eşleşme tipi) ve certificate association data (sertifika ilişkilendirme verisi). Tipik bir kayıt şöyle görünür.

_25._tcp.mail.ornekalan.com. 3600 IN TLSA 3 1 1 (
    a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
    e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2 )

Buradaki 3 1 1 sırasıyla usage, selector ve matching type değerleridir; ardından gelen uzun onaltılık dizi ise sertifikanın ya da açık anahtarın hash özetidir. Bu üç sayının her birinin ne anlama geldiğini bir sonraki başlıklarda tek tek açacağım, çünkü DANE'i doğru kurmanın sırrı bu üç alanı bilinçli seçmektir.

Kaydı elle üretmek için OpenSSL yeter. Sunucunuzdaki sertifika dosyasından açık anahtarın SHA-256 özetini almanın klasik yolu şudur.

# Sertifikadaki açık anahtarın SHA-256 özeti (selector 1, matching type 1)
openssl x509 -in /etc/letsencrypt/live/ornekalan.com/cert.pem \
  -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 256

Bu komutun çıktısı, TLSA kaydının son alanına yapıştıracağınız hash'tir. Birçok DNS sağlayıcısı ve ldns-dane gibi araçlar bu üretimi otomatikleştirir, ama komutun ne yaptığını bilmek arıza anında hayat kurtarır.

Usage Alanı Sertifika Kullanım Tipleri#

Usage alanı, TLSA kaydının sertifika zincirinin hangi noktasını sabitlediğini söyler. Dört değer vardır ve bunları karıştırmak DANE kurulumlarındaki en yaygın hatadır.

Pratikte, özellikle e-posta sunucuları için en çok kullanılan değer 3 yani DANE-EE'dir. Bunun nedeni şudur: DANE-EE ile doğrudan sunucunun kendi sertifikasını (uç sertifikayı) sabitlersiniz ve bu sertifikanın herhangi bir kamu otoritesi tarafından imzalanmış olması gerekmez. Yani teoride kendi imzaladığınız (self-signed) bir sertifika bile DANE-EE ile mükemmel biçimde çalışır, çünkü güven artık DNS'ten gelmektedir.

2 yani DANE-TA ise kendi iç sertifika otoritenizi işletiyorsanız işe yarar; bu durumda kök otoritenizi sabitler, altındaki tüm sunucu sertifikaları otomatik güvenilir sayılır. 0 ve 1 ise DANE'i klasik CA modelinin üzerine ek bir kısıt olarak koyar; sertifika hem güven deposunda geçerli olmalı hem de sizin izin verdiğiniz otoriteden gelmelidir. E-posta dünyasında 0 ve 1 neredeyse hiç tercih edilmez çünkü çoğu mail sunucusu zaten katı bir güven deposu doğrulaması yapmaz.

Selector ve Matching Type Alanları#

Selector alanı, sertifikanın hangi bölümünün sabitleneceğini belirler ve iki değeri vardır. 0 tüm sertifikayı, 1 ise sadece sertifikanın içindeki açık anahtar bilgisini (SubjectPublicKeyInfo) ifade eder.

Sahada neredeyse her zaman selector 1 seçilir ve bunun çok pratik bir gerekçesi vardır. Let's Encrypt gibi otoritelerden sertifika yenilerken varsayılan davranış, aynı açık anahtarı koruyarak sadece sertifikayı yeniden imzalamaktır ya da tam tersi. Eğer TLSA kaydınız tüm sertifikaya (selector 0) bağlıysa, her yenileme sonrası kayıt bozulur ve DNS'i güncellemeniz gerekir; unutursanız e-posta trafiğiniz aniden durur. Selector 1 ile sadece açık anahtarı sabitlerseniz, açık anahtarı sabit tuttuğunuz sürece sertifikayı istediğiniz kadar yenileyebilirsiniz ve TLSA kaydına dokunmanız gerekmez.

Matching type alanı ise sabitlenen verinin nasıl saklandığını söyler. Üç değeri vardır.

Yaygın ve önerilen kombinasyon 3 1 1'dir: uç sertifikanın (usage 3) açık anahtarının (selector 1) SHA-256 özetini (matching type 1) sabitler. Bu üçlü hem otorite bağımsızlığı verir hem de sertifika yenilemelerine dayanıklıdır. Yeni bir kuruluma başlıyorsanız aksini gerektiren özel bir sebep olmadıkça 3 1 1 ile başlayın.

Bir de anahtar döndürme (key rollover) inceliği var. Açık anahtarı değiştirecekseniz, geçiş anında eski ve yeni anahtar için iki ayrı TLSA kaydını aynı anda yayınlayın, DNS'in tüm dünyaya yayılmasını bekleyin, sonra sunucuyu yeni anahtara geçirin ve en sonunda eski kaydı silin. Bu sıralamayı atlarsanız yayılma penceresinde bazı gönderen sunucular sizi doğrulayamaz.

; Geçiş döneminde iki kayıt bir arada
_25._tcp.mail.ornekalan.com. 3600 IN TLSA 3 1 1 <ESKI_ANAHTAR_HASH>
_25._tcp.mail.ornekalan.com. 3600 IN TLSA 3 1 1 <YENI_ANAHTAR_HASH>

DNSSEC Neden Zorunlu Bir Ön Koşul#

DANE'in tek ama mutlak bağımlılığı DNSSEC'tir. Mantık gayet açıktır: DANE, güven kararını DNS'e taşır; peki DNS cevabının kendisi yolda değiştirilirse ne olur? İmzasız DNS'te bir saldırgan araya girip sahte bir TLSA kaydı enjekte edebilir ya da kaydı tümden silebilir. Silinen kayıt, doğrulamanın "kayıt yok, klasik moda düş" davranışına dönmesine yol açar ve DANE'in koruması buharlaşır. Bu yüzden DANE, yalnızca DNSSEC ile imzalanmış ve doğrulanan bir bölgede anlam taşır.

DNSSEC, her DNS cevabını kriptografik olarak imzalar ve bu imzaların zinciri kök bölgeye kadar gider. Böylece doğrulayan taraf, aldığı TLSA kaydının gerçekten alan sahibi tarafından yayınlandığından ve yolda değiştirilmediğinden emin olur. DNSSEC'in nasıl çalıştığını ve alan adınızda nasıl etkinleştireceğinizi ayrıntılı görmek için DNSSEC nedir rehberimize göz atın; DANE'e geçmeden önce o adımı sağlam kurmanız şart.

Kurulum sırası da bu nedenle nettir. Önce alan adınızda DNSSEC'i etkinleştirin ve DS kaydının üst bölgeye (registrar) düzgün yayıldığını doğrulayın. Ardından TLSA kayıtlarını ekleyin. Bu sırayı ters çevirirseniz TLSA kaydınız var olur ama imzasız olduğu için hiçbir doğrulayan onu ciddiye almaz. DNSSEC'in gerçekten çalıştığını komut satırından kontrol edebilirsiniz.

# DNSSEC doğrulamasının başarılı olduğunu ve TLSA kaydının imzalı geldiğini gör
dig +dnssec TLSA _25._tcp.mail.ornekalan.com

# Cevapta "ad" (authenticated data) bayrağı olmalı
dig +dnssec +short TLSA _25._tcp.mail.ornekalan.com

Cevabın başlığında ad bayrağını görüyorsanız çözümleyiciniz kaydı DNSSEC ile doğrulamış demektir. Bu bayrak yoksa DANE devreye giremez; önce DNSSEC tarafını düzeltmeniz gerekir. Alan adı ve DNS yönetimini tek elden yürütmek isterseniz alan adı ve sunucu yönetimi hizmetlerimiz bu adımları sizin için sadeleştirir.

E-Posta Sunucularında DANE Kullanımı#

DANE'in bugün en yaygın ve en anlamlı kullanım alanı web değil, sunucular arası e-posta aktarımıdır. Nedeni SMTP'nin tarihsel bir zaafında yatar. Mail sunucuları birbirine bağlanırken TLS'i genelde "fırsatçı" (opportunistic) modda kullanır: şifreleme varsa iyi, yoksa düz metin devam eder ve sertifika doğrulaması çoğu zaman hiç yapılmaz. Bu, aradaki bir saldırganın TLS'i tümden düşürmesine (downgrade) ya da sahte sertifika sunmasına açık kapı bırakır.

DANE, alıcı mail sunucusunun TLSA kaydını DNS'e koymasını ve gönderen sunucunun bu kaydı zorunlu tutmasını sağlayarak bu açığı kapatır. Gönderen tarafta bir kayıt varsa TLS artık isteğe bağlı değildir; sertifika DNS'teki parmak iziyle eşleşmek zorundadır, aksi halde mail teslim edilmez. Postfix gibi yaygın bir MTA'da alıcı tarafı için etkinleştirmek için önce DNSSEC ile imzalı TLSA kaydı yayınlarsınız, gönderen tarafı için de doğrulamayı açarsınız.

# Postfix main.cf – gönderen taraf DANE doğrulamasını açar
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

# Alıcı taraf – 25/tcp için sunucu sertifikasını sunar
smtpd_tls_cert_file = /etc/letsencrypt/live/ornekalan.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/ornekalan.com/privkey.pem
smtpd_tls_security_level = may

Burada smtp_tls_security_level = dane satırı kritiktir; gönderen Postfix, karşı tarafın DNSSEC imzalı bir TLSA kaydı varsa doğrulamayı zorunlu kılar, yoksa fırsatçı TLS'e döner. smtp_dns_support_level = dnssec ise doğrulayan bir çözümleyici kullanmasını garanti eder. Kurulumun doğru çalıştığını test etmek için posttls-finger aracını kullanabilirsiniz.

# Karşı sunucuya DANE ile bağlanmayı test et
posttls-finger -c -l dane smtp:mail.ornekalan.com:25

Çıktıda "Verified TLS connection ... Matched DANE TLSA record" benzeri bir satır görüyorsanız kurulum başarılıdır. Web tarafında DANE'i tarayıcılar yerel olarak desteklemediği için HTTPS'te pratik faydası sınırlıdır; asıl kazanç e-posta altyapısındadır. Kurumsal e-posta altyapınızı bu standartlarla kurmak isterseniz e-posta çözümlerimiz ve güçlü DNS altyapımız iyi bir zemin sunar. Web tarafındaki sertifika ve trafik güvenliği için ise SSL ve WAF hizmetlerimize bakabilirsiniz.

Yaygın Hatalar ve Sorun Giderme#

DANE kurulumlarında en sık karşılaşılan sorun, sertifika yenilendikten sonra TLSA kaydının bozulmasıdır. Bunun kaynağı genellikle selector 0 (tüm sertifika) kullanımıdır. Çözüm, selector 1 ile açık anahtarı sabitlemek ve otomatik yenileme scriptine, anahtar değişirse yeni TLSA kaydını yayınlayıp eskisini gecikmeli silen bir adım eklemektir. Certbot kullanıyorsanız --reuse-key seçeneği açık anahtarı sabit tutarak bu sorunu tümden ortadan kaldırır.

İkinci sık hata, DNSSEC zincirinin eksik olmasıdır. TLSA kaydı doğru ama alan adı ya hiç imzalı değil ya da DS kaydı registrar tarafına yayılmamış. Bu durumda doğrulayan taraf kaydı görmezden gelir ve DANE sessizce devre dışı kalır. Her zaman önce dig +dnssec ile ad bayrağını doğrulayın. Üçüncü klasik hata, kayıt isminde port ya da protokol yanlış yazmaktır; _25._tcp yerine _25._udp yazmak kaydı işlevsiz bırakır.

Sorun giderirken şu hızlı kontrol listesini izleyin.

# 1) DNSSEC çalışıyor mu (ad bayrağı var mı)
dig +dnssec TLSA _25._tcp.mail.ornekalan.com | grep -i "flags"

# 2) TLSA kaydı yayınlanmış mı
dig +short TLSA _25._tcp.mail.ornekalan.com

# 3) Sunucunun sunduğu sertifikanın gerçek hash'i ile karşılaştır
openssl s_client -connect mail.ornekalan.com:25 -starttls smtp 2>/dev/null \
  | openssl x509 -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Üçüncü komutun ürettiği hash ile DNS'teki TLSA kaydının son alanı birebir aynı olmalıdır. İkisi tutmuyorsa ya sunucuda yanlış sertifika sunuluyordur ya da DNS kaydı eski kalmıştır. Bu üç kontrol, DANE arızalarının neredeyse tamamını dakikalar içinde teşhis eder. Altyapınızın yedeklerini düzenli almak da bu tür yapılandırma değişikliklerinde geri dönüş güvencesi verir; yedekleme hizmetimiz bu noktada işinizi kolaylaştırır.

Sıkça Sorulan Sorular#

TLSA kaydı olmadan sunucum güvensiz mi kalır?#

Hayır, TLSA kaydı olmadan da klasik TLS ve sertifika doğrulaması çalışmaya devam eder ve sunucunuz güvenlidir. TLSA yalnızca ek bir güvence katmanıdır; güven kararını sertifika otoritelerinin yanında bir de sizin DNS kaydınıza dayandırır. Özellikle sunucular arası e-posta aktarımında araya girme ve TLS düşürme saldırılarına karşı ekstra koruma sağlar, ama var olan güvenliğinizin ön koşulu değildir.

DANE için mutlaka DNSSEC şart mı?#

Evet, DNSSEC olmadan DANE hiçbir anlam ifade etmez ve doğrulayan taraflarca dikkate alınmaz. DANE'in tüm güven modeli, DNS cevabının sahte olmadığından emin olmaya dayanır ve bunu sağlayan tek mekanizma DNSSEC imzalarıdır. İmzasız bir bölgede yayınlanan TLSA kaydı, bir saldırgan tarafından değiştirilebilir ya da silinebilir olduğundan koruma sağlamaz. Bu nedenle önce DNSSEC etkinleştirilmeli, sonra TLSA eklenmelidir.

Hangi usage, selector ve matching type değerlerini seçmeliyim?#

Çoğu senaryo için önerilen kombinasyon 3 1 1 değerleridir. Bu üçlü, uç sunucu sertifikasının açık anahtarının SHA-256 özetini sabitler ve hem herhangi bir kamu otoritesine bağımlı olmaktan kurtarır hem de sertifika yenilemelerine dayanıklıdır. Kendi iç sertifika otoritenizi işletiyorsanız usage değerini 2 olarak seçebilirsiniz, ancak özel bir gerekçeniz yoksa 3 1 1 ile başlamak en pratik ve en az bakım gerektiren yaklaşımdır.

Sertifikamı yenilediğimde TLSA kaydını değiştirmem gerekir mi?#

Selector 1 yani açık anahtarı sabitleyen kombinasyonu kullanıyorsanız ve yenileme sırasında aynı açık anahtarı koruyorsanız TLSA kaydına dokunmanıza gerek kalmaz. Certbot gibi araçlarda --reuse-key seçeneği tam olarak bu amaca hizmet eder ve anahtarı sabit tutar. Eğer açık anahtar değişecekse, geçiş boyunca eski ve yeni anahtarın hash'lerini içeren iki TLSA kaydını bir arada yayınlayıp DNS yayılmasını bekledikten sonra eskisini silmeniz gerekir.

DANE web siteleri için de kullanışlı mı yoksa sadece e-posta için mi?#

DANE teknik olarak her TLS servisi için tanımlanabilir, ancak bugünkü tarayıcılar HTTPS için DANE doğrulamasını yerel olarak desteklemez. Bu yüzden web sitenizin ana sayfasında pratik bir koruma sağlamaz. Asıl değeri, sunucular arası SMTP e-posta aktarımındadır; burada gönderen mail sunucuları DANE'i etkin biçimde kullanır ve TLS düşürme saldırılarını engeller. Kısacası DANE'i öncelikle e-posta altyapınız için değerlendirin, web tarafında ise HSTS ve güncel sertifika yapılandırmasına yaslanın.

TLSA kaydımın doğru çalıştığını nasıl test ederim?#

En hızlı yol komut satırından üç adımlı bir kontroldür. Önce dig +dnssec TLSA _25._tcp.mail.alanadi.com ile hem kaydın yayınlandığını hem de DNSSEC ad bayrağının geldiğini doğrularsınız. Ardından Postfix ortamında posttls-finger -c -l dane smtp:mail.alanadi.com:25 komutu, karşı sunucuya DANE ile bağlanmayı deneyip eşleşmeyi raporlar. Çıktıda TLSA kaydının eşleştiğini belirten bir satır görüyorsanız kurulum başarılıdır; ayrıca çeşitli çevrimiçi DANE doğrulama araçları da aynı sonucu tarayıcıdan verir.

Kapanış#

TLSA kaydı ve DANE, güven kararını tanımadığınız yüzlerce sertifika otoritesinden alıp doğrudan kendi yönettiğiniz DNS altyapısına taşıyan güçlü bir mekanizmadır. Doğru kurulduğunda özellikle e-posta sunucuları arasındaki trafikte araya girme ve TLS düşürme saldırılarına karşı somut bir koruma sağlar. Ancak bu korumanın tek şartı vardır: sağlam kurulmuş bir DNSSEC temeli. Önce alan adınızı DNSSEC ile imzalayın, ardından 3 1 1 kombinasyonuyla açık anahtarınızı sabitleyin ve sertifika yenilemelerini açık anahtarı koruyacak şekilde yapılandırın.

Bu tür ileri seviye yapılandırmaları tek tek uğraşmadan hayata geçirmek isterseniz Clou.TR altyapısı yanınızda. DNSSEC destekli alan adı yönetimi, güvenli e-posta çözümleri, uçtan uca SSL yapılandırması ve deneyimli ekibimizin sunduğu sunucu yönetimi hizmetiyle e-posta ve web altyapınızı modern güvenlik standartlarına taşıyabilirsiniz. Kurumsal projeleriniz için sunucu çözümlerimize göz atın; sertifika ve DNS güvenliğini sizin adınıza biz kuralım, siz işinize odaklanın.