Yönetim Panelinde mTLS Ne Sağlar?
Yönetim panelinin giriş formuna ulaşmadan önce istemci kimliği doğrulamak, anonim giriş denemelerini uygulamadan uzak tutabilir. Karşılıklı TLS (mTLS), istemcinin sertifikasını ve ona ait özel anahtara sahip olduğunu TLS bağlantısında doğrular. Bu rehber, Nginx önündeki bir yönetim uygulaması için CA oluşturma, sertifika dağıtımı, erişim kontrolü ve iptal sürecini birlikte ele alır.
Normal HTTPS’te istemci sunucunun kimliğini doğrular. mTLS’te sunucu da istemci sertifikasını kabul ettiği CA ve kurallara göre denetler. Geçerli bir sertifika, uygulamada her işlemi yapma yetkisi anlamına gelmez; kullanıcı oturumu, rol kontrolü ve gerekiyorsa MFA korunmalıdır. Sertifikanın veya anahtarın paylaşılması da kişi bazındaki izlenebilirliği bozar.
Örnekler güncel OpenSSL 3.x ve TLS modüllü Nginx kullanan Linux laboratuvarı içindir. İki dilde aynı dosya adları ve aynı CA/CRL akışı kullanılır. Komutlardaki alan adları, sertifika yolları ve 127.0.0.1:8080 uygulaması örnektir. Üretimden önce gerçek dinleyicilerinizi, ters proxy sınırını ve yönetim rotalarını belirleyin.
İstemci Doğrulaması ve Uygulama Yetkisi
Nginx yönetim uygulamasına giden bütün yolları denetliyorsa sertifikasız veya güvenilmeyen istemciyi uygulamaya ulaşmadan reddedebilir. Ağdaki sunucu ve TLS dinleyicisi yine erişilebilir olabilir; mTLS tek başına trafik saldırısını önleyen veya sunucuyu görünmez yapan bir mekanizma değildir. IP/VPN kısıtlaması, kapasite koruması ve uygulama kimliği ayrı kontrollerdir.
İşletim maliyeti sertifika üretimiyle bitmez: hangi kişi ve cihazın hangi seri numarasını kullandığını kaydetmek, özel anahtarı korumak, süreyi izlemek ve kayıp cihazda erişimi sonlandırmak gerekir. Her cihaz için ayrı anahtar ve sertifika, tek paketi bütün ekiple paylaşmaya göre daha belirgin bir iptal sınırı sağlar.
Önce yönetim alanını ayrı bir hostname üzerinde korumayı değerlendirin. Aynı hostname altında yalnız bazı yollar korunacaksa sertifika talebi yine TLS aşamasında yapılır; HTTP yolu daha sonra değerlendirilir. Bu ayrım tarayıcı davranışını ve Nginx direktiflerinin yerini belirler. Aşağıda iki model de gösterilir.
OpenSSL ile İstemci CA’sı ve Sertifika Üretme
CA Tasarımı ve Anahtar Sorumluluğu
OpenSSL ile küçük bir CA kurmak mekanizmayı öğrenmek ve sınırlı bir dağıtımı yönetmek için uygundur. Üretimde sertifika talebinin kim tarafından onaylandığı, anahtarın nerede üretildiği, yedeklerin kimde olduğu ve iptal listesinin nasıl dağıtıldığı tanımlanmalıdır. Düzenli kayıt ve denetim gerektiren ekiplerde yönetilen bir iç PKI daha uygun olabilir.
Bu laboratuvarın CA’sı yalnız istemci sertifikaları içindir. CA özel anahtarı şifrelenir ve Nginx’e kopyalanmaz. Nginx’in HTTPS sunucu sertifikası ayrı bir güven ilişkisidir. Uzun süreli kök CA örneğini üretim tasarımı olarak kabul etmeyin; çevrimdışı kök ve ara CA gerekiyorsa zincir, CRL ve doğrulama derinliği de ayrıca tasarlanmalıdır.
Yalıtılmış Çalışma Dizini ve Kök CA
set -eu
umask 077
mtls_dir="$HOME/mtls-ca-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 = Admin Client 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
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
mkdir var olan dizinde durur; eski CA veritabanını sıfırlamamak için bu korumayı kaldırmayın. Sonraki CA komutlarını aynı mtls-ca-lab dizininde çalıştırın: OpenSSL’de dir = . mevcut çalışma dizinini kullanır. pathlen:0 bu kökten ara CA üretimini sınırlar. index.txt, seri dosyaları ve CA anahtarını tutarlı biçimde yedekleyin. Anahtar parolası terminalde sorulur.
İstemci Sertifikası ve İlk CRL
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private/alex.key.pem
openssl req -new -key private/alex.key.pem -subj "/CN=Alex Admin" -out alex.csr.pem
openssl ca -config openssl.cnf -extensions client_cert -days 90 -notext -in alex.csr.pem -out certs/alex.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/alex.cert.pem
openssl x509 -in certs/alex.cert.pem -noout -serial -dates
openssl ca verilen sertifikayı veritabanına kaydeder; sonraki iptal işlemi bu kayda dayanır. İmzalamadan önce talebi ve kişiyi doğrulayın; komut onay ve CA parolası isteyebilir. İlk sertifikanın seri numarası bu yeni laboratuvarda 1000 olur. clientAuth profili istemci kullanımını, copy_extensions = none ise CSR uzantılarının denetimsiz kopyalanmamasını sağlar. İlk boş CRL de burada üretilir; Nginx ayarından önce hazırdır.
openssl pkcs12 -export -inkey private/alex.key.pem -in certs/alex.cert.pem -certfile certs/ca.cert.pem -out alex.p12
PKCS#12 dosyası özel anahtarı da içerir; dışa aktarırken güçlü bir parola belirleyin. Paketi yetkisi sınırlı ve süresi kısıtlı güvenli aktarım yöntemiyle, parolayı ayrı doğrulanmış kanalla iletin. Bu örnekte istemci anahtarı CA çalışma dizininde üretilir; üretimde mümkünse cihaz üzerinde üretin ve CSR’yi CA’ya gönderin. Yalnız gerekli anahtar kopyalarını tutun.
Nginx’te Yönetim Erişimini Koruma
Önce Güven Dosyalarını Hazırlama
ssl_verify_client yalnız http veya server kapsamında kullanılabilir; location içine konamaz. Ayrı yönetim hostname’inde on bütün host için doğrulamayı zorunlu kılar. Aynı hostta yol koruması için optional istemciden TLS sırasında sertifika ister, sonra korunan location’lar SUCCESS sonucunu zorunlu tutar.
Nginx sunucusuna yalnız açık CA sertifikasını ve CRL’yi güvenli biçimde aktarın. Aşağıdaki kurulum komutları bu iki dosyanın bulunduğu dizinden, amaçlanan Nginx sunucusunda çalıştırılır; CA farklı makinedeyse önce bu açık dosyaları taşıyın. CA özel anahtarını taşımayın. Gerçek sunucu sertifikasının hostname ile eşleştiğini ve uygulamanın yalnız güvenilen proxy üzerinden erişildiğini doğrulayın.
sudo install -d -m 0755 /etc/nginx/client_ca
sudo install -m 0644 certs/ca.cert.pem /etc/nginx/client_ca/ca.cert.pem
sudo install -m 0644 crl/ca.crl.pem /etc/nginx/client_ca/ca.crl.pem
# Inside the existing http {} block:
log_format mtls '$remote_addr [$time_local] "$request" $status '
'verify="$ssl_client_verify" serial="$ssl_client_serial"';
# Inside the existing http {} block, after log_format:
server {
listen 443 ssl;
server_name admin.example.com;
ssl_certificate /etc/ssl/certs/admin-server-fullchain.pem;
ssl_certificate_key /etc/ssl/private/admin-server.key;
ssl_client_certificate /etc/nginx/client_ca/ca.cert.pem;
ssl_verify_depth 1;
ssl_crl /etc/nginx/client_ca/ca.crl.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache off;
ssl_session_tickets off;
access_log /var/log/nginx/admin_access.log mtls;
ssl_verify_client on;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-Serial $ssl_client_serial;
}
}
Bu bloklar mevcut http {} içine eklenir; log_format server dışında kalır. Örnek doğrudan kökten imzalanan istemci için derinlik 1 kullanır. Yeni bağlantı testlerini açık tutmak için oturum önbelleği ve biletleri kapalıdır; üretimde yeniden kullanımı açacaksanız iptal etkisini ayrıca değerlendirin. Aynı hostname’te yol koruması gerekiyorsa, yukarıdaki server yerine aşağıdaki modeli kullanın. Sunucu sertifikası bu kez example.com için olmalıdır.
# Alternative to the dedicated host; inside existing http {}:
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/public-server-fullchain.pem;
ssl_certificate_key /etc/ssl/private/public-server.key;
ssl_client_certificate /etc/nginx/client_ca/ca.cert.pem;
ssl_verify_depth 1;
ssl_crl /etc/nginx/client_ca/ca.crl.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache off;
ssl_session_tickets off;
access_log /var/log/nginx/admin_access.log mtls;
ssl_verify_client optional;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-Serial $ssl_client_serial;
}
location = /admin {
if ($ssl_client_verify != SUCCESS) { return 403; }
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-Serial $ssl_client_serial;
}
location ^~ /admin/ {
if ($ssl_client_verify != SUCCESS) { return 403; }
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-Serial $ssl_client_serial;
}
}
= /admin tam yolu, ^~ /admin/ alt yolları korur. Uygulamanızın diğer yönetim API’lerini, giriş rotalarını, yeniden yazmalarını ve alternatif erişimlerini ayrıca kapsayın. Bu iki yol bütün uygulamalar için yeterli değildir. Public ziyaretçi sertifika seçme istemi görebilir; sunduğu geçersiz sertifika public isteğin de reddedilmesine yol açabilir.
Eksik veya Geçersiz Sertifikayı Reddetme
Nginx’in 495 ve 496 dahili durumları istemci doğrulama hatası ve gerekli sertifikanın yokluğu içindir. Bunları anlaşılır bir 403 yanıtına çevirebilirsiniz. Her TLS başarısızlığı HTTP yanıtına ulaşmaz; istemci, TLS sürümü ve hata aşamasına göre görülen sonuç değişebilir. Hata sayfası doğrulamayı devre dışı bırakan bir geçiş yolu olmamalıdır.
# Optional: inside the protected server {} block:
error_page 495 496 = @mtls_required;
location @mtls_required {
return 403 "A valid client certificate is required.\n";
}
Bu isteğe bağlı adlandırılmış hata location’ı uygulamaya proxy yapmaz; yalnız ret metni döndürür. Yol modelindeki if kontrolü zaten 403 üretir. Kabul ölçütü tek bir hata kodu değil, yetkisiz isteğin uygulamaya ulaşmaması ve günlükte doğru ret nedeninin görülmesidir.
Sertifika Seri Numarasıyla İzin Listesi
CA’nın verdiği her istemci sertifikasının bu panele girmesi gerekmeyebilir. Aşağıdaki ek kontrol, bu tek ve ayrı CA altında başarıyla doğrulanan belirli seri numarasını kabul eder. CN içinde “Admin” geçen herkesi kabul eden ifade veya metin biçimi belirsiz bir DN karşılaştırması kullanmaz. Önce sertifikadaki gerçek seri numarasını okuyun.
# Inside the existing http {} block, for this dedicated CA only:
map "$ssl_client_verify:$ssl_client_serial" $mtls_admin {
default 0;
"SUCCESS:1000" 1;
}
# Add inside each protected location, before proxy_pass:
# if ($mtls_admin = 0) { return 403; }
map mevcut http kapsamına bir kez eklenir; yorumdaki if satırını her korunan location’da etkinleştirmek gerekir. 1000 yalnız bu laboratuvarın ilk sertifikasıdır. Yenileme yeni seri üretir; izin listesini kontrollü güncelleyin. Birden fazla CA’ya güveniyorsanız seri tek başına eşsiz değildir: doğrulanmış issuer ve seri birlikte değerlendirilmelidir. Genişleyen rol yönetimini uygulama veya yetkilendirme servisine taşıyın.
Sertifika İptali ve CRL Dağıtımı
Kayıp özel anahtar örneğinde ilgili sertifikayı CA veritabanında iptal edin ve yeni CRL üretin. Aşağıdaki keyCompromise nedeni bu olay içindir; başka olayda uygun nedeni seçin. CA komutları CA makinesinde, dağıtım komutları açık CRL dosyası güvenli aktarılmış Nginx makinesinde çalışır. Nginx’in CA anahtarına ihtiyacı yoktur.
cd "$HOME/mtls-ca-lab"
openssl ca -config openssl.cnf -revoke certs/alex.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
sudo install -m 0644 crl/ca.crl.pem /etc/nginx/client_ca/ca.crl.pem.new
sudo mv /etc/nginx/client_ca/ca.crl.pem.new /etc/nginx/client_ca/ca.crl.pem
sudo nginx -t && sudo systemctl reload nginx
CRL’nin nextUpdate süresinden önce yeni liste üretip dağıtın; hiç iptal yoksa da yenileme gerekir. Bu örnekte süre 7 gündür, dolayısıyla dağıtım daha erken ve izlenen bir takvimle yapılmalıdır. Yeni dosya, başarılı yapılandırma testi ve yeniden yükleme sonrasında yeni TLS bağlantısıyla kontrol edilir. Mevcut bağlantılar, oturum yeniden kullanımı ve uygulama oturumları için ayrıca sonlandırma politikası gerekir; CRL güncellemesi hepsini anında kapatmaz.
Nginx SSL modülü belgeleri güven dosyaları, doğrulama derinliği ve CRL direktiflerini açıklar. Ara CA kullanıldığında zincirde gereken CRL’leri de sağlamanız gerekir. Laboratuvarın doğrudan kök→istemci düzeninden daha karmaşık bir zincire geçerken yalnız derinlik sayısını değiştirmekle yetinmeyin.
Tarayıcı ve Cihazlara Sertifika Dağıtımı
PKCS#12 Paketini Kişisel Sertifika Olarak Yükleme
alex.p12 dosyasını işletim sisteminin veya tarayıcının kişisel istemci sertifikası deposuna aktarın. Paket sertifikayı ve ona ait özel anahtarı birlikte içermelidir. İstemci sertifikası kurmak için bu CA’ya bütün web sitelerinin sunucu kimliklerini doğrulama yetkisi vermek gerekmez. Nginx’in sunucu sertifikasına güven ve Nginx’in istemci CA’sına güven ayrı yönlerdir; tarayıcı ayarlarını bu ayrımla yapın.
Cihaz Değişimi ve Kayıp Anahtarlar
Yeni cihazda tercihen yeni anahtar ve sertifika üretin; aynı p12’nin cihazlar arasında çoğalması hangi kopyanın kaybolduğunu ayırmayı zorlaştırır. Kullanıcı/cihaz, seri numarası, süre ve teslim kaydı tutun. Yönetilen cihazlarda kurulum ve silme işlemlerini kurumun cihaz yönetimiyle uygulayın. Dosyayı veya parolayı herkesin görebildiği bir paylaşım alanına bırakmayın.
Sertifika Seçimini ve TLS Ucunu Kontrol Etme
Önce bağlantının hangi TLS ucunda sonlandığını, server kapsamındaki doğrulamayı ve CA listesini kontrol edin. Sonra doğru tarayıcı profilinde sertifika ve özel anahtarın birlikte bulunduğunu, sertifikanın süresini ve clientAuth kullanımını inceleyin. Tarayıcı otomatik seçim yapabilir; seçim penceresi görmemek doğrulamanın çalışmadığını tek başına göstermez. Testi yeni bağlantıyla ve Nginx günlüğüyle doğrulayın.
curl ve Nginx Günlükleriyle Doğrulama
Kabul ve Ret Durumlarını Ayrı Test Etme
Komutları istemci sertifikası dosyalarının bulunduğu dizinden, gerçek hostname ile çalıştırın. Alex’in kabul testini iptal adımından önce, aynı dosyayla ret testini iptal ve CRL dağıtımından sonra yapın. Sertifikasız istek korunan uygulamaya ulaşmamalıdır. Geçerli sertifika sonrasında uygulama giriş yanıtı veya yönlendirme döndürebilir; her başarı 200 değildir. Güvenilmeyen sertifikayı, public rotayı, tam /admin ve alt yolları da ayrı kontrol edin.
curl -i https://admin.example.com/
curl -i --cert certs/alex.cert.pem --key private/alex.key.pem https://admin.example.com/
curl -i --cert-type P12 --cert alex.p12 https://admin.example.com/
PKCS#12 örneği bu dosya türünü destekleyen curl TLS arka ucu içindir; parola terminalde sorulur ve komut satırına yazılmaz. Schannel kullanan Windows curl sürümlerinde sertifika deposu biçimi gerekebilir. curl TLS sertifika doğrulaması rehberi sunucunun güvenini açıklar. Özel sunucu CA’sı gerekiyorsa uygun --cacert kullanın; istemci testi için -k ile sunucu doğrulamasını kapatmayın.
Doğrulama Sonucunu ve Seri Numarasını Kaydetme
Günlükte doğrulama sonucu ve sertifika seri numarası kimlik envanteriyle ilişkilendirilebilir. Bu, sertifikanın hangi hesaba verildiğini gösterir; cihaz başındaki kişiyi tek başına kanıtlamaz. Anahtarı paylaşan kişiler aynı kimlikle görünebilir. Günlük erişimini, saklama süresini ve kişisel veri kapsamını sınırlayın.
# Inside the existing http {} block:
log_format mtls '$remote_addr [$time_local] "$request" $status '
'verify="$ssl_client_verify" serial="$ssl_client_serial"';
# Inside the relevant server {} block:
access_log /var/log/nginx/admin_access.log mtls;
Bu log_format önceki örnekte zaten varsa ikinci kez tanımlamayın. VPS günlüklerini merkezi toplama rehberi merkezi izleme tasarımına yardımcı olur. Doğrulama hatası, süre bitimine yaklaşan sertifika ve CRL dağıtım hatasını ayrı takip edin. Log toplama aracının güncel destek durumunu değerlendirin; özel anahtar veya p12 içeriği günlüğe yazılmamalıdır.
mTLS’i Uygulama Kontrolleriyle Birlikte Kullanma
Uygulama parolası, MFA ve rol kontrollerini sürdürün. Gerekirse yönetim erişimini VPN/IP kurallarıyla daraltın. Nginx rate limiting ve Fail2ban rehberi uygulamaya veya giriş noktasına yönelik ek kontrolleri ele alır. satisfy any belirli HTTP erişim modüllerini birleştirir; zorunlu TLS istemci doğrulamasını genel olarak atlatan bir ayar değildir.
DV, OV, EV ve wildcard SSL rehberi ağırlıkla sunucu sertifikası seçimini anlatır. Bu yönetim istemcisi örneğinde ayrı iç CA ve clientAuth profili kullanılır. Sunucu sertifikasının marka veya doğrulama türü, istemcinin uygulamadaki rolünü belirlemez.
WordPress güvenlik sertleştirme kontrol listesi uygulama içi yetkiler, dosya erişimi ve bakım için tamamlayıcıdır. WordPress veya başka CMS’de yalnız bir /admin yolu varsaymayın: gerçek giriş dosyaları, yönetim alanı, API ve entegrasyon rotalarını belirleyin. Bir rotayı kısıtlarken gerekli public işlevleri de test edin.
Dağıtım, Yenileme ve İptal Süreçleri
Süreleri ve Yetkileri Envanterleme
Bu örnekte istemci ömrü 90 gündür; uygun süre risk ve yenileme kapasitesine göre seçilir. Sertifikayı bitmeden yenileyin, yeni seri numarasını yetki kayıtlarına ekleyin, yeni bağlantıyla doğrulayın ve eski yetkiyi planlı kaldırın. Kullanıcının ayrılması veya anahtarın kaybı halinde süre sonunu beklemeyin.
CA Hizmetine Geçiş ve Otomasyon
step-ca belgeleri kayıt ve kısa ömürlü sertifika otomasyonu için başlangıç noktasıdır. step-ca’nın varsayılan pasif iptali yenilemeyi engeller; mevcut sertifika sona erene kadar geçerli kalır. Aktif iptal ve Nginx’in kullanacağı CRL dağıtımı ayrıca desteklenen biçimde kurulmalıdır. Genel CA hizmeti kurulumu, bu yazıdaki dosya tabanlı iptal akışını kendiliğinden sağlamaz.
Kayıp Cihaz veya Anahtar Sızıntısına Müdahale
Olayda ilgili seri numarasının yetkisini kaldırın, CA iptalini ve CRL dağıtımını tamamlayın, açık uygulama oturumlarını ve bağlantıları değerlendirin. Nginx’in zarif yeniden yüklemesi mevcut bağlantıları anında kesme garantisi vermez. Yeni cihaz için yeni anahtar üretin. Aynı özel anahtarı içeren p12’ye yeni parola koymak, daha önce kopyalanmış anahtarı geçersiz kılmaz.
Erişim Kaybına Karşı Kontrollü Kurtarma
Doğrulama kuralını açmadan önce ayrı denetlenen SSH, sağlayıcı konsolu veya yönetim VPN’i üzerinden kurtarma erişimini doğrulayın. Bütün hostta zorunlu TLS doğrulaması varken /rescue-admin içinde bunu kapatmak çalışmaz; yol TLS aşamasından sonra bilinir. Herkese açık alternatif yönetim yolu eklemek yerine yapılandırmayı bu ayrı yönetim kanalıyla düzeltin.
sudo nginx -t && sudo systemctl reload nginx
Önce staging hostname’inde geçerli, eksik, güvenilmeyen ve iptal edilmiş sertifikaları test edin. CA, CRL, sunucu sertifikası ve uygulama yönlendirmesinin hepsi doğru olmalıdır. Ardından kontrollü üretim dağıtımı yapın ve aynı testleri tekrarlayın. Sisteminiz Nginx’i farklı servis adıyla yönetiyorsa yeniden yükleme komutunu buna uyarlayın.
Proxy ve CDN Arkasında Doğrulama Sınırı
CDN veya yük dengeleyici TLS’i sonlandırıyorsa son kullanıcının mTLS bağlantısı orada biter. Origin’in gördüğü yeni TLS istemcisi proxy’dir; bu ikinci bağlantı kullanıcı sertifikasını kendiliğinden taşımaz. Edge’de doğrulanmış kimliğin güvenilir aktarımı ve ayrıca doğrulanmış edge→origin bağlantısı gerekir. Gerçek TLS geçişi kullanılıyorsa doğrulama origin’de yapılabilir; aradaki cihazın TLS’i sonlandırmadığını doğrulayın.
Örnek Nginx, X-Client-Verify ve X-Client-Serial değerlerini gelen istemci başlıklarını kabul etmek yerine kendi doğruladığı değerlerle yazar. Backend bu başlıkları yalnız güvenilen proxy bağlantısından kabul etmeli ve doğrudan dışarıya açık olmamalıdır. Host veya herhangi bir kimlik başlığı tek başına güven kanıtı değildir. Uygulama seri numarasını kontrollü kimlik/rol kaydına bağlamalıdır.
TLS, Dosya İzinleri ve Güncelleme Politikası
Güncel TLS sürümleri, sınırlı özel anahtar izinleri ve desteklenen yazılım sürümleri kullanın. HSTS HTTPS kullanımını zorlar, istemci yetkisi oluşturmaz. Aşamalı sürelerle devreye alın; includeSubDomains ve preload seçimini bütün alt alan adlarının HTTPS durumunu inceleyerek yapın. Bu politikaların geri alınması tarayıcı önbellekleri nedeniyle hemen etkili olmayabilir.
Rate limiting ve Fail2ban yaklaşımı ek trafik ve giriş denemesi kontrolleri sağlar. Limitleri doğru istemci adresi ve proxy güven sınırıyla tasarlayın; bütün kullanıcıları tek CDN IP’si gibi görmek hatalı engellemelere yol açabilir. mTLS kontrolünden geçen kullanıcıların da uygulama sınırlarına uyması gerekir.
Staging Ortamında Dağıtım Provası
Staging’de ayrı anahtarlar ve gerekirse ayrı CA güveni kullanın. Üretim CA’sını deneme amaçlı her ortama yaymayın. Kurulum belgesinde dosya teslimi, tarayıcı profili, sertifika seçimi, yenileme ve kayıp cihaz bildirimi bulunmalıdır. Otomasyonun sadece sertifika ürettiğini değil, doğru cihaza ve doğru yetkiyle dağıttığını da kontrol edin.
Proxy ve uygulama günlüklerini güvenli bir istek kimliğiyle ilişkilendirin. Test, isteğin hangi listener’dan girdiğini, hangi sertifikayla doğrulandığını ve hangi uygulama kararını aldığını gösterebilmelidir. WebSocket gibi uzun bağlantılarda kimlik ilk TLS bağlantısında doğrulanır; sonraki iptal açık bağlantıyı otomatik yeniden doğrulamaz. Uzun bağlantıların kapanma politikasını belirleyin.
Sık Görülen Yapılandırma Hataları
Yaygın hatalar ssl_verify_client’i location içine koymak, log_format’ı server içine yazmak, ilk CRL’yi oluşturmadan ssl_crl tanımlamak ve yalnız /admin/ yolunu korumaktır. İstemci paketi için CA’ya bütün web sunucularını doğrulama güveni vermek de gerekli değildir. Sertifika zincirini, süreyi, clientAuth kullanımını, gerçek seri numarasını ve çalışır kurtarma kanalını ayrı ayrı kontrol edin.
WordPress güvenlik sertleştirme rehberi gibi uygulamaya özgü kontrolleri mTLS ile birlikte değerlendirin. Sertifika sahibi kullanıcının erişim düzeyi, dosya yükleme yetkisi veya eklenti açığı TLS tarafından düzeltilmez. Geçerli sertifika ile yapılan bir isteğin uygulama tarafından hâlâ reddedilmesi doğru davranış olabilir.
Kısa Ömürlü Sertifikalar ve Yetkilendirme
Kısa ömürlü sertifika, kullanılabilecek geçerlilik penceresini küçültür; acil iptal gereksinimini ortadan kaldırmaz. Yenileme servisi kimlik ve cihaz yetkisini yeniden denetlemeli, ayrılan veya kaybolan cihazın yenilemesini durdurmalıdır. Etkin sertifika ve açık bağlantılar için kalan risk süresini ölçün. “Birkaç gün sonra biter” yaklaşımı hassas yönetim erişiminde yeterli olmayabilir.
Rol kararları doğrulanmış ve CA tarafından kontrollü biçimde atanmış kimliğe dayanmalıdır. CN’deki herhangi bir sözcüğü yönetici rolüne çevirmeyin. Bu örnekte tek issuer altındaki seri numarası envantere bağlanır; çok issuer veya ayrıntılı rol modeli için doğrulanmış kimliği alan yetkilendirme servisi kullanılabilir. Proxy’den gelen bilgi, uygulamanın bütün erişim kontrollerini kaldırma gerekçesi değildir.
Laboratuvardan Üretime Geçiş Ölçütleri
Üretime geçmeden önce istemci CA’sı, kayıt veritabanı, ilk CRL, geçerli sunucu sertifikası ve kontrollü backend hazır olmalıdır. Sertifikayı dağıtın, doğru Nginx kapsamını seçin, izin politikasını ve bütün yönetim rotalarını doğrulayın. Kabul/ret testlerinden sonra yenileme, CRL süre takibi, kayıp cihaz müdahalesi ve bağımsız kurtarma sorumlularını belirleyin.
Node.js’i Nginx ve TLS ile yayımlama rehberi backend servisinin yönetimi için tamamlayıcıdır. Backend başka makinedeyse yalnız loopback varsayımı geçerli olmaz; ağ sınırını ve proxy→backend kimlik doğrulamasını ayrıca tasarlayın. Buradaki yerel 8080 örneğini erişime açık bir upstream adresiyle denetimsiz değiştirmeyin.
İşletim ve Periyodik Kontrol
Başarılı dağıtımda geçerli ve yetkili istemci beklenen uygulama akışına ulaşır; sertifikasız, güvenilmeyen, iptal edilmiş veya izin listesi dışındaki istemci korunan uygulamaya ulaşamaz. Aynı hostta public yolların amaçlanan davranışı da sürmelidir. Bir başarılı tarayıcı denemesi bu sonuçların tümünü kanıtlamaz.
DNS, proxy, sertifika, Nginx veya uygulama rotası değiştiğinde kabul ve ret testlerini tekrarlayın. Yeni sertifika kullanılırken eski seri numarasının hâlâ yetkili kalıp kalmadığını, CRL’nin süresini ve bütün origin dinleyicilerini izleyin. Acil iptal planını yalnız yeni bağlantılar için değil, mevcut kullanıcı ve uygulama oturumları için de prova edin.
mTLS’in değeri doğru güven sınırı ve sürdürülebilir yaşam döngüsüyle ortaya çıkar. Sertifika kimliği, uygulama yetkisi, iptal ve kurtarma sorumlulukları birlikte belgelendiğinde yönetim erişimi ölçülebilir biçimde kontrol edilebilir. Laboratuvar örneğini kendi altyapınızın bütün yollarıyla doğrulayarak uyarlayın.
