mTLS, yani karşılıklı TLS, bir bağlantıda yalnız sunucunun değil, istemcinin de sertifikayla kimliğini kanıtladığı kimlik doğrulama modelidir. TLS, ağ üzerinden iletilen veriyi şifreleyen ve aktarım sırasında değiştirilmesini tespit eden protokoldür. Normal web kullanımında istemci çoğunlukla sunucu sertifikasını doğrular; mTLS'de sunucu da istemciden sertifika ister ve sertifikayı kendi güven ve istemci kimliği kurallarına göre doğrular.

Bu model, bağlantıyı şifrelerken iki tarafın sunduğu sertifika kimliklerini de doğrular. Özellikle uygulamaların birbirine veri ve işlem isteği gönderdiği API trafiğinde, yönetilen cihazlarda ve kurumsal erişimde istemciyi yalnız IP adresi, parola veya paylaşılan bir sırla tanımak yerine sertifika ve özel anahtar üzerinden doğrulamak için kullanılabilir.

mTLS ayrı bir şifreleme protokolü değildir. TLS'in sertifika tabanlı istemci kimlik doğrulama özelliğinin, bağlantının iki tarafını da doğrulayacak biçimde kullanılmasıdır.

TLS 1.3'te İstemci Sertifikasının Doğrulanması

Aşağıdaki aşamalar, iki tarafın da sertifikasını sunduğu ve güvenilen sertifika yetkililerine dayanan tam TLS 1.3 el sıkışmasını anlatır. El sıkışma, bağlantının başında kimliklerin doğrulandığı ve şifreleme için gerekli anahtarların oluşturulduğu mesaj alışverişidir.

Sunucu İstemci Sertifikası Talep Eder

İlk TLS parametreleri belirlendikten sonra sunucu, istemci sertifikası istediğini CertificateRequest mesajıyla bildirir. Bu mesaj, sunucunun kabul ettiği imza yöntemlerini ve varsa sertifika yetkililerine ilişkin tercihlerini taşır. Sunucu bu isteği, kendi sertifikasını içeren mesajdan önce gönderir.

İstemci Sunucunun Sertifikasını ve İmzasını Doğrular

Sunucu, sertifika zincirini Certificate mesajıyla gönderir ve CertificateVerify mesajındaki imzayla ilgili özel anahtarı kullanabildiğini kanıtlar. İstemci, bu imzayı, sertifikanın beklenen sunucu kimliğiyle eşleşmesini ve kabul ettiği güven köklerinden birine uzanan geçerli bir doğrulama yolu bulunmasını kontrol eder.

Sunucu, bu mesajların sonuna Finished mesajını ekler. İstemci bu mesajı da doğrulayarak el sıkışma verisinin bütünlüğünü ve hesaplanan anahtarların karşı tarafla uyumunu kontrol eder.

İstemci Sertifikasını ve Anahtar Sahipliği Kanıtını Gönderir

İstemci, sunucuyu doğruladıktan sonra kendi Certificate mesajında sertifikasını ve gerekiyorsa ara sertifikaları gönderir. Ardından CertificateVerify mesajıyla özel anahtarını kullanabildiğini kanıtlar. Her iki tarafın CertificateVerify imzası da el sıkışma mesajlarının özetini ve imzanın sunucuya mı istemciye mi ait olduğunu ayıran bağlam bilgisini içeren veri üzerinde hesaplanır; mesajlar doğrudan, olduğu gibi imzalanmaz.

Özel anahtar ağ üzerinden gönderilmez. Karşı taraf, imzayı sertifikadaki açık anahtarla doğrular. İstemci bu mesajların ardından kendi Finished mesajını gönderir.

Sunucu İstemci Kimliğini Kabul Eder veya Reddeder

Sunucu, istemci sertifikasının güvenilen bir kaynaktan geldiğini, geçerlilik süresini ve istemci kimlik doğrulamasına uygunluğunu kontrol eder. CertificateVerify imzasını ve istemcinin Finished mesajını da doğrular. Özel anahtar kanıtı veya Finished doğrulaması başarısızsa TLS bağlantısı sonlandırılır.

Sunucu, mTLS'yi zorunlu tutuyorsa uygun sertifika sunamayan istemciye erişim vermemelidir. İstemci sertifikasının isteğe bağlı olduğu bir yapılandırma bağlantıyı kimliği doğrulanmamış istemciyle sürdürebilir; böyle bir bağlantı kurulması, istemcinin mTLS ile doğrulandığını göstermez.

Doğrulanmış İstemcinin Uygulama İstekleri İşlenir

Başarılı doğrulamanın ardından uygulama, istemci kimliğine göre erişim kararını verebilir. Uygulama verisi TLS'in ürettiği trafik anahtarlarıyla şifrelenir. TLS 1.3 sunucusu kendi Finished mesajından sonra daha erken veri gönderebilse de istemci kimliği gerektiren veri ve işlemler için istemci doğrulamasının tamamlanmasını beklemelidir.

mTLS'de Güvenilen İstemci Sertifikaları Nasıl Belirlenir?

Sertifika dosyasının bulunması tek başına yeterli değildir. Sertifika yetkilisine dayanan kurulumlarda doğrulayan taraf, sertifikadan güvendiği bir sertifika yetkilisine uzanan geçerli bir doğrulama yolu kurabilmelidir. Bir kuruluş kendi istemci sertifikalarını belirli bir sertifika yetkilisi üzerinden verebilir ve sunucuyu yalnız bu yetkiliye uzanan geçerli bir doğrulama yolu bulunan sertifikaları kabul edecek biçimde yapılandırabilir.

Tipik yapıda istemci sertifikası istemci kimliğini temsil eder; ara sertifikalar bu sertifikayı sunucunun önceden güvendiği sertifika yetkilisine bağlayan doğrulama yolunu oluşturur. Sunucu hangi kök sertifikalara güveneceğini kendi yapılandırmasında önceden belirler; istemcinin bu kök sertifikaları ayrıca göndermesi gerekmez.

İki sertifikanın da teknik olarak geçerli görünmesi, istemci ile sunucunun birbirinin sertifikasını otomatik olarak kabul edeceği anlamına gelmez. Bu modelde sunucu, istemci sertifikasının doğrulama yolundaki sertifika yetkilisine güvenmelidir; istemci de sunucu sertifikası için aynı denetimi kendi güven yapılandırmasına göre yapar.

Bazı uygulamalar ise belirli istemci sertifikalarını önceden kaydeder ve bağlantıda sunulan sertifikayı bu kayıtla karşılaştırır. Uygulama bu yöntemi destekliyorsa kendinden imzalı istemci sertifikaları da kullanılabilir. Bu, herhangi bir kendinden imzalı sertifikaya güvenmek değil, önceden kabul edilen belirli sertifikayı ve ona ait özel anahtarın kullanımını doğrulamak demektir.

mTLS Ne İşe Yarar?

mTLS, sunucunun istemci kimliğini sertifikayla doğrulaması gereken ortamlarda kullanılır. Kullanıcının etkileşime girmediği servisler arası iletişimde özellikle uygundur; özel anahtar ilgili servis veya cihazda tutulur ve bağlantı sırasında doğrudan paylaşılmaz.

  • Servisler arası API erişimi: Bir API ağ üzerinden erişilebilir olsa bile yalnız güvenilen istemci sertifikasına sahip servislerin TLS oturumu kurmasına izin verilebilir.
  • Kurumsal erişim: Yönetilen istemcilere verilen sertifikalar, belirli iç sistemlere bağlanan cihaz veya uygulamaların kimliğini doğrulamak için kullanılabilir.
  • Cihaz kimliği: Otomasyon bileşenleri, ağ cihazları veya diğer yönetilen uçlar, kendilerine özgü sertifikalarla tanımlanabilir.
  • Katmanlı erişim kontrolü: mTLS kimlik doğrulaması, uygulama düzeyindeki kullanıcı hesabı veya rol kontrolünden önce ek bir bağlantı koşulu olarak uygulanabilir.

mTLS seçerken hangi istemcilere sertifika verileceğini, sertifikaları nasıl dağıtıp yenileyeceğinizi ve iptal işlemlerini nasıl yürüteceğinizi belirleyin. Merkezi olarak yönetilmeyen geniş bir istemci kitlesinde sertifika dağıtımı ve özel anahtar yönetimi ek iş yükü oluşturabilir.

mTLS ile Yalnız Sunucunun Sertifika Sunduğu TLS Arasındaki Farklar

Standart web TLS kullanımında istemci, bağlandığı sunucunun sertifikasını doğrular; istemcinin kullanıcı kimliği gerekiyorsa bu kimlik çoğunlukla HTTP veya uygulama katmanındaki başka bir yöntemle doğrulanır. mTLS'de ise TLS katmanı istemciden de sertifika ister ve istemci kimliğinin kriptografik doğrulamasını el sıkışmanın bir parçası haline getirir.

Bu fark, mTLS'nin parola veya uygulama oturumu mekanizmalarını zorunlu olarak ortadan kaldırdığı anlamına gelmez. mTLS, servis veya cihaz kimliğini doğrularken uygulama ayrıca kullanıcı, rol, işlem veya kaynak bazında yetkilendirme yapabilir.

Kimlik Doğrulama ile Yetkilendirme Aynı Şey Değildir

mTLS'nin temel görevi karşı tarafın sunduğu sertifika kimliğini ve özel anahtar sahipliğini doğrulamaktır. Bir istemcinin geçerli sertifika sunması, o istemcinin uygulamadaki her kaynağa erişme hakkı olduğu anlamına gelmez.

Uygulamalar genellikle sertifikadan elde edilen güvenilir kimliği bir hesap, servis adı, cihaz kaydı veya rol ile eşleştirir. Uygulama, hangi API yoluna, veriye veya işleve izin verileceğine bu eşleştirmeden sonra ayrı bir yetkilendirme kararı verir.

mTLS Yapılandırmasında Sertifika, Anahtar ve Yetki Kontrolleri

  • Güvenilen sertifika yetkililerini sınırlandırın: Sunucunun hangi istemci sertifika yetkililerine güveneceğini açıkça tanımlayın. Gereğinden fazla sertifika yetkilisine güvenmek, istenmeyen istemci sertifikalarının kabul edilmesine yol açabilir.
  • Özel anahtarları koruyun: Sertifika kimliğinin güvenilirliği, ona karşılık gelen özel anahtarın yalnız yetkili istemcide kalmasına bağlıdır.
  • Sertifika yaşam döngüsünü yönetin: Sertifikaları süreleri dolmadan yenileyin; iptal edilen veya artık kullanılmaması gereken sertifikaları reddetmek için sunucunun iptal denetimini yapılandırın. Yalnız güvenilen sertifika yetkilileri listesini güncel tutmak, aynı yetkilinin düzenlediği belirli bir istemci sertifikasını iptal edilmiş saydırmaz.
  • Kimliği yetkiyle karıştırmayın: TLS doğrulamasından sonra uygulama düzeyindeki erişim kurallarını ayrıca uygulayın.
  • Sertifika yolundaki sorunları kontrol edin: Uygun istemci sertifikasının seçilememesi, ara sertifika eksikliği, güvenilmeyen sertifika yetkilisi veya özel anahtar eşleşmesi gibi sorunlar el sıkışmayı başarısız kılabilir.

Sertifika İptali Mevcut Bağlantıları Hemen Kapatır mı?

Sertifikayı iptal etmek, açık TLS bağlantılarını kendiliğinden kapatmaz. Sunucunun yeni doğrulamalarda sertifikayı reddetmesi, iptal denetimini yapmasına ve güncel iptal bilgisine erişmesine bağlıdır. İptal durumu, CRL’ler (Certificate Revocation List) veya sertifikanın güncel durumunu sorgulayan OCSP gibi yöntemlerle denetlenebilir; kullanılan yöntem sunucunun ve sertifika altyapısının desteğine bağlıdır.

Sunucu TLS oturumunu yeniden kullanabiliyorsa yalnız sertifika iptal denetimine güvenmeyin. Önceki bağlantıdan türetilen anahtarlarla yeni bağlantı kurulurken sertifika yeniden sunulmayabilir. Erişimin hemen kesilmesi gerekiyorsa uygulamadaki yetkiyi kaldırmak, açık bağlantıları sonlandırmak ve önceki oturumun yeniden kullanılmasını engellemek gerekebilir. Sertifikanın süresinin dolması da açık bağlantıları tek başına kapatmaz.