Nginx ve Caddy ile Mikroservislerde mTLS

Mikroservislerde İstemci Kimliğini Doğrulama

Bir mikroservisin ağdan erişilebilir olması, çağrıyı yapan servisin yetkili olduğunu göstermez. Karşılıklı TLS (mTLS), sunucu sertifikasının yanında istemci sertifikasını ve ona ait özel anahtarın sahipliğini doğrular. Nginx veya Caddy bu kontrolü TLS ucunda yapabilir; uygulama ise doğrulanan kimliğin hangi kaynağa erişebileceğine karar verir.

Bu rehber iki proxy için aynı sertifika akışını ve aynı Node.js yetkilendirme örneğini kullanır. Gelen mTLS, kimliğin backend’e aktarılması, ayrı upstream mTLS bağlantısı ve iptal adımları birlikte ele alınır. Güncel OpenSSL 3.x, TLS modüllü Nginx, Caddy 2.11.7 sözdizimi ve desteklenen Node.js sürümü varsayılır. Alan adları ve dosya yolları laboratuvar örneğidir.

mTLS’in Kimlik ve Yetki Sınırı

İstemci, sunucunun güven zincirini ve hostname’ini doğrular. Proxy de istemcinin sertifikasını kabul ettiği CA ve kullanım kurallarına göre denetler. Bu iki sertifika aynı CA’dan gelmek zorunda değildir. İstemci özel anahtarını karşı tarafa göndermez; TLS sırasında ona sahip olduğunu kanıtlar. Sertifika zincirinin geçerli olması, uygulama rolünün otomatik belirlendiği anlamına gelmez.

Ele geçirilmiş istemci anahtarı veya yetkili servisin kötüye kullanımı için ayrıca müdahale gerekir. Ayrı servis/cihaz anahtarları, en dar erişim politikası, yenileme ve etkin iptal planı tutun. Kısa sertifika ömrü geçerlilik penceresini küçültür; anahtarı kendiliğinden değiştirmez ve acil iptalin yerini almaz.

Laboratuvar CA’sı, Sunucu ve İstemci Sertifikası

Aşağıdaki özel CA yalnız laboratuvar içindir; örneği sade tutmak için hem sunucu hem istemci sertifikası üretir. Üretimde farklı güven alanlarını, çevrimdışı kökü ve ara CA gereksinimini ayrıca tasarlayın. api.example.test yerel test adıdır; kamusal Let’s Encrypt sertifikası beklenmez. Sunucunun SAN’ı, istemcinin bağlandığı adla eşleşmelidir.

Yeni ve ayrı bir dizin açılır; mevcut dizini tekrar kullanıp CA durumunu sıfırlamayın. Sonraki CA komutlarını aynı dizinde çalıştırın: dir = . mevcut çalışma dizinidir. İstemci profili clientAuth, sunucu profili serverAuth ve SAN içerir; CA ve yaprak kısıtları açıkça yazılır. CA anahtarı şifrelenir, imzalama sırasında parola ve onay istenir.

set -eu
umask 077
mtls_dir="$HOME/service-mtls-lab"
mkdir "$mtls_dir"
cd "$mtls_dir"
mkdir certs crl newcerts private
: > index.txt
printf '1000\n' > serial
printf '1000\n' > crlnumber
cat > openssl.cnf <<'EOF'
[ ca ]
default_ca = CA_default

[ CA_default ]
dir = .
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
crlnumber = $dir/crlnumber
private_key = $dir/private/ca.key.pem
certificate = $dir/certs/ca.cert.pem
default_md = sha256
default_days = 90
default_crl_days = 7
policy = client_policy
unique_subject = no
copy_extensions = none
x509_extensions = client_cert
crl_extensions = crl_ext

[ client_policy ]
commonName = supplied

[ req ]
distinguished_name = req_dn
prompt = no
x509_extensions = root_ca

[ req_dn ]
CN = Service mTLS Lab CA

[ root_ca ]
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

[ client_cert ]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = clientAuth
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always

[ crl_ext ]
authorityKeyIdentifier = keyid:always
[ server_cert ]
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = DNS:api.example.test,DNS:backend.example.test
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
EOF
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -aes-256-cbc -out private/ca.key.pem
openssl req -new -x509 -config openssl.cnf -key private/ca.key.pem -days 3650 -sha256 -out certs/ca.cert.pem
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private/client.key.pem
openssl req -new -key private/client.key.pem -subj "/CN=stock-service" -out client.csr.pem
openssl ca -config openssl.cnf -extensions client_cert -days 90 -notext -in client.csr.pem -out certs/client.cert.pem
openssl ca -config openssl.cnf -gencrl -out crl/ca.crl.pem
openssl verify -CAfile certs/ca.cert.pem -purpose sslclient -crl_check -CRLfile crl/ca.crl.pem certs/client.cert.pem
openssl x509 -in certs/client.cert.pem -noout -serial -dates
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private/server.key.pem
openssl req -new -key private/server.key.pem -subj /CN=api.example.test -out server.csr.pem
openssl ca -config openssl.cnf -extensions server_cert -days 90 -notext -in server.csr.pem -out certs/server.cert.pem
openssl verify -CAfile certs/ca.cert.pem -purpose sslserver -verify_hostname api.example.test certs/server.cert.pem

openssl ca üretimi veritabanına kaydeder; ilk CRL, Nginx ayarından önce oluşturulur. İlk istemci seri numarası bu yeni dizinde 1000 olur. Sertifikadaki gerçek kimliği ve talebi onaylamadan imzalamayın. CA özel anahtarını proxy’ye taşımayın; proxy’ye sunucu sertifikası/anahtarı, açık CA sertifikası ve Nginx için CRL kurulur. step-ca belgeleri otomasyon için başlangıçtır; varsayılan pasif iptal yalnız yenilemeyi durdurur, mevcut sertifikayı anında geçersiz kılmaz.

Nginx’te Doğrulama ve Güvenilir Kimlik Aktarımı

Nginx TLS’i sonlandırır ve istemciyi doğrular; doğrulanmış sertifikayı uygulamaya iletmek bunun üzerine kurulan ayrı bir işlemdir. Örnekte certs/server.cert.pem ve private/server.key.pem uygun servis hesabının okuyabildiği /etc/mtls/server.crt ve server.key yollarına kurulur. CA sertifikası /etc/mtls/ca.crt, ilk CRL /etc/mtls/ca.crl olur. Anahtarı yalnız gerekli süreçler okuyabilmelidir.

Aşağıdaki blok mevcut http kapsamına eklenir; log_format server dışında kalır. Zorunlu doğrulama bütün hostname’i kapsar. İstemci yaprak sertifikası $ssl_client_escaped_cert ile URL kodlu PEM olarak aktarılır; çok satırlı $ssl_client_cert doğrudan HTTP başlığına yazılmaz. Var olmayan bir CN değişkeni kullanılmaz.

# Inside the existing http {} block:
log_format service_mtls '$remote_addr "$request" $status '
                        'verify="$ssl_client_verify" serial="$ssl_client_serial"';
server {
    listen 443 ssl;
    server_name api.example.test;
    ssl_certificate /etc/mtls/server.crt;
    ssl_certificate_key /etc/mtls/server.key;
    ssl_client_certificate /etc/mtls/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 1;
    ssl_crl /etc/mtls/ca.crl;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache off;
    ssl_session_tickets off;
    access_log /var/log/nginx/service_mtls.log service_mtls;
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_set_header X-Client-Cert-Encoding uri-pem;
        proxy_set_header X-Client-Cert $ssl_client_escaped_cert;
    }
}

ssl_verify_client yalnız http/server kapsamındadır; location içine konamaz. Aynı hostta bazı yollar public olacaksa server düzeyinde optional ve her korunan yolda SUCCESS kontrolü gerekir; tarayıcı istemi ve geçersiz sertifikanın public trafiğe etkisi değerlendirilmelidir. Buradaki bütün-host örneğinde /healthz de mTLS ister. Nginx SSL modülü belgeleri kapsamı, CRL’yi ve gerçek değişkenleri açıklar.

Aşağıdaki bağımsız Node.js örneği iki proxy’nin kodlamasını aynı SHA-256 sertifika kimliğine çevirir. Önce izin dosyasını üretin ve yönetilen, istemcinin değiştiremediği /etc/service-auth/allowed-clients.json yoluna kurun. CA anahtarı veya istemci anahtarı uygulamaya verilmez. Backend’i yalnız güvenilen proxy ulaşabilecek biçimde yalıtın; loopback dış erişimi sınırlar, güvenilmeyen yerel süreçlere karşı tek başına yeterli değildir. Çok kiracılı ortamda izinli Unix soketi, süreç/ağ yalıtımı veya ayrı doğrulanmış bağlantı kullanın.

node --input-type=module - certs/client.cert.pem > allowed-clients.json <<'JS'
import { readFileSync } from 'node:fs';
import { X509Certificate } from 'node:crypto';
const cert = new X509Certificate(readFileSync(process.argv[2]));
console.log(JSON.stringify({ [cert.fingerprint256]: 'stock-service' }, null, 2));
JS

// Save as app.mjs. Only the trusted local proxy may reach this listener.
import { createServer } from 'node:http';
import { readFileSync } from 'node:fs';
import { X509Certificate } from 'node:crypto';

createServer((req, res) => {
  const reply = (status, body) => {
    res.writeHead(status, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify(body));
  };
  if (req.headers['x-client-verify'] !== 'SUCCESS') {
    return reply(401, { error: 'Client authentication required' });
  }
  let cert;
  try {
    const value = req.headers['x-client-cert'];
    const encoding = req.headers['x-client-cert-encoding'];
    if (typeof value !== 'string' || value.length > 24000) throw new Error();
    if (encoding === 'uri-pem') {
      cert = new X509Certificate(decodeURIComponent(value));
    } else if (encoding === 'base64-der' && /^[A-Za-z0-9+/]+={0,2}$/.test(value)) {
      cert = new X509Certificate(Buffer.from(value, 'base64'));
    } else {
      throw new Error();
    }
  } catch {
    return reply(401, { error: 'Invalid identity encoding' });
  }
  let allowed;
  try {
    allowed = JSON.parse(readFileSync('/etc/service-auth/allowed-clients.json', 'utf8'));
    if (!allowed || typeof allowed !== 'object' || Array.isArray(allowed)) throw new Error();
  } catch {
    return reply(503, { error: 'Authorization policy unavailable' });
  }
  const service = Object.hasOwn(allowed, cert.fingerprint256)
    ? allowed[cert.fingerprint256] : undefined;
  if (service !== 'stock-service') return reply(403, { error: 'Not authorized' });
  let path;
  try { path = new URL(req.url, 'http://localhost').pathname; }
  catch { return reply(400, { error: 'Invalid request target' }); }
  if (req.method === 'GET' && path === '/stock') {
    return reply(200, { service, status: 'authorized' });
  }
  if (req.method === 'GET' && path === '/healthz') return reply(200, { status: 'ok' });
  return reply(404, { error: 'Not found' });
}).listen(3000, '127.0.0.1');

Uygulamayı node app.mjs ile servis yöneticiniz altında çalıştırın. X509Certificate burada sertifikayı ayrıştırır; TLS zincir doğrulamasını tekrar yapmaz. Kimlik başlıklarının güvenilirliği proxy erişim sınırına dayanır. Küçük örnek izin JSON’unu her istekte okur; yüksek trafikte aynı ret politikasını koruyan sürümlü politika önbelleği veya yetkilendirme servisi kullanın. SHA-256, yaprak sertifikanın tam kimliğidir; yenilemede yeni değeri yetkilendirin. Nginx’e ayrıca tek CA altında seri kontrolü eklenebilir:

# Optional additional gate, inside http {}; this single CA only:
map "$ssl_client_verify:$ssl_client_serial" $client_allowed {
    default 0;
    "SUCCESS:1000" 1;
}
# Inside each protected location before proxy_pass:
# if ($client_allowed = 0) { return 403; }

Map http kapsamındadır; yorumdaki if satırı ilgili location’da etkinleştirilmelidir. Birden fazla issuer varsa seri tek başına eşsiz değildir. Backend ayrı makinedeyse aşağıdaki bağlantı modeli kullanılabilir. Önce backend.example.test SAN’ına uygun sunucu sertifikasını, backend CA güvenini ve proxy’ye özel clientAuth sertifikasını hazırlayın; backend yalnız bu proxy kimliğini kabul etmelidir.

# Replace the incoming server's location / with this example.
# Requires separately issued gateway client credentials and backend trust.
location / {
    proxy_pass https://10.0.0.12:8443;
    proxy_ssl_server_name on;
    proxy_ssl_name backend.example.test;
    proxy_ssl_trusted_certificate /etc/mtls/backend-ca.crt;
    proxy_ssl_verify on;
    proxy_ssl_verify_depth 1;
    proxy_ssl_certificate /etc/mtls/gateway-client.crt;
    proxy_ssl_certificate_key /etc/mtls/gateway-client.key;
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
        proxy_set_header X-Client-Verify $ssl_client_verify;
        proxy_set_header X-Client-Cert-Encoding uri-pem;
        proxy_set_header X-Client-Cert $ssl_client_escaped_cert;
}

Backend’in TLS’te doğruladığı kimlik gateway’dir. Asıl çağıran servisin kimliği, gateway’in güvenilir biçimde ilettiği başlıkta taşınır; iki TLS bağlantısı aynı oturum değildir.

Caddy’de Aynı mTLS ve Uygulama Politikası

Caddy örneği aynı elle üretilmiş sunucu sertifikasını kullanır ve istemci CA’sına karşı require_and_verify uygular. Bu dosyaların yenilenmesini Caddy otomatik üstlenmez. Kamusal, doğrulanabilir bir hostname için ayrı otomatik HTTPS yapılandırması seçilebilir; .local veya bu .test örneğine kamusal sertifika verileceğini varsaymayın.

https://api.example.test {
    tls /etc/mtls/server.crt /etc/mtls/server.key {
        client_auth {
            mode require_and_verify
            trust_pool file {
                pem_file /etc/mtls/ca.crt
            }
        }
    }
    reverse_proxy 127.0.0.1:3000 {
        header_up X-Client-Verify SUCCESS
        header_up X-Client-Cert-Encoding base64-der
        header_up X-Client-Cert {tls_client_certificate_der_base64}
    }
}

Güncel trust_pool file CA dosyasını okur. Caddy yaprak sertifikayı {tls_client_certificate_der_base64} ile tek satır base64 DER olarak iletir. X-Client-Verify değerinin SUCCESS olması, bütün site için zorunlu doğrulamanın başarılı olmasına dayanır; varsayılan bir “verified” değişkeni varsayılmaz. Bütün kimlik başlıkları reverse_proxy içinde header_up ile yazılır. Caddy TLS ve client_auth belgeleri kullanılan söz dizimini açıklar.

Path’e özel handle, aynı TLS bağlantısındaki zorunlu mTLS’i kaldırmaz. mTLS’siz sağlık dinleyicisi gerekiyorsa ayrı ve izleme ağına kısıtlı olmalıdır; korunan uygulamaya public geçiş yolu açmamalıdır. Caddy’den ayrı backend’e mTLS için mevcut reverse_proxy bloğu aşağıdakiyle değiştirilebilir; gateway sertifikası ve backend doğrulaması önceden kurulmuş olmalıdır.

# Replace reverse_proxy inside the incoming mTLS site with this block.
# The backend must require and authorize the gateway client certificate.
reverse_proxy https://10.0.0.12:8443 {
    header_up X-Client-Verify SUCCESS
    header_up X-Client-Cert-Encoding base64-der
    header_up X-Client-Cert {tls_client_certificate_der_base64}
    transport http {
        tls_server_name backend.example.test
        tls_trust_pool file {
            pem_file /etc/mtls/backend-ca.crt
        }
        tls_client_auth /etc/mtls/gateway-client.crt /etc/mtls/gateway-client.key
    }
}

tls_trust_pool backend sunucu güvenini, tls_server_name doğrulanacak adı, tls_client_auth Caddy’nin sunduğu gateway kimliğini belirler. Asıl istemcinin başlığı ancak bu gateway yetkilendirildikten sonra backend tarafından kabul edilmelidir.

API ve Mikroservislerde Yetki Tasarımı

Örnekte stock-service sertifikası /stock erişimine bağlanır. Sipariş servisi başka bir servisi çağırıyorsa TLS’te çağıranın sertifikası sunulur; hedefin adını CN’ye yazmak çağıranın kimliğini değiştirmez. Sertifika adı veya SAN kimliğini CA kontrollü üretim politikasıyla ilişkilendirin. CN’de belirli bir kelimenin bulunması otomatik yönetici veya ekip yetkisi sağlamamalıdır.

Harici partner istemci sertifikası desteklemiyorsa onun erişim yolu için token, imza ve tekrar oynatma kontrolleri ayrı tasarlanabilir. İç mTLS, dış isteğin iş yetkilerini kendiliğinden doğrulamaz. Gateway’in hangi kullanıcı veya servis adına işlem yaptığını uygulama politikası açıkça belirlemelidir. Bir bağlantının doğrulanması bütün sonraki bağlantıları otomatik doğrulamaz.

Servis başına ayrı anahtar, sertifika ve yetki kaydı tutmak olay incelemesini kolaylaştırır. Logdaki sertifika kimliğini uygulama kararı ve istek iziyle ilişkilendirin; özel anahtarları veya tam sertifika başlıklarını gereksiz yere kaydetmeyin. OpenTelemetry ile izlenebilirlik rehberi çağrı zincirinin izlenmesini ele alır; iz kimliği, TLS istemci kimliğinin yerine geçmez.

Rotasyon, CRL ve Acil Erişim İptali

Laboratuvar yaprakları 90 gün geçerlidir; üretim ömrünü risk ve yenileme kapasitesine göre seçin. Yeni sertifika farklı SHA-256 değeri üretir. Planlı yenilemede yeni yetkiyi kontrollü ekleyin, yeni bağlantıyla doğrulayın, eski yetkiyi kaldırın. CA değişiminde gerekli eski/yeni güven örtüşmesini yönetin; birleştirilmiş CA dosyası tek başına kimlik ve iptal politikasını taşımaz.

Anahtar sızıntısında sertifikayı CA veritabanında iptal etmekle yetinmeyin; ilgili kimliği uygulama izin JSON’undan atomik güncellemeyle kaldırın. Örneğin boş {} politikası bütün servisleri reddeder. Mevcut izin dosyasını istemcinin değiştirmesine izin vermeyin. Nginx için yeni CRL’nin dağıtımı ve başarılı reload da gerekir. Aşağıdaki CA komutları yalnız CA makinesinde çalışır:

cd "$HOME/service-mtls-lab"
openssl ca -config openssl.cnf -revoke certs/client.cert.pem -crl_reason keyCompromise
openssl ca -config openssl.cnf -gencrl -out crl/ca.crl.pem
openssl crl -in crl/ca.crl.pem -noout -lastupdate -nextupdate

Açık CRL’yi Nginx’te /etc/mtls/ca.crl yoluna güvenli ve atomik biçimde dağıtın; nginx -t ardından desteklenen reload işlemini ve yeni bağlantıda reddi doğrulayın. CA anahtarını proxy’ye kopyalamayın. Bu profilin CRL süresi 7 gündür; iptal olmasa bile nextUpdate öncesinde yenileyin ve dağıtımı izleyin.

Caddy’deki temel trust_pool ayarı bu Nginx CRL dosyasını kendiliğinden denetlemez. Desteklenen bir ek sertifika verifier’ı veya uygulama yetki kontrolüyle erişim iptalini uygulayın. Buradaki uygulama SHA-256 kaydı kaldırıldığında sonraki isteği reddeder; TLS sertifikasının kendisi hâlâ doğrulanabilir. Kısa ömür ve yenilemeyi durdurmak kalan geçerlilik süresinde acil engelleme sağlamaz. Mevcut WebSocket, TLS ve uygulama oturumlarını ayrıca ele alın.

Hostname uyuşmazlığında sunucu SAN’ını ve gerçek SNI adını, zincir hatasında issuer ve ara sertifikaları, tarih hatasında sertifika/CRL süresini ve saatleri kontrol edin. Yenileme aynı anahtarı tekrar kullanabilir; anahtar rotasyonu için yeni anahtar üretimini açıkça planlayın. Sızmış anahtarı yeni p12 parolasıyla paketlemek önceki kopyaları geçersiz kılmaz.

Kabul, Ret ve Kimlik Aktarımı Testleri

Aşağıdaki örnek proxy’nin aynı test makinesinde 443 dinlediğini varsayar; başka makinede –resolve adresini o proxy’nin adresiyle değiştirin. Dosyaların bulunduğu CA/istemci test dizininden çalıştırın. Olumlu testi, önceki bölümdeki sertifika iptali ve uygulama izin kaydını kaldırma işlemlerinden önce yapın; ardından aynı kimlikle reddi doğrulayın. –resolve DNS’i yalnız bu curl isteğinde geçersiz kılar, doğru hostname ve SNI doğrulaması korunur. İstemci özel anahtarı test istemcisinde kalır.

curl --resolve api.example.test:443:127.0.0.1 --cacert certs/ca.cert.pem -i https://api.example.test/stock
curl --resolve api.example.test:443:127.0.0.1 --cacert certs/ca.cert.pem --cert certs/client.cert.pem --key private/client.key.pem -i https://api.example.test/stock

İlk istek uygulamaya ulaşmamalı, yetkili sertifikayla ikinci istek örnek /stock yanıtını almalıdır. Güvenilmeyen sertifikayı, aynı CA’dan fakat izin listesi dışındaki yaprağı, sahte kimlik başlıklarını ve iptal sonrası yeni bağlantıyı da test edin. Nginx HTTP hata yanıtı verebilir; Caddy veya başka TLS aşamaları bağlantıyı HTTP’den önce kesebilir. Her ret için 400/401/403 beklemeyin.

Merkezi VPS günlük yönetimi rehberi uygulama ve proxy gözlemlerini bir araya getirmeye yardımcı olur. Nginx log_format http kapsamında doğrulama ve seri numarasını kaydeder. Caddy’de TLS hata günlüğü ile uygulamanın yetki kararını ayrı değerlendirin. Log toplama araçlarının güncel destek durumunu kontrol edin ve hassas kimlik verisinin saklama süresini belirleyin.

nftables güvenlik duvarı rehberi ağ sınırını tamamlar. İlgili IPv4/IPv6 yollarını, alternatif hostname/portları ve backend’in doğrudan erişimini kontrol edin. mTLS, fazla açık dinleyicileri kapatmaz veya trafik kapasitesi saldırısını tek başına durdurmaz.

Yönetim Panellerinde Aynı Güven Sınırını Kullanma

Yönetim panelleri için de sertifika kontrolü uygulama parolası, MFA ve rol yetkilerinin önüne eklenebilir. Nginx mTLS ile yönetim panelini koruma rehberi ayrı hostname ile yol koruması arasındaki farkı, ilk CRL’yi ve kontrollü kurtarma erişimini anlatır. HTTP health veya rescue rotası, bütün-host TLS doğrulamasının arkasından geçiş istisnası oluşturmaz.

Dağıtım ve Sertifika İşletimi

Sertifika envanterinde servis, ortam, issuer, seri, SHA-256 kimliği, süre ve yenileme sorumlusu bulunsun. Dağıtımı Ansible veya CI/CD ile yapmak onay ve dosya koruması gereksinimini kaldırmaz. İstemci anahtarlarını mümkünse kullanacak serviste üretin; CA’ya yalnız doğrulanmış CSR gönderin.

Bu örnekte Nginx ve Caddy elle sağlanan sunucu dosyalarını kullanır; yenileme işiniz yeni dosyaları dağıtıp hizmete yüklemelidir. Nginx’te test ve reload, Caddy’de caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile ardından caddy reload --config /etc/caddy/Caddyfile --adapter caddyfile --force kullanılabilir. Caddy reload, erişimi korunan etkin admin API ister. –force değişmeyen yapılandırmada sertifika dosyalarını yeniden yükletebilir; üretimde otomatik dosya izlemeyi varsaymayın.

Staging’de gerçek zincir yapısını ve yetki kurallarını prova edin, ancak üretim özel anahtarlarını kopyalamayın. Yeniden yükleme bir kabul testi değildir; hangi sertifikanın sunulduğunu ve eski kimliğin reddedildiğini ölçün. Bağlantı yeniden kullanımı performansı etkiler, fakat iptal süresini ve açık bağlantıları ayrıca yönetmek gerekir. Her kullanıcı için algılanamaz performans etkisi garanti edilemez.

Hata Kaynağını Bağlantı Yönüne Göre Ayırma

Önce hatanın istemci→proxy, proxy→backend veya uygulama yetkisi aşamasında olduğunu belirleyin. Güvenilen CA, hostname/SAN, sertifika kullanım amacı, süre, CRL ve izin kaydı farklı hata kaynaklarıdır. Geçerli zincirle 403 almak yetki reddi olabilir; istemcinin sunucuya güvenmemesi de mTLS’in uygulandığını kanıtlamaz.

curl ayrıntılarıyla TLS ve HTTP sonucunu ayırın; gerektiğinde openssl s_client ile doğru hostname/SNI ve CA altında bağlantıyı inceleyin. Caddy TLS belgeleri ve Nginx SSL belgeleri üzerinden kullanılan sürümün kapsamını doğrulayın. Başlık boşsa gerçek placeholder’ı ve encoding sözleşmesini kontrol edin; sunucu doğrulamasını kapatarak hatayı gizlemeyin.

Dağıtımın Tamamlanma Ölçütleri

Tamamlanmış kurulumda yetkili servis iki proxy üzerinden aynı uygulama kararını alır. Sertifikasız ve güvenilmeyen çağrılar TLS sınırında, yetkisiz ama geçerli yapraklar uygulama politikasında reddedilir. Uzak backend kullanılıyorsa gateway kimliği ve backend sunucu adı ayrı TLS bağlantısında doğrulanır. Kimlik başlıklarının doğrudan taklit edilebileceği yol kalmamalıdır.

CA, sertifika, proxy, ağ veya uygulama değişiminden sonra kabul/ret testlerini tekrarlayın. Yenileme, CRL güncelliği, uygulama izin kaydı ve uzun bağlantıların iptal davranışını birlikte izleyin. mTLS’i sürdürülebilir yapan yalnız ilk sertifika üretimi değil, bu yaşam döngüsünün doğru işletilmesidir.