Sertifika yaşam döngüsü: Özel anahtar koruması, yenileme, iptal ve kimlik güveni.

1. Core Mechanism / Temel mekanizma

11.04 KDC’nin certificate veya Key Trust yolunda hesabı nasıl eşlediğini ele aldı. Şimdi aynı kimliğin anahtar koruması, renewal ve revocation boyunca nasıl izlendiğine bakacağız.

Arabirimler ve belirtimler

• Özel anahtar: sertifikanın kimlik iddiasını taşıyabilmesini sağlayan, sertifikadan ayrı korunan sırdır. Sertifika paylaşılabilir veridir; anahtara erişim ve dışa aktarma yüzeyi ayrıca denetlenmelidir.
• Validity penceresi: sertifikanın notBefore ve notAfter alanlarıyla sınırlanan geçerlilik aralığıdır.
• Yenileme: yaklaşan süre sonunda yeni bir sertifikanın alınmasıdır; anahtarın yeniden üretilip üretilmediği ayrı bir karardır.
• CRL: CA'nın yayımladığı, iptal edilmiş sertifikaların listesini ve bir sonraki güncelleme zamanını taşıyan imzalı yapıdır.
• cRLReason: CRL entry extension'ıdır (OID 2.5.29.21) ve revocation reason'ı, örneğin keyCompromise (1), belirtir. Tek başına compromise zamanını belirtmez.
• OCSP: sertifika iptal durumunu çevrimiçi sorgulayan request/response protokolüdür. CRL'den farklı bir dağıtım biçimi değil, güncel durumu sorgulama yoludur; yanıt freshness alanlarıyla değerlendirilir.
• Invalidity Date: CRL entry içinde private key'in ele geçirildiğinin bilindiği veya şüphe edildiği ya da sertifikanın başka biçimde geçersizleştiği tarihi taşıyabilen ayrı bir extension'dır (OID 2.5.29.24); revocationDate'den daha erken olabilir.

Korunan şey sertifika değil, anahtardır

Sertifika açık bir belgedir ve paylaşılabilir. Kimlik iddiasını mümkün kılan, ona karşılık gelen özel anahtara erişimdir. Bu yüzden 'sertifika kimse tarafından görülmesin' hedefi yanlış yerde durur; asıl hedef anahtar üzerindeki erişim ve dışa aktarma yüzeyini sınırlamaktır.

Anahtarın nerede tutulduğu, kimlerin kullanabildiği ve dışa aktarılıp aktarılamadığı ele geçirilme riskini etkiler. Dışa aktarmanın kapalı olması riski azaltır ama anahtarın hiçbir yolla ele geçirilemeyeceğini kanıtlamaz. Exportable bir anahtar ise sertifika ömrü boyunca taşınabilir kimlik materyalidir.

Yenileme bir devamlılık kararıdır

Yenileme sırasında iki ayrı seçenek vardır: aynı anahtar çiftiyle devam etmek veya yeni bir anahtar üretmek. Birincisi operasyonel olarak kolaydır; ancak anahtarın maruz kalma süresini uzatır. İkincisi maruz kalma süresini keser ama ilgili her yerde yeni anahtarın tanınmasını gerektirir.

11.04'teki eşleme biçimleri bu kararı etkiler. Eşleme açık anahtara/SKI'ye bağlıysa aynı key pair eşlemeyi koruyabilir; certificate serial number'a bağlı mapping yeni sertifika için güncellenmek zorunda kalabilir. Aynı anahtarı yeniden kullanmak maruz kalma süresini uzatır; renewal planı mapping biçimiyle birlikte yapılmalıdır.

İptalin etkisi sorgulayan tarafta oluşur

CA bir sertifikayı iptal ettiğinde bilgi CRL veya OCSP yanıtı üzerinden sunulur. Relying party bu durumu sorgulamıyorsa ya da iptal öncesi yanıtı policy hâlâ güncel sayıyorsa, iptal bilgisini görmeyebilir. Sonuç uygulamanın revocation, response freshness ve ulaşılamayan responder davranışına bağlıdır; failure davranışı uygulama/policy kararıdır.

Bu yüzden iptal kararını, iptal bilgisinin doğrulayıcıda görünmesiyle aynı an sayma. CRL'in thisUpdate/nextUpdate alanları, dağıtım erişimi ve doğrulayıcının cache/freshness policy'si birlikte gözlenmelidir.

cRLReason iptalin nedenini belirtir; keyCompromise değeri tek başına kompromi zamanını vermez. RFC 5280'deki ayrı Invalidity Date extension'ı, biliniyor veya şüphe ediliyorsa anahtarın compromise tarihini ya da sertifikanın başka biçimde geçersizleştiği tarihi taşıyabilir ve CRL revocationDate'inden önce olabilir. Incident response bu tarih alanlarını da inceler.

Verilmeden kullanıma kadar ayrı kararlar

Tek bir kullanıcı sertifikasını izleyelim. Request için CA hakkı ve template Enroll koşulları, CA’nın sertifika vermesi, KDC’nin hesabı eşlemesi ve kaynak üzerindeki izin kararı ayrı aşamalardır. CA sertifika verdiği halde strong mapping reddedilebilir. Bu durumda issuance kaydı account authentication veya kaynak erişimi kanıtı değildir. 11.02–11.04 bu kontrolleri ayrı ayrı kurar.

Yenilemede yeni sertifikanın serial değeri değişsin. Issuer/serial kullanan explicit mapping’in eski serial’a bağlı kalması halinde yeni sertifika için eşleşme ayrıca kontrol edilmelidir; her mapping türünün serial’a bağlı olduğu söylenmez. İptal örneğinde CA’nın karar zamanı 10:00, verifier’ın kullandığı CRL’nin thisUpdate zamanı 09:00 olsun. nextUpdate henüz gelmemiş olması, 10:00 kararının bu CRL’de bulunduğunu göstermez. Verifier’ın hangi status verisini gerçekten değerlendirdiğini incele.

İptal edilmiş certificate, açık oturum

Certificate iptalini yeni bir PKINIT denemesiyle karşılaştır. Güncel revocation bilgisini uygulayan KDC bu certificate’ı reddedebilir. Fakat daha önce verilmiş TGT, service ticket ve kurulmuş uygulama session’ı ayrı durumlardır; CA kaydı bunları geri çağıran bir mesaj değildir. Örnekte yeni deneme ret alırken, önceden verilmiş ticket’ın süresi dolmamış ve uygulama session’ı hâlâ açık olarak ayrıca gözlenmiştir. Bu üç gözlem birbiriyle çelişmez.

MS-KILE’de account durumunun kontrolü, belirli KDC policy ve TGT yaşı koşullarına bağlıdır; certificate revocation’ını yeniden sorgulamakla aynı işlem değildir. Ticket’ın sona erme koşulunu ve uygulamanın session kapatma davranışını ortam kanıtıyla incele. Bu karşılaştırma bir Windows hot-list veya session sonlandırma işlemi çalıştırmaz.

Durum ve veri akışı

1. Anahtar çifti üretilir; özel anahtara erişim ve dışa aktarma yüzeyi kontrol edilir.
2. Sertifika talebi gönderilir ve CA, sertifikayı geçerlilik penceresiyle birlikte üretir.
3. Geçerlilik sonuna yaklaşınca renewal yapılır; aynı key pair mi yeni key pair mi kullanılacağı ve mapping'in değişip değişmeyeceği birlikte kararlaştırılır.
4. Anahtarın ele geçirildiği veya kimliğin geçersizleştiği düşünülüyorsa CA sertifikayı iptal eder ve varsa reason/date bilgilerini CRL entry'ye yazar.
5. Verifier CRL/OCSP bilgisini policy’siyle değerlendirir. Bu yeni denemenin sonucu, önceden verilmiş ticket ve açık session gözlemlerinden ayrılır.

2. Exploitation / İstismar

Broken trust assumption

Savunma ekibi, şüpheli private-key kullanımının etkisini değerlendirmektedir. Buradaki senaryolar anahtar ele geçirilmesi veya gerçek authentication sonucu kanıtı değildir.

Technical prerequisites

• Özel anahtar exportable ya da yetkisiz erişime açık bir bağlamda tutulmaktadır.
• Sertifikayı kabul eden relying party revocation kontrolü yapmamakta, iptal öncesi cache kullanmakta veya yanıt alınamadığında kabulü sürdüren bir policy izlemektedir.
• Sertifika notAfter tarihine kadar başka bir ret koşulu olmadan kabul edilebilir durumdadır.

Exploitation mechanism / İstismar mekanizması

Parola değişikliği certificate’a karşılık gelen private key’i değiştirmez. Müdahale, ilgili certificate’ın iptalini ve verifier’ın güncel status bilgisini kullanmasını doğrular. Bunun yanında daha önce kurulmuş ticket ve session yolları ayrıca incelenir; yeni certificate denemesinin reddi onların bittiğini göstermez.

Neden parola sıfırlama yetmez

Olay müdahalesinde refleks çoğu zaman parola sıfırlamaktır. Certificate tabanlı kimlikte bu adım özel key'i yenilemez ve iptal etmez; başka koşul yoksa certificate ile authentication yolu açık kalabilir.

İlgili certificate, mapping ve verifier kayıtlarını ilişkilendir. Sonra iptalden önce verilmiş ticket ve kurulmuş session olup olmadığını ayrı sor. Yalnız CA’nın iptal kaydına bakarak bütün kimlik kullanımının kapandığını söyleyemeyiz.

Bu örneğin risk sınırı

Issued, renewed ve revoked etiketlerini tek bir “erişim var/yok” alanına sıkıştırmak hatalıdır. Accepted authentication ile resource authorization da ayrı tutulur.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Authentication için kullanılan sertifikaların envanterini issuer, serial, validity window ve renewal date ile tut.
• Özel anahtarların hangi key store/hardware içinde tutulduğunu, kimlerin kullanabildiğini ve export policy'sini kaydet; exportable key'leri ayrı raporla.
• CRL thisUpdate/nextUpdate ve OCSP thisUpdate/nextUpdate alanlarını, dağıtım erişimi ve yanıt freshness ile birlikte izle.
• CA revocationDate, varsa Invalidity Date ve verifier’ın iptali gördüğü zamanı ayır. Önceki ticket sürelerini ve açık session’ların durumunu ayrıca kaydet.

Events and relevant fields

• 4768 · DC Security günlüğündeki TGT isteği. Güncel event sürümlerinde PreAuthType ve certificate alanları bulunabilir; Event ID tek başına iptal gerekçesini veya key compromise’ı göstermez.
• 5136 · Directory nesnesi değişikliği. İlgili attribute için Write audit SACL ve Audit Directory Service Changes gerekir. Mapping değişikliği certificate iptal kaydı değildir.

İptali bir olay değil, bir yayılım süreci olarak yönet

CA’da revoked görünen certificate, güncel bilgiyi almayan bir verifier tarafından hâlâ kabul edilebilir. Güncel bilgiyle yeni denemenin reddedilmesi bir doğrulama adımıdır; açık session’ların bittiğini göstermeye yetmez.

CA’nın karar zamanını, verifier’ın status bilgisini uyguladığı zamanı ve varsa uygulama session’ının kapandığı zamanı ayrı kaydet. Responder’a ulaşılamadığında davranışın ne olduğunu da doğrulayıcının policy’sinden öğren.

Değişiklik sonrası doğrulama

Sertifikayı issuer/serial ve gerekirse ilgili key identity ile takip et; request, mapping ve verifier gözlemlerini kendi üreticilerine bağla. CRL/OCSP erişimi, güncelliği ve policy sonucunu ölçmeden yalnız CA iptal kaydıyla kapanış yapma.

Detection logic · XPath

*[System[(EventID=4768)]]

Query assumptions

• Sorgu domain controller üzerindeki Security günlüğünde çalıştırılmak üzere yazılmıştır ve 4768 olaylarını seçer; tek başına PKINIT veya iptal nedeni filtresi değildir.
• Certificate alanları ve failure gösterimi OS/event sürümüne bağlıdır. PreAuthType, certificate alanları, sonuç kodu ve ilgili KDC mesajını birlikte oku; bu olayda bulunmayan bir revocation reason alanı varsayma.
• Bu derste parser doğrulaması yapılan artifact yalnız CRL reason-code extension'ıdır; complete CRL veya KDC event schema'sı değildir.

False positives

• 4768 kayıtları rutin Kerberos authentication trafiğinde yoğun üretilir; tek başına iptal veya key compromise göstergesi değildir.
• İlgili kaydın yokluğu iptal edilmiş sertifikanın hiçbir yerde kabul edilmediğini kanıtlamaz; başka bir verifier revocation sorgulamıyor olabilir veya event schema'sı farklı olabilir.

Hardening

• Özel anahtarlara erişimi sınırla; key store, hardware protection ve export policy'yi tanımla. Dışa aktarmayı yalnız gerekçeli istisnalara aç.
• Yenilemede anahtarın da yenilenip yenilenmeyeceğini politika olarak belirle ve eşleme biçimiyle birlikte planla.
• Revocation status kontrolünü relying party policy'sinde belirle; responder/CRL erişilemediğinde fail-open davranışını varsayılan hale getirme. CRL/OCSP freshness ve güncelleme süresini ölç.
• Key compromise şüphesinde yeni certificate kullanımının ret sonucunu ve eski ticket/session durumlarını ayrı doğrula. Session kapanışını gösteren uygulama kanıtını CA kaydının yerine koyma.

Örnekler üzerinde oku / Read the examples

30 0a 06 03 55 1d 15 04 03 0a 01 01

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E03",
  "certificate": "toy-cert-B",
  "issued": true,
  "keyEpoch": "same",
  "serialEpoch": "new",
  "mappingType": "issuer-serial",
  "mappingMatch": false,
  "verifierCRL": "dated-snapshot",
  "resourceAccess": "not-reached"
}

İki yanlış kanı / Two reality checks

Sanılan: CA bir sertifikayı iptal ettiyse her relying party aynı anda reddeder.

Gerçekte: İptal, relying party'nin güncel CRL/OCSP durumunu sorgulamasına ve freshness/failure policy'sine bağlıdır; CA'daki kayıt her cache'i anında güncellemez.

Sanılan: cRLReason, compromise'ın tam olarak ne zaman olduğunu söyler.

Gerçekte: cRLReason neden kodudur. RFC 5280 Invalidity Date extension'ı, biliniyor veya şüphe ediliyorsa private key'in compromise zamanını ya da sertifikanın başka şekilde geçersizleştiği tarihi taşıyabilir; bu tarih revocationDate'den önce olabilir.

Kaynaklar / Sources

• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  Validity alanları; CRL profili ve CRL entry extensions; §5.3.1 cRLReason (id-ce-cRLReasons, 2.5.29.21) ve keyCompromise değeri.
• IETF · RFC 6960 (X.509 Internet PKI Online Certificate Status Protocol — OCSP)
  Sertifika iptal durumunun çevrimiçi sorgulanması; yanıt durumları ve güncellik alanları.
• Microsoft Open Specifications · [MS-WCCE]: Windows Client Certificate Enrollment Protocol
  İstemci ile CA arasındaki enrollment ve yenileme taleplerinin protokol kapsamı.
• Microsoft · certutil
  Sertifika ve CRL doğrulama işlemlerine ilişkin komut referansı.
• Microsoft · Event 4768: A Kerberos authentication ticket (TGT) was requested
  Updated event versions include PreAuthType and certificate fields; the event ID alone does not identify the authentication method or revocation reason.
• NDES service account / CA permission
  Set up request permission on the CA; SPN alias conditions
• MS-WCCE template permissions
  §1.3.3.4 Permissions on Templates
• KB5014754 certificate mapping
  Timeline; strong/weak mapping; KDC event guidance; Schannel distinction
• RFC 5280 — CRL profile
  §5.1.2.4–5.1.2.6 thisUpdate/nextUpdate/revokedCertificates
• RFC4120 · Kerberos ticket lifecycle
  §1.1 and §3.3.3.1; ticket lifetime and TGS/hot-list scope; not a Windows control recipe.
• MS-KILE · Check Account Policy for Every Session Ticket Request
  §3.3.5.7.1; conditional account-standing validation is not certificate-status checking.
• Microsoft · Event5136
  Matching attribute Write SACL and Audit Directory Service Changes; modification is not certificate revocation.
• Microsoft · Audit Directory Service Changes
  DC-only directory change auditing; matching object SACL.