Karşılıklı TLS (mTLS) Sunucu Kurulumu ve Yönetimi

Son Güncelleme: Mayıs 2026

mTLS (Mutual TLS / karşılıklı kimlik doğrulama), sunucu ile istemci arasında her iki tarafın da sertifika ile doğrulandığı bir güvenlik mekanizmasıdır. Bu rehberde mTLS temel kavramları, OpenSSL ile sertifika otorisi (CA) oluşturma, Nginx ve Apache konfigürasyon örnekleri, otomasyon ve pratik kullanım senaryoları adım adım açıklanmaktadır.

İçindekiler

• mTLS Nedir?
• Neden mTLS Kullanılmalı?
• Bileşenler ve Terminoloji
• Sertifika Üretimi (OpenSSL Örneği)
• Nginx Konfigürasyonu
• Apache Konfigürasyonu
• Otomasyon ve Yönetim
• Kullanıcı (İstemci) Provizyonlama
• Uygulama Senaryoları
• TLS vs mTLS Karşılaştırma
• Sıkça Sorulan Sorular
• Sonuç

mTLS Nedir?

mTLS, standart TLS (Transport Layer Security / Taşıma Katmanı Güvenliği) el sıkışmasına ek olarak istemcinin de sunucuya bir sertifika ile kimliğini kanıtlamasını gerektiren bir yöntemdir. Standart TLS’de sadece sunucu doğrulanırken, mTLS ile her iki taraf da doğrulanır; böylece yetkisiz istemcilerin erişimi engellenir.

Neden mTLS Kullanılmalı?

• Güvenlik: Yetkisiz erişimlerin sertifika düzeyinde engellenmesi.
• Kimlik: Kullanıcı adı/parola yerine güçlü sertifika tabanlı kimlik doğrulama.
• İzlenebilirlik: Hangi istemcinin hangi isteği gönderdiğinin kesin olarak bilinmesi.
• Uyumluluk: PCI DSS, HIPAA gibi ek güvenlik gereksinimlerini destekler.

Bileşenler ve Terminoloji

mTLS kurulumu yaparken tanışacağınız temel terimler ve Türkçe karşılıkları:

• CA (Certificate Authority): Sertifika Otoritesi (Sertifika veren kurum).
• CSR (Certificate Signing Request): Sertifika İmzalama Talebi.
• Client Cert (İstemci Sertifikası): İstemcinin kimliğini doğrulayan sertifika.
• Server Cert (Sunucu Sertifikası): Sunucunun kimliğini doğrulayan sertifika.
• PKI (Public Key Infrastructure): Açık Anahtar Altyapısı.

Sertifika Üretimi (OpenSSL Örneği)

Aşağıdaki örnek, küçük ölçekli bir PKI için openssl kullanarak bir CA, bir sunucu sertifikası ve bir istemci sertifikası üretimini gösterir. Komutlar Linux/Unix (ör. Ubuntu, CentOS) üzerinde çalıştırılabilir.

Adımlar:

1. CA anahtarı ve kendinden imzalı kök sertifika oluşturma:

openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/C=TR/ST=Istanbul/L=Istanbul/O=CoreluxCA/OU=IT/CN=corelux.local"

2. Sunucu anahtarı ve CSR oluşturma:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=Corelux/OU=Web/CN=example.corelux.local"

3. Sunucu sertifikasını imzalama (CA ile):

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 825 -sha256

4. İstemci anahtarı ve CSR oluşturma:

openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=CoreluxClient/OU=Clients/CN=client1"

5. İstemci sertifikasını imzalama:

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 825 -sha256
# PKCS#12 dosyası (istemci uygulamalarında kullanmak için)
openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt -certfile ca.crt -passout pass:Parola123

Not: Üretim ortamında ca.key güvenli bir HSM (Hardware Security Module / Donanım Güvenlik Modülü) veya ayrı, güvenli bir sunucuda saklanmalıdır.

Nginx Konfigürasyonu

Nginx ile mTLS sağlamak için ssl_client_certificate ve ssl_verify_client direktifleri kullanılır. Aşağıdaki örnek, istemci sertifikasını doğrulayan temel bir server bloğu gösterir.

server {
    listen 443 ssl;
    server_name example.corelux.local;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    ssl_client_certificate /etc/ssl/certs/ca.crt; # CA sertifikası
    ssl_verify_client on; # isteğe bağlı olarak optional_no_ca

    location / {
        proxy_pass http://127.0.0.1:8080;
        # İstemci sertifikasından CN almak için header ekleme
        proxy_set_header X-Client-Cert $ssl_client_cert;
    }
}

Alternatif doğrulama seviyeleri:

• on: İstemci sertifikası zorunludur ve doğrulanır.
• optional: Sertifika isteyip doğrular; sertifika yoksa bağlantıya izin verir.
• optional_no_ca: Sertifika sunulmuşsa doğrular ama sadece sizin CA'nız tarafından imzalanma zorunluluğu aramaz.

Apache (httpd) Konfigürasyonu

Apache’de mod_ssl kullanılarak mTLS etkinleştirilebilir. Aşağıdaki örnek VirtualHost içinde gösterilmiştir.

    ServerName example.corelux.local

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/server.crt
    SSLCertificateKeyFile /etc/ssl/private/server.key
    SSLCACertificateFile /etc/ssl/certs/ca.crt

    # İstemci doğrulaması zorunlu
    SSLVerifyClient require
    SSLVerifyDepth 2

    # İstemci sertifika bilgilerini environment olarak aktarma
    SSLOptions +StdEnvVars

    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/

Apache ile istemci sertifikasının Common Name (CN) bilgisine SSL_CLIENT_S_DN_CN environment değişkeni ile erişebilirsiniz.

Otomasyon ve Yönetim

Büyük ölçekli dağıtımlarda manuel sertifika yönetimi hataya açıktır. Otomasyon ve Life-cycle yönetimi için öneriler:

• ACME veya otomatik yenileme: İstemci sertifikaları için özel ACME sunucuları ya da Vault kullanımı.
• Vault: HashiCorp Vault veya benzer bir PKI çözümü ile merkezi sertifika yönetimi.
• Sertifika rotasyonu: Anahtar değişimini düzenli planlayın (ör. 90-180 gün).
• Monitoring: Sertifika sona erme (expiration) için uyarılar kurun.

Kullanıcı (İstemci) Provizyonlama

İstemci sertifikaları dağıtımı için seçenekler:

• PKCS#12 dosyası: Masaüstü uygulamalar veya tarayıcılara .p12 dosyası ile aktarım.
• Yönetilen istemci sertifikaları: Mobil cihaz yönetimi (MDM) veya şirket içi yazılılarla otomatik kurulum.
• Scoped sertifikalar: Her uygulama/servis için ayrı subject veya SAN (Subject Alternative Name) kullanın.

Uygulama Senaryoları

mTLS aşağıdaki senaryolarda etkili olur:

• API sunucuları: İç API’ler arası güvenli iletişim için ideal.
• Microservice iletişimi: Hizmetler arası güveni güçlendirir.
• Yönetim panelleri: Sadece yetkili makinelerin erişimi için kullanın.
• VPN alternatifi: Belirli servisler için hafif, sertifika tabanlı erişim kontrolü.

TLS vs mTLS Karşılaştırma

Sorun Giderme ve En Yaygın Hatalar

• Sertifika zinciri hataları: CA sertifikasını doğru yerde (sunucu tarafında) tanımlayın.
• Tarayıcı uyumluluğu: Bazı tarayıcılar client.p12 yüklerken ek ayar isteyebilir.
• CN/SAN uyuşmazlığı: Sunucu sertifikasının CN veya SAN alanları ile erişilen hostname eşleşmelidir.
• Doğrulama seviyesi yanlış ayarı: optional yerine on/require kullanımı fark yaratır.

Pratik Örnekler

Örnek 1: İç API'ler için Nginx önünde mTLS, arka uç servislerine proxy pass ile güvenli bağlantı sağlanması. Bu yapı, sadece yetkili hizmetlerin API'ye erişmesine izin verir.

Örnek 2: Yönetim panelleri (ör. cPanel/WHM benzeri) için ek bir doğrulama katmanı olarak mTLS kullanımı; sadece şirket makinelerinin erişimine izin verilir.

Sıkça Sorulan Sorular

Sonuç

Özetle, mTLS sunucu ve istemci arasındaki güveni artıran, özellikle iç API'ler, microservice mimarileri ve yönetim panelleri için güçlü bir çözümdür. Uygulama öncesi PKI yönetimi, sertifika rotasyonu ve otomasyon konularını planlayın. Gereksinimlerinize göre mTLS uygulamasını Corelux altyapısı üzerinde test edebilir, ölçeklendirme ihtiyaçlarınız için Türkiye VPS Sunucu veya yüksek performanslı çözümler için Kiralık Sunucu hizmetlerimizi değerlendirebilirsiniz. Sertifika ve yönetim ihtiyaçlarınız için SSL Sertifikası hizmetimize göz atın ve kritik verileriniz için Yedekleme Hizmeti ile birlikte uygulayın.

Bu rehber uygulama odaklıdır; üretim ortamına geçmeden önce test ortamlarında (staging) doğrulama ve güvenlik kontrolleri yapmayı unutmayın.