Standart TLS bağlantısı trafiği şifreler, fakat çoğu senaryoda istemcinin gerçekten kim olduğunu kanıtlamaz. Şifre, API key, IP allowlist veya token tabanlı kontroller ek güvenlik sağlar; ancak bunlar paylaşılabilir, sızabilir, kopyalanabilir veya yanlış bağlamda kullanılabilir. mTLS ise istemcinin private key sahibi olduğunu doğrulayarak bağlantı seviyesinde daha güçlü bir kimlik sinyali üretir.
B2B API, ödeme, sağlık verisi paylaşımı, IoT cihaz trafiği ve yönetim arayüzü erişimi gibi senaryolarda bu fark kritiktir. Her partner, cihaz veya yönetici kendi sertifikasıyla gelir; sertifika süresi, CA zinciri, CN, fingerprint ve doğrulama sonucu audit edilebilir. Ancak bu bilgileri her uygulamanın ayrı ayrı parse etmesi operasyonu karmaşıklaştırır.
Geleneksel mTLS kurulumlarında CA bundle yönetimi, verify modu, hata kodları, sertifika field extraction ve uygulamaya bilgi aktarma parçalıdır. Bir ortamda sertifika zorunlu, başka ortamda geçiş için optional mod gerekebilir. Eski CA zincirleri, test sertifikaları veya partner geçişleri sırasında katı doğrulama ile kontrollü tolerans arasında ince bir denge gerekir.
Doğru yaklaşım, mTLS'i servis profili olarak yönetmektir. Verify modu, CA dosyası, CA hata stratejisi, sertifika alanlarının kurum servisine aktarımı ve AAM conditional access politikaları aynı modelde birleşmelidir.
TR7 mTLS İstemci Sertifika Kimlik Doğrulama bu modeli sunar: istemci sertifikasını bağlantı kontrolünden çıkarır, kurum servisi ve erişim politikaları için kullanılabilir kimlik objesine dönüştürür.
TR7, mTLS doğrulamasını servis bazlı verify modu, CA yönetimi, sertifika alanı aktarımı ve AAM erişim politikasıyla birlikte uygular.
none, optional ve required modlarıyla her servis kendi mTLS politikasını kullanabilir. Sertifika zorunlu kılınabilir, geçiş döneminde opsiyonel tutulabilir veya ilgili servis için devre dışı bırakılabilir.
Doğrulama kodu, SHA1 fingerprint, CN ve ek sertifika alanları HTTP header'larına dönüştürülebilir. Kurum servisi sertifika parse etmeden kimlik bilgisini okuyabilir ve uygulama mantığında kullanabilir.
Sertifika header'ları parse edilerek present, verified, verify, sha1 ve cn gibi alanlara dönüştürülebilir. Verify başarısız olsa bile sertifika bilgisi kontrollü biçimde loglanabilir ve karar motoruna taşınabilir.
CA doğrulama hataları tümden reddedilebilir, geçiş döneminde topluca tolere edilebilir veya yalnızca belirli hata kodları için esnetilebilir. Bu sayede staging, partner migration ve production politikaları aynı mTLS modelinde yönetilir.
mTLS İstemci Sertifika Kimlik Doğrulama, istemci sertifikasını edge seviyesinde doğrular, ayrıştırır, loglar ve kurum servisiyle paylaşır.
TR7, her servis için client certificate authentication davranışını ayrı yönetir. none modunda istemci sertifikası istenmez; optional modda sertifika sunulursa parse edilir, sunulmazsa bağlantı devam edebilir; required modda sertifika yoksa bağlantı reddedilir. Bu yapı, production'da katı güvenlik, staging'de esneklik ve migration sırasında kademeli geçiş sağlar. Aynı platformda farklı servisler farklı mTLS zorunluluklarıyla çalışabilir.
TR7, istemci sertifikalarını servis bazlı CA dosyalarıyla doğrulayabilir. Partner A'nın CA zinciri bir serviste, Partner B'nin CA zinciri başka bir serviste kullanılabilir. Bu ayrım, farklı iş ortaklarının veya cihaz gruplarının aynı ADC üzerinde izole şekilde yönetilmesini sağlar. Tek global CA listesine bağımlı kalmadan servis başına güven kökü tanımlanır.
TR7, istemci sertifikasının doğrulama durumunu x-ssl-verify gibi header'larla kurum servisine iletebilir. Başarılı doğrulama, sertifika yokluğu veya belirli doğrulama hatası uygulama tarafında açıkça görülebilir. Bu sayede kurum servisi bağlantının mTLS durumuna göre karar verebilir. Uygulama, TLS stack veya sertifika parse mantığıyla uğraşmadan doğrulama sonucunu kullanır.
TR7, istemci sertifikasından Common Name ve SHA1 fingerprint değerlerini çıkarıp kurum servisine header olarak aktarabilir. CN partner, cihaz, kullanıcı veya servis kimliği olarak kullanılabilir. SHA1 fingerprint ise allowlist, audit, eşleştirme veya hızlı revoke senaryolarında pratik bir anahtar sunar. Fingerprint normalize edilerek farklı yazım biçimleri tek formata indirilebilir.
caErrorStrategy ile CA doğrulama hatalarına karşı farklı davranışlar seçilebilir. ignoreAll geçici debug veya migration senaryolarında tüm CA hatalarını tolere edebilir; manualIgnoreList yalnızca belirli doğrulama hata kodlarına izin verir. Production'da bu esneklik kapatılarak sıfır tolerans uygulanabilir. Bu model, katı güvenlik ile gerçek dünya geçiş ihtiyaçları arasında kontrollü denge kurar.
TR7 yalnızca istemciden sertifika istemekle kalmaz; kurum servisine bağlanırken kendisi de istemci sertifikası sunabilir. Kurum servisi tarafında verify required, CA dosyası ve ADC istemci sertifikası tanımlanabilir. Böylece istemci ↔ TR7 ve TR7 ↔ kurum servisi arasında ayrı TLS güven politikaları kurulabilir. Bu yaklaşım, edge üzerinde inceleme yapılırken iç bağlantının da güvenli kalmasını sağlar.
İstemci sertifikası güçlü bir kimlik sinyalidir; fakat tek başına tüm erişim kararını taşımak zorunda değildir. TR7, sertifika bilgisini AAM conditional access politikalarıyla birlikte kullanabilir. Sertifika, IP, cihaz postürü, kullanıcı grubu, saat ve MFA durumu birlikte değerlendirilebilir. Bu sayede mTLS, daha geniş zero-trust erişim kararının bir parçası olur.
Sertifika doğrulaması başarılı olsa bile istek güvenli kabul edilmez; içerik ve hacim kontrolleri devam eder. TR7, mTLS kimlik katmanını WAAP, DDoS ve bot davranış analiziyle birlikte uygular. mTLS istemcinin kim olduğunu gösterir; WAAP isteğin ne yaptığını, DDoS katmanı ise trafik hacmini değerlendirir. Bu üç kontrol aynı servis önünde birlikte çalışabilir.
Optional modda sertifika sunan partnerler mTLS kimliğiyle işlenirken, henüz sertifika geçişi tamamlanmamış istemciler alternatif kimlik mekanizmasına bırakılabilir. Bu model, büyük B2B geçişlerinde tüm partnerleri aynı gün mTLS'e zorlamadan güvenli kademelendirme sağlar. Kurum servisi x-ssl-verify header'ının varlığına göre sertifika tabanlı veya API key tabanlı akışa karar verebilir. Geçiş tamamlandığında servis required moda alınabilir.
mTLS bağlantılarında sertifika subject, issuer, geçerlilik zamanı, doğrulama sonucu ve fingerprint gibi alanlar loglanabilir. SIEM tarafında hangi partnerin, hangi sertifikayla, hangi servise eriştiği daha net izlenir. Expired, self-signed veya issuer hatası gibi olaylar ayrıca analiz edilebilir. Bu kayıtlar uyumluluk, olay inceleme ve partner denetimi için güçlü audit izi üretir.
mTLS operasyonu; bind davranışı, verify kodları, header algılama, fingerprint normalizasyonu, CA dosyası ve SNI/Host doğrulamasıyla birlikte ele alınır.
Servis girişinde verify none, optional veya required davranışı tanımlanır. required modda sertifika sunmayan istemci bağlantısı reddedilir. optional modda sertifika varsa parse edilir, yoksa istek alternatif politika akışına bırakılabilir.
Sertifika doğrulama sonucu sayısal hata koduyla ifade edilebilir. 0 başarılı doğrulamayı, diğer değerler issuer bulunamaması, sertifikanın süresinin dolması, henüz geçerli olmaması veya self-signed olması gibi durumları temsil eder. Bu değer kurum servisine header olarak iletilebilir.
x-ssl-verify boşsa veya sertifika kullanılmadığını gösteriyorsa istemci sertifikası yok kabul edilir. Değer 0 ise sertifika doğrulanmış sayılır. Diğer değerlerde sertifika bilgisi mevcut olabilir fakat doğrulama başarısızdır; bu durum log ve politika kararlarında ayrı ele alınabilir.
Fingerprint değerleri büyük/küçük harf ve iki nokta ayracı gibi format farklarıyla gelebilir. TR7 bu değeri normalize ederek karşılaştırma ve allowlist işlemlerini sadeleştirir. Böylece aynı sertifika farklı yazım biçimleri nedeniyle farklı kimlik gibi değerlendirilmez.
Her servis kendi CA bundle'ını kullanabilir. Bu, partner, cihaz grubu veya iç servis ayrımlarında güven köklerini izole etmeyi sağlar. CA değişiklikleri servis etkisi dikkate alınarak planlanmalı ve audit edilmelidir.
mTLS kullanılan servislerde SNI ve Host doğrulaması ayrıca etkinleştirilebilir. Sertifika, SNI ve Host birlikte değerlendirildiğinde istek kimliği, hedef domain ve HTTP yönlendirme niyeti daha net doğrulanır. Bu model domain fronting benzeri suistimal risklerini azaltmaya yardımcı olur.
Her partner kendine özel istemci sertifikasıyla API'ye bağlanır. TR7 CN ve SHA1 fingerprint değerlerini loglar, kurum servisine aktarır ve partner bazlı audit ile rate-limit kararlarını kolaylaştırır.
Her cihaz fabrikada yüklenen benzersiz sertifikayla TR7'ye bağlanabilir. Cihaz seri numarası CN alanında taşınır, fingerprint allowlist ile revoke veya erişim kısıtlama akışları daha hızlı yönetilir.
Sağlık kurumları provider sistemleriyle veri paylaşırken mTLS kullanarak bağlantı seviyesinde kimlik doğrulaması yapabilir. Sertifika süresi dolduğunda veya doğrulama başarısız olduğunda erişim otomatik olarak kesilebilir.
Sistem yöneticileri TR7 yönetim arayüzüne istemci sertifikasıyla bağlanabilir. AAM üzerinde MFA ve cihaz postürüyle birleştiğinde bir laptop, bir sertifika ve bir yönetici kimliği birlikte doğrulanır.
İstemci sertifikasını edge'de doğrulayın, kurum servisine taşıyın ve AAM politikasıyla birleştirin. Kendi servislerinizle canlı bir kurulumda gezdirelim.