Normal HTTPS’te istemci genellikle sunucunun sertifikasını doğrular. mTLS, istemcinin de sertifika sunarak karşı tarafa kimliğini kanıtlamasına dayanan ayrı bir tasarımdır. Bir alan adına ücretsiz SSL almak, bütün API istemcilerine mTLS erişimi verilmesi anlamına gelmez. Bu rehber, teknik yaklaşımı ve operasyon sorularını açıklamak içindir; mevcut hizmetin otomatik mTLS sertifikası düzenlediği iddiasını içermez.
Kimlik ile yetkiyi ayrı tasarlayın
Geçerli bir istemci sertifikası bağlantıyı kurmaya yardımcı olabilir; hangi API işleminin yapılabileceği ayrıca belirlenmelidir. Sertifika kimliğini hesap veya servis kimliğine kontrollü eşleyin. Aynı sertifikayı bütün müşterilere dağıtmak ayrıştırmayı ve iptali zorlaştırır. Yetki kararını yalnız görünen ortak ad metnine bağlamadan güven zinciri ve uygulama tasarımını inceleyin.
Güven kökünü ve dağıtımı planlayın
Hangi otoritenin istemci sertifikalarını düzenleyeceğini, özel anahtarların nerede üretileceğini ve kimlerin erişeceğini tanımlayın. Gizli anahtarı sıradan e-posta eki gibi dağıtmayın. Sunucu sertifikası için kullanılan güven listesi ile istemci kabul politikası farklı olabilir. Test ve üretim güven zincirlerini birbirinden ayırın.
Yenilemeyi son güne bırakmayın
İstemci sertifikasının süresi bittiğinde API erişimi kesilebilir. Bitiş envanteri, sorumlu kişi ve güvenli yenileme yolu oluşturun. Eski ve yeni kimliğin geçiş dönemini uygulamanın izinleriyle birlikte sınayın. Birden fazla istemci örneği varsa hepsinin yeni materyali aldığını doğrulayın. Tek bir düğümdeki başarı dağıtımın tamamlandığını göstermez.
Kayıp veya iptalde etkili kapatma sağlayın
Özel anahtarın açığa çıktığı şüphesinde ilgili istemciyi nasıl engelleyeceğinizi önceden belirleyin. Sertifika iptal denetimi, uygulama erişim kapatma ve güven listesinin güncellenmesi ortamın tasarımına göre birlikte gerekebilir. Kimlik bilgilerini günlüklerde tutmayın. Olay kaydında gizli anahtar yerine güvenli referans ve zaman bilgisini kullanın.
Ters vekil ile uygulama sınırını koruyun
mTLS ters vekilde sonlanıyorsa uygulamaya taşınan istemci kimliği yalnız güvenilen iç bağlantıdan kabul edilmelidir. Kullanıcının aynı başlığı dışarıdan yazarak kimlik taklidi yapmasına izin vermeyin. Yapılandırma testi, olumsuz senaryo ve yetkisiz istemci reddini de kapsasın. Yalnız başarılı bağlantıyı görmek güvenlik tasarımını doğrulamaz.
Uygulama kontrol listesi
- İstemci kimliği ile API yetkisini ayırın.
- Anahtar dağıtım yolunu güvenceye alın.
- Yenileme ve iptal sorumlusunu belirleyin.
- Yetkisiz istemciyi de test edin.
Sık sorulan soru
Alan adı SSL’i mTLS istemci sertifikası yerine geçer mi?
Kullanım amacı ve güven politikası farklıdır. Bu iki süreci aynı hizmet veya otomatik yetki olarak kabul etmeyin.
Sonraki adım
Başvuru için ücretsiz SSL formunu, teknik aşamalar için SSL rehberini kullanabilirsiniz. Kurulumda bir hata varsa destek talebinize etkilenen alan adını ve hata mesajını ekleyin.
Bu içerik ucretsizssl.tr bilgi merkezi için hazırlanmış, teknik kaynaklarla karşılaştırılmış bir açıklamadır. Altyapı ve ürün seçenekleri sağlayıcıya göre değişebilir. Hazırlama tarihi: 16 Ekim 2026.
NGINX istemci sertifikası doğrulama ayarıGüvenli teknik kontrol
Aşağıdaki örnekleri kendi ortamınıza uyarlayın. Komutlar kullanıcı adını, OTP veya özel anahtar içeriğini paylaşmayı gerektirmez.
# mTLS tasarımı için üretimden önce ayrı test ortamı kullanın.
# Güvenilmeyen istemci ve iptal senaryolarını da doğrulayın.
