Mimari ve çalışma modeli
TLS istemcisi yalnız sunucu sertifikasına bakmaz; sunucunun sunduğu yaprak ve ara sertifikaları yerel güven deposundaki bir kök sertifikaya bağlayan doğrulama yolu kurar. İmza, geçerlilik zamanı, ad eşleşmesi, Basic Constraints ve Key Usage gibi kısıtlar birlikte değerlendirilir. Sunucu kök sertifikayı göndermemeli, gerekli ara sertifikaları ise doğru sırada sunmalıdır. Tarayıcıda çalışan bir hizmetin yalın bir API istemcisinde hata vermesi, istemcilerin ara sertifika önbelleği veya güven deposunun farklı olmasından kaynaklanabilir.
Aynı IP üzerinde birden çok ad barındırıldığında SNI, TLS el sıkışmasında istenen sunucu adını taşır. SNI göndermeyen eski istemci varsayılan sanal sunucunun sertifikasını alabilir. Sertifika iptal durumu CRL veya OCSP ile denetlenir; OCSP stapling kullanıldığında sunucu imzalı durum yanıtını el sıkışmasına ekler. Stapling bulunmaması ile geçersiz ya da süresi geçmiş bir stapled yanıt aynı olay değildir.
Teşhis sırası DNS ve hedef IP doğrulamasıyla başlar; ardından SNI ile sunulan zincir, ad eşleşmesi, zaman, güven deposu ve iptal kanalı ayrı incelenir. Üretimde yalnız doğrulamayı kapatmak sorunu görünmez kılar ve kimlik sınırını kaldırır. Düzeltme; doğru sanal sunucu, tam ara zincir, kontrollü güven deposu ve ölçülen OCSP/CRL erişimi üzerinden yapılmalıdır.
- 1DNS ve hedef IP
- 2SNI ile TLS el sıkışması
- 3Zincir ve ad doğrulaması
- 4İptal durumu ve telemetri
Tasarım parametreleri
- Zincir içeriği
- Yaprak ve gerekli ara CA sertifikalarını sunun; kök CA istemcinin güven deposunda bulunmalıdır.
- Ad doğrulaması
- SAN alanı istenen FQDN'i kapsamalı; wildcard kapsamı ve IDN gösterimi ayrıca doğrulanmalıdır.
- Zaman ve yenileme
- NotBefore/NotAfter, istemci saati ve yenileme penceresi birlikte izlenmelidir.
- İptal davranışı
- Fail-open/fail-closed kararı istemciye göre değişebilir; OCSP stapling yaşı ve responder erişimi ölçülmelidir.
Hesap ve uygulama örneği
api.example.com için istemcilerin yüzde 3'ü unknown issuer hatası veriyorsa önce hata veren istemci sınıfını ayırın. Sunucu yalnız yaprak sertifikayı gönderiyor ve ara CA 1.8 KB ise zinciri eklemek el sıkışmasına küçük bir yük getirirken tüm istemcilerin ortak doğrulama yolu kurmasını sağlar. Ölçümde düzeltme öncesi/sonrası handshake_error oranını ve p95 TLS süresini karşılaştırın.
Aynı IP'de portal.example.com ve api.example.com varsa `openssl s_client` komutunu `-servername` ile ve onsuz çalıştırın. Sertifika parmak izi değişiyorsa varsayılan vhost ile SNI eşlemesini ayırmış olursunuz; DNS değiştirmeden önce yük dengeleyici dinleyici ve sertifika eşlemesini düzeltin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts -status </dev/null
openssl x509 -in leaf.pem -noout -subject -issuer -dates -ext subjectAltName
openssl verify -purpose sslserver -untrusted intermediate.pem -CAfile roots.pem leaf.pem
curl -v --resolve api.example.com:443:192.0.2.20 https://api.example.com/healthHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| unable to get local issuer certificate | Ara sertifika sunulmuyor veya istemci farklı bir güven deposu kullanıyor olabilir. | `-showcerts` çıktısındaki zinciri ve `openssl verify -CAfile` sonucunu karşılaştırın. |
| hostname mismatch | SNI yanlış, SAN kapsamı eksik veya farklı sanal sunucu yanıt veriyor olabilir. | Bağlanılan IP, `-servername` değeri ve sertifikanın SAN listesini birlikte kaydedin. |
| OCSP response expired | Stapled yanıt yenilenmemiş ya da responder erişimi kesilmiş olabilir. | OCSP yanıtının producedAt/thisUpdate/nextUpdate alanlarını ve sunucu yenileme logunu inceleyin. |
Kabul ve doğrulama kontrolleri
- Sunulan zincirde yaprak ve gerekli ara sertifikaları listeleyin.
- FQDN'i SAN alanı ve SNI sonucu ile doğrulayın.
- İstemci ve sunucuda güvenilir zaman kaynağını kontrol edin.
- En az iki farklı istemci güven deposuyla bağlantı testi yapın.
- OCSP stapling yanıtının imzasını ve zaman penceresini doğrulayın.
- Düzeltme sonrası TLS hata oranı ile p95 el sıkışma süresini karşılaştırın.
İlgili kavramlar
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.