mTLS Kimlik Doğrulama

ipucu

Bu doküman spesifik bir politikanın detaylı kullanımını anlatır. Eğer Apinizer politika yapısını ilk kez kullanıyorsanız veya politikaların genel çalışma prensiplerini öğrenmek istiyorsanız, öncelikle Politika Nedir? sayfasını okumanızı öneririz.

Genel Bakış

Amacı Nedir?

• İstemcinin TLS el sıkışması sırasında sunduğu sertifikayı zorunlu kılarak, parola veya token taşımayan güçlü bir kimlik doğrulama katmanı kurmak.
• Sertifikadan çözümlenen kimliği Apinizer üzerindeki bir Kimlik Bilgisi ile eşleştirerek, istemciyi tanınan bir kimliğe bağlamak.
• İstemcinin sunduğu sertifika zincirini, eşleşen Kimlik Bilgisi'ne bağlı Anahtar Deposu ile doğrulayarak sahte veya yetkisiz sertifikaları reddetmek.
• Kimlik doğrulandıktan sonra erişim izni, geçerlilik süresi ve adres kısıtlarını denetleyip, gerektiğinde rol tabanlı yetkilendirme ile birleştirmek.

Ön Koşullar

Bu politika, ancak istemci sertifikası gateway'e ulaşabildiğinde çalışabilir. Aşağıdaki üç koşul sağlanmadan politika hiçbir isteği kabul etmez:

Koşul	Açıklama
Ortam ayarları	Politikanın uygulanacağı ortamda HTTPS etkin ve mTLS seçeneği işaretli olmalıdır. mTLS kapalıyken gateway istemciden sertifika istemez ve politika sertifika bulamaz.
TLS'in sonlandığı yer	TLS bağlantısı gateway üzerinde sonlanmalıdır. TLS'i önündeki bir yük dengeleyici veya ingress bileşeni sonlandırıyorsa istemci sertifikası gateway'e ulaşmaz; bu durumda bağlantının gateway'e kadar aktarılması gerekir.
Proxy türü	Politika yalnızca HTTP/HTTPS API Proxy'lerinde çalışır. gRPC ve WebSocket API Proxy'lerinde desteklenmez; bu proxy türlerinden birinde tanımlanmışsa istek sertifika denetimine hiç girmeden 500 hatasıyla reddedilir.

uyarı

Ortam ayarlarında HTTPS ve mTLS etkin değilse, bu politika eklenmiş olsa bile istekler sertifika bulunamadığı gerekçesiyle reddedilir. Politika yalnızca ayarların etkin olduğu ortamda çalışır.

Çalışma Prensibi

1. TLS el sıkışması: Ortamda mTLS etkinse gateway, bağlantı kurulurken istemciden sertifikasını ister. İstemcinin sunduğu sertifika, ortamın anahtar deposundaki güvenilir sertifikalara karşı doğrulanır. Bu doğrulamayı geçemeyen bağlantı, politika hiç çalışmadan kapanır.
2. Sertifikanın alınması: Politika, el sıkışmasından gelen istemci sertifikasını okur. Sertifika sunulmamışsa istek reddedilir.
3. Kimliğin çözümlenmesi: Kimlik Kaynağı ayarına göre sertifikadan bir ad okunur ve bu ad ile eşleşen, etkin durumdaki bir Kimlik Bilgisi aranır. Eşleşme bulunamazsa istek reddedilir.
4. Sertifika geçerliliği: Sertifikayı Doğrula seçeneği açıksa sertifikanın geçerlilik tarihleri kontrol edilir ve sertifikanın istemci kimlik doğrulaması amacıyla üretilmiş olduğu denetlenir. Süresi geçmiş veya farklı bir amaç için üretilmiş sertifikalar reddedilir.
5. Güven doğrulaması: Sertifikaların Issuer'ını Doğrula seçeneği açıksa, istemcinin sunduğu sertifika zincirinin tamamı, eşleşen Kimlik Bilgisi'ne bağlı anahtar deposundaki güvenilir sertifikalara karşı doğrulanır. Zincir bu depoya bağlanamıyorsa istek reddedilir.
6. Erişim denetimi: İstemci için ACL Kontrol Et seçeneği açıksa, eşleşen Kimlik Bilgisi'nin bu API'ye erişim izni, geçerlilik süresi ve varsa adres/konum kısıtları denetlenir.
7. Sonuç: Tüm denetimler başarılıysa çözümlenen kimlik isteğe yazılır, istenirse bir başlığa eklenir ve yetkilendirme etkinse rol denetimleri çalışır. Herhangi bir aşamada başarısızlık olursa istek durdurulur ve yapılandırılmış hata yanıtı döndürülür.

bilgi

Güven doğrulaması (5. adım), erişim denetiminden (6. adım) önce çalışır. Böylece bir istemci, sertifikasının güvenilirliği kanıtlanmadan kimlik doğrulaması geçmiş sayılmaz.

Kimlik Kaynağı

Bir sertifikada iki ayrı ad bulunur: sertifikanın sahibi (istemcinin kendisi) ve sertifikayı veren (imzalayan otorite). Politika, kimliği bu adlardan hangisiyle çözümleyeceğini Kimlik Kaynağı ayarı ile belirler.

Seçenek	Kimlik nereden okunur	Ne zaman kullanılır
Sertifika Sahibi (Subject CN)	İstemci sertifikasının kendi sahip adından	Her istemcinin ayrı bir Kimlik Bilgisi olarak tanımlandığı kurulumlar. En dar kapsamlı ve en kesin ayrım.
Sertifikayı Veren (Issuer CN)	Sertifikayı imzalayan otoritenin adından	Bir kurumun kendi sertifika otoritesinin verdiği tüm istemci sertifikalarının tek bir kurum kimliği olarak kabul edildiği kurulumlar.
Önce Sahip, Sonra Veren	Önce sahip adı denenir; eşleşme bulunamazsa veren adı denenir	Varsayılan seçenek. Her iki adlandırma yaklaşımının bir arada kullanıldığı kurulumları destekler.

not

Kimlik, yalnızca istemcinin kendi sertifikasından okunur. İstemcinin gönderdiği zincirdeki ara veya kök sertifikaların adları kimlik olarak kullanılmaz. "Sertifikayı Veren" seçeneğinde veren adı, istemci sertifikasının kendi üzerindeki bilgiden okunduğu için istemci zinciri göndermese bile kimlik çözümlenebilir.

Kimlik Kaynağı seçiminin, kurduğunuz Kimlik Bilgisi'nin kullanıcı adı ile uyumlu olması gerekir. Örneğin kurumunuzun sertifika otoritesi MyRootCA adını taşıyor ve bu otoritenin verdiği tüm istemcileri tek kimlik altında toplamak istiyorsanız, Kimlik Bilgisi'nin kullanıcı adı MyRootCA olmalı ve Kimlik Kaynağı Sertifikayı Veren (veya varsayılan) seçilmelidir. Her istemciyi ayrı tanımlamak istiyorsanız, Kimlik Bilgisi'nin kullanıcı adı istemci sertifikasının sahip adıyla aynı olmalı ve Sertifika Sahibi seçilmelidir.

Özellikler ve Yetenekler

Temel Özellikler

• Esnek Kimlik Çözümleme: Kimliğin sertifikanın sahip adından mı, veren adından mı çözümleneceğini seçebilme; her istemciyi ayrı ayrı veya bir otorite altındaki tüm istemcileri tek kimlikle tanıma.
• Sertifika Geçerlilik Kontrolü: Her istek için sertifikanın geçerlilik tarihlerini ve kullanım amacını denetleyerek süresi geçmiş veya amaç dışı sertifikaları reddetme.
• Zincir Tabanlı Güven Doğrulaması: İstemcinin sunduğu sertifika zincirini, kimliğe bağlı anahtar deposuna karşı doğrulama; ara sertifika otoriteleri içeren zincirleri destekleme.
• Erişim Denetimi: Kimliğin API'ye erişim izni, geçerlilik süresi ve adres/konum kısıtlarını denetleme.
• Aktif/Pasif Durum Kontrolü: Politikanın aktif veya pasif durumunu değiştirme. Pasif durumda politika uygulanmaz ancak yapılandırması saklanır.
• Koşul Bazlı Uygulama: Query Builder ile koşullar oluşturarak politikanın ne zaman uygulanacağını belirleme (örn: sadece belirli endpoint'lere veya başlık değerlerine göre).

İleri Düzey Özellikler

• Başlık Enjeksiyonu Yönetimi: Sertifikadan çözümlenen kimliği özel bir başlığa yazarak arka uç servislerine aktarma.
• Yetkilendirme Servisi Entegrasyonu: Kimlik doğrulamayı rol tabanlı erişimle birleştirme; rolleri API, veritabanı veya gizli bilgi yönetimi kaynaklarından çözümleme.
• Metot Bazlı Yetki Kısıtları: HTTP metoduna göre erişim kuralları tanımlayarak hassas operasyonları ayrıntılı düzeyde kontrol etme.
• Export/Import Özelliği: Politika yapılandırmasını dışa aktarma ve farklı ortamlara içe aktarma.
• Policy Group ve Proxy Group Desteği: Birden fazla politikayı grup içinde yönetme, gruplara toplu politika atama.
• Deploy ve Versiyonlama: Politika değişikliklerini canlı ortama yükleme, hangi API Proxy'lerde kullanıldığını görme.

Kullanım Senaryoları

Senaryo	Durum	Çözüm (Politika Uygulaması)	Beklenen Davranış / Sonuç
Kurumsal Cihaz Erişimi	Finansal servisler sadece şirket cihazlarından çağrılıyor	Kurumun sertifika otoritesi adıyla bir Kimlik Bilgisi tanımlanır, otoritenin sertifikası bu kimliğin anahtar deposuna eklenir, Kimlik Kaynağı Sertifikayı Veren seçilir	Kurumsal otoritenin verdiği sertifikalarla gelen istekler kabul edilir, diğerleri reddedilir
Cihaz Bazlı Kimlik	Her uç cihazın kendi sertifikası var ve ayrı izlenmesi gerekiyor	Her cihaz için sertifikanın sahip adıyla ayrı Kimlik Bilgisi tanımlanır, Kimlik Kaynağı Sertifika Sahibi seçilir	Her cihaz kendi kimliğiyle tanınır, trafik loglarında ayrı ayrı görünür, tek cihazın erişimi bağımsız kapatılabilir
Partner API Erişimi	Dış partnerlere sınırlı endpoint erişimi verilecek	Partner otoritesi adıyla Kimlik Bilgisi tanımlanır, Query Builder'da yol koşulu belirlenir, kimliğin erişim listesine yalnızca ilgili API eklenir	Partner sertifikası eşleşirse yalnızca tanımlı endpoint'lere erişim sağlanır
Süresi Geçmiş Sertifika	Yenilenmeyen istemci sertifikalarının erişimi kesilmeli	Sertifikayı Doğrula açık tutulur	Süresi geçmiş sertifikalarla gelen istekler reddedilir
Rol Bazlı Yetki	Aynı sertifikayla farklı servis rolleri uygulanacak	Yetkilendirme etkinleştirilir, roller başlığa yazılır	Arka uç servis rol başlığını okuyarak yetki verir
Adres Kısıtlaması	Sertifika paylaşımı riskine karşı adres eşlemesi	İstemci Adresini Kontrol Et etkinleştirilir, Kimlik Bilgisi'nde izinli adresler tanımlanır	Tanımlı adresler dışından gelen istekler reddedilir

Politika Parametrelerini Yapılandırma

Bu adımda, kullanıcı yeni bir politika oluşturabilir ya da mevcut politika parametrelerini yapılandırarak erişim kurallarını belirleyebilir. Tanımlanan parametreler, politikanın çalışma şeklini doğrudan etkiler. Bu sayede politika hem kuruma özel gereksinimlere göre özelleştirilebilir hem de merkezi olarak yönetilebilir.

Yeni mTLS Kimlik Doğrulama Politikası Oluşturma

Yapılandırma Adımları

Adım	Açıklama / İşlem
Adım 1: Ön Hazırlık	- Politikayı kullanacağınız ortamda HTTPS ve mTLS ayarlarının etkin olduğundan emin olun. - İstemcinin sertifikasını imzalayan otoritenin sertifikasını bir anahtar deposuna yükleyin. - Bu anahtar deposunu, istemciyi temsil edecek Kimlik Bilgisi'ne bağlayın ve Kimlik Bilgisi'nin erişim listesine ilgili API'yi ekleyin.
Adım 2: Oluşturma Sayfasına Gitme	- Sol menüden Development → Global Settings → Global Policies → mTLS Kimlik Doğrulama Politikası bölümüne gidin. - Sağ üstteki [+ Create] butonuna tıklayın.
Adım 3: Temel Bilgileri Girme	Policy Status (Politika Durumu): Aktif/Pasif durumu gösterir. Yeni politikalar varsayılan olarak aktiftir. Name (İsim) Zorunlu: Örnek: Production_mTLSAuth - Benzersiz isim girin, boşlukla başlamaz. - Sistem otomatik kontrol eder. Yeşil tik: kullanılabilir. Kırmızı çarpı: mevcut isim. Description (Açıklama): Örnek: "Kurumsal istemciler için mTLS kimlik doğrulaması" - Maks. 1000 karakter.
Adım 4: Kimlik Kaynağı Seçimi	- Kimlik Kaynağı: Kimliğin sertifikanın hangi adından çözümleneceğini belirler. - Sertifika Sahibi (Subject CN): Her istemci ayrı Kimlik Bilgisi ise. - Sertifikayı Veren (Issuer CN): Bir otoritenin verdiği tüm istemciler tek kimlik ise. - Önce Sahip, Sonra Veren: Varsayılan; her iki yaklaşımı da destekler. - Seçiminizin, Kimlik Bilgisi'nin kullanıcı adı ile uyumlu olduğundan emin olun.
Adım 5: Sertifika Doğrulama Parametreleri	- Sertifikayı Doğrula: Sertifikanın geçerlilik tarihlerini ve istemci kimlik doğrulaması amacıyla üretilmiş olduğunu kontrol eder. - Sertifikaların Issuer'ını Doğrula: İstemcinin sunduğu sertifika zincirini, Kimlik Bilgisi'ne bağlı anahtar deposuna karşı doğrular. Kimlik Bilgisi'nde anahtar deposu tanımlı değilse istek reddedilir. - İstemci için ACL Kontrol Et: Kimlik Bilgisi'nin API erişim izni, geçerlilik süresi ve adres kısıtlarını denetler.
Adım 6: Adres Kontrolü	- İstemci Adresini Kontrol Et: İsteğin geldiği adresin, Kimlik Bilgisi'nde tanımlı izinli adres ve konum listesiyle eşleşmesini arar. - Sertifika paylaşımı riskine karşı bu kontrolü etkin tutmanız önerilir.
Adım 7: Başlık ve Yetkilendirme Ayarları	- Çözümlenen Kimliği İstek Bağlamına Yaz: Bu politikanın çözümlediği kimliğin isteğin kimliği olarak kaydedilip kaydedilmeyeceğini belirler. Açık (varsayılan) iken bu kimlik trafik loglarında, sonraki politikalarda ve scriptlerde görünür. Kapalı iken kimlik yalnızca gerekli iç denetimler için kullanılır. - Kimliği Başlığa Ekle: Çözümlenen kimliği belirtilen başlığa yazar. - Kimliğin Ekleneceği Başlık: Varsayılan X-Authenticated-UserId, ihtiyaç halinde özelleştirin. - Enable Authorization: Rol ve metot bazlı kontrolleri aktif eder; Authorization sekmesindeki kaynak ve roller tanımlanmalıdır.
Adım 8: Koşul Tanımlama (İsteğe Bağlı)	- Condition sekmesine geçin. - Koşullar, politikanın hangi durumda aktif olacağını belirler. Örnekler: - Ortam bazlı: Header = X-Environment, Operator = Equals, Value = production - Endpoint bazlı: Path = /api/admin/* Koşul tanımlamazsanız politika her zaman aktiftir
Adım 9: Hata Mesajı Özelleştirme (İsteğe Bağlı)	- Error Message Customization sekmesine gidin. - Erişim reddedildiğinde dönecek mesajı özelleştirin.
Adım 10: Kaydetme	- Sağ üstteki [Save] butonuna tıklayın. Kontrol Listesi: Benzersiz isim. Kimlik Kaynağı seçimi Kimlik Bilgisi kullanıcı adıyla uyumlu. Kimlik Bilgisi'ne anahtar deposu bağlı. Kimlik Bilgisi'nin erişim listesinde ilgili API mevcut. Sonuç: - Politika listeye eklenir. - API'lere bağlanabilir. - Global politikaysa otomatik uygulanır.

Koşullar ve Hata Mesajı Özelleştirme panellerinin açıklaması için Politika Nedir? sayfasındaki Koşullar ve Hata Mesajı Özelleştirme (Error Message Customization) bölümlerini inceleyebilirsiniz.

Hata mesajı yapılandırmasının tüm katmanları, öncelik sırası ve senaryo örnekleri için Hata Mesajı Yapılandırma Rehberi sayfasına bakın.

Sertifika, anahtar deposu ve Kimlik Bilgisi hazırlığını uçtan uca gösteren örnek için mTLS Kimlik Doğrulama Senaryosu sayfasına bakabilirsiniz.

Politikayı Silme

Bu politikanın silme adımları ve kullanımdayken uygulanacak işlemler için Politika Yönetimi sayfasındaki Akıştan Politika Kaldırma bölümüne bakabilirsiniz.

Politikayı Dışa/İçe Aktarma

Bu politikanın dışa aktarma (Export) ve içe aktarma (Import) adımları için Export/Import sayfasına bakabilirsiniz.

Politikayı API'ye Bağlama

Bu politikanın API'lere nasıl bağlanacağına ilişkin süreç için Politika Yönetimi sayfasındaki Politikayı API'ye Bağlama bölümüne bakabilirsiniz.

Best Practices

Yapılması Gerekenler ve En İyi Uygulamalar

Kategori	Açıklama / Öneriler
Kimlik Kaynağı Seçimi	Kötü: Kimlik Kaynağı ile Kimlik Bilgisi kullanıcı adını uyumsuz bırakmak İyi: Kurulumun adlandırma yaklaşımına uygun seçeneği bilinçli seçmek En İyi: Her istemciyi ayrı Kimlik Bilgisi olarak tanımlayıp Sertifika Sahibi kullanmak; böylece tek istemcinin erişimi bağımsız kapatılabilir
Sertifika Yönetimi	Kötü: Otorite sertifikası yenilendiğinde anahtar deposunu güncellemeyi unutmak İyi: Yenileme sonrası anahtar deposunu güncelleyip politikayı yeniden yüklemek En İyi: Sertifika yenileme takvimini otomatik hatırlatma ile takip etmek
Güven Doğrulaması	Kötü: Sertifikaların Issuer'ını Doğrula seçeneğini kapatıp yalnızca ad eşleşmesine güvenmek İyi: Seçeneği açık tutup her kimliğe kendi anahtar deposunu bağlamak En İyi: Her kimliğe yalnızca kendi otoritesinin sertifikasını içeren dar kapsamlı bir anahtar deposu tanımlamak
Yetkilendirme Entegrasyonu	Kötü: Yetkilendirme açıkken rol listelerini boş bırakmak İyi: Roller için minimum yetki prensibini uygulamak En İyi: Roller değiştiğinde CI/CD içinde otomatik test çalıştırmak
Başlık Kullanımı	Kötü: Arka uç servislerin kimlik başlığını doğrulamaması İyi: Başlık doğrulamasını gateway arkasındaki servislerde uygulamak En İyi: Arka uç ile gateway arasında ayrıca güvenli kanal kullanmak
Deployment Süreci	Kötü: Canlı ortamda doğrudan değişiklik yapmak İyi: Test ortamında sertifika senaryolarını denemek En İyi: Blue/Green deployment planı oluşturmak

Güvenlik En İyi Uygulamaları

Güvenlik Alanı	Açıklama / Uyarılar
Dar Kapsamlı Anahtar Deposu	Bir kimliğe bağlı anahtar deposu ne kadar geniş olursa, o kimlik adına kabul edilebilecek sertifika kümesi o kadar büyür. Her kimliğe yalnızca gerekli otoriteyi içeren depo tanımlayın.
Kimlik Kaynağı Kapsamı	Sertifikayı Veren seçeneğinde, o otoritenin verdiği tüm sertifikalar aynı kimlik olarak kabul edilir. İstemcileri ayrı ayrı ayırt etmeniz gerekiyorsa Sertifika Sahibi seçeneğini kullanın.
Sertifika İptal Listesi	İptal kontrolleri gateway dışında yapılıyorsa periyodik olarak güncelleyin; iptal edilen sertifikaların kimlik eşleşmesini kaldırın.
Başlık Koruması	Arka uç servislerde başlık taklidine karşı imza veya güvenli iletişim kullanın.
Adres Eşleşmesi	Adres kontrolü devredeyse dinamik adres kullanan istemciler için izinli listeyi güncel tutun.
Loglama	Sertifika doğrulama hatalarını güvenli loglarda maskeli olarak saklayın, kişisel verileri anonimleştirin.

Kaçınılması Gerekenler

Kategori	Açıklama / Uyarılar
Güven Doğrulamasını Kapatmak	Neden kaçınılmalı: Yalnızca ad eşleşmesine güvenilir; sertifikanın gerçekten güvenilen bir otoriteden geldiği politika katmanında kanıtlanmaz. Alternatif: Seçeneği açık tutup kimliğe anahtar deposu bağlayın.
Geniş Kapsamlı Kimlik	Neden kaçınılmalı: Bir otoritenin verdiği tüm sertifikalar tek kimlik olur; tek bir istemcinin erişimini kapatmak mümkün olmaz. Alternatif: İstemci bazlı ayrım gerekiyorsa Sertifika Sahibi seçeneğini kullanın.
Ortam Ayarını Atlamak	Neden kaçınılmalı: HTTPS veya mTLS kapalıyken politika hiçbir isteği kabul edemez. Alternatif: Politikayı eklemeden önce ortam ayarlarını doğrulayın.
Test Ortamını Atlamak	Neden kaçınılmalı: Sertifika zincirindeki hatalar canlıda kesinti yaratır. Alternatif: Her değişikliği test ortamında aynı zincirle doğrulayın.

Performans İpuçları

Kriter	Öneri / Etki
El Sıkışma Optimizasyonu	Öneri: TLS oturum yeniden kullanımı (session resumption) etkinleştirin. Etki: El sıkışma süresi azalır, gecikme düşer.
Anahtar Deposu Kapsamı	Öneri: Anahtar depolarını gereksiz sertifikalarla şişirmeyin. Etki: Zincir doğrulaması hızlanır, güvenlik kapsamı da daralır.
Loglama Seviyesi	Öneri: Ayrıntılı logları sadece Geliştirme ortamında aktif edin. Etki: Canlı ortamda I/O yükü ve disk kullanımı azalır.
Yetkilendirme Çağrıları	Öneri: Yetkilendirme servis çağrılarına zaman aşımı ve Circuit Breaker ekleyin. Etki: Harici servis yavaşlamaları API yanıt süresini etkilemez.

Sık Sorulan Sorular (SSS)

Kategori	Soru	Cevap
Genel	mTLS kimlik doğrulama nedir?	Mutual TLS (mTLS), hem istemcinin hem de sunucunun birbirlerinin sertifikalarını doğruladığı çift yönlü kimlik doğrulama mekanizmasıdır.
Genel	Politika hangi durumlarda kullanılmalı?	Sertifika tabanlı istemci doğrulaması gereken tüm senaryolarda (partner entegrasyonları, kurumsal cihaz erişimleri, yüksek güvenlikli API'ler) kullanılabilir.
Teknik	Kimlik sertifikanın neresinden çözümlenir?	Kimlik Kaynağı ayarına göre istemci sertifikasının sahip adından, veren adından ya da önce sahip sonra veren sırasıyla çözümlenir. İstemcinin gönderdiği zincirdeki ara ve kök sertifikaların adları kimlik olarak kullanılmaz.
Teknik	Kimlik Bilgisi'nin kullanıcı adı ne olmalı?	Kimlik Kaynağı seçiminize bağlıdır: Sertifika Sahibi seçtiyseniz istemci sertifikasının sahip adı, Sertifikayı Veren seçtiyseniz sertifikayı imzalayan otoritenin adı olmalıdır.
Teknik	Güven doğrulaması nasıl çalışır?	İstemcinin sunduğu sertifika zincirinin tamamı, eşleşen Kimlik Bilgisi'ne bağlı anahtar deposundaki güvenilir sertifikalara karşı doğrulanır. Ara sertifika otoriteleri içeren zincirler desteklenir.
Teknik	Politika gRPC veya WebSocket API Proxy'lerinde çalışır mı?	Hayır. Politika yalnızca HTTP/HTTPS API Proxy'lerinde çalışır; gRPC veya WebSocket proxy'lerinde tanımlıysa istek 500 hatasıyla reddedilir.
Teknik	Ortam ayarlarında mTLS kapalıyken ne olur?	Gateway istemciden sertifika istemez, politika sertifika bulamaz ve istekler reddedilir. Politikayı eklemeden önce ortam ayarlarını doğrulayın.
Teknik	Kimlik Bilgisi'nde anahtar deposu tanımlı değilse ne olur?	Sertifikaların Issuer'ını Doğrula seçeneği açıkken istek reddedilir. Seçeneği kapatırsanız güven doğrulaması yapılmaz ve yalnızca ad eşleşmesine güvenilir.
Teknik	Sertifikam geçerli ama yine de reddediliyor, neden?	Sık nedenler: Kimlik Kaynağı seçimi ile Kimlik Bilgisi kullanıcı adının uyumsuz olması, sertifikayı imzalayan otoritenin kimliğin anahtar deposunda bulunmaması, Kimlik Bilgisi'nin erişim listesinde ilgili API'nin olmaması veya sertifikanın istemci kimlik doğrulaması amacıyla üretilmemiş olması.
Kullanım	Farklı endpoint'ler için farklı sertifika kuralları nasıl tanımlanır?	Query Builder'da endpoint bazlı koşullar oluşturup her koşul için ayrı politika atayın.
Kullanım	Varsayılan hata mesajını nasıl değiştirebilirim?	Error Message Customization sekmesinden durum kodu, hata kodu ve mesaj alanlarını düzenleyebilirsiniz.
Kullanım	Politika değişikliklerini nasıl test etmeliyim?	Test ortamında aynı sertifika zincirini kullanarak el sıkışmalarını deneyin, koşulları otomasyon testleriyle doğrulayın.