Public/private key, sertifika, CA ve trust chain: PKI’nin gerekli temeli.

1. Core Mechanism / Temel mekanizma

PKI asimetrik key pair’e dayanır: private key signature üretir ve eşleşen public key doğrular. Normal enrollment’da requester public key’i CA’e gönderir ve private key’i korur; explicit key archival bunun ayrı yapılandırılan istisnasıdır. Certificate, public key ile identity bilgisini CA signature’ı altında bağlar. AD smart-card logon, LDAPS, IPsec ve service identity’leri bu yapıya bağlıdır; path-validation policy ile key custody birlikte önem taşır.

Arabirimler ve belirtimler

• Private key signature üretir ve normal enrollment’da requester’ın host’unda veya hardware-protected storage’ında kalır; açıkça yapılandırılan encrypted key archival istisnası olabilir.
• Public key: certificate request içinde taşınır ve sertifikada SubjectPublicKeyInfo alanında bulunur; dağıtılabilir.
• CA, DER-encoded TBSCertificate’ı imzalar; signatureAlgorithm ve signatureValue dış Certificate yapısında ayrı alanlardır.
• Issuer: issuing CA’i tanımlar; path construction issuer/subject ilişkileri ve diğer certificate bilgileriyle destekleyici sertifikaları bulur.
• Authority Key Identifier ve Subject Key Identifier: birden çok CA certificate adayı olduğunda issuer/key ilişkilerini ayırt etmeye yardım eder.
• Trust anchor verifier’ın path-validation yapılandırmasının girdisidir; yaygın olarak trusted root kullanılır, ancak başka bir CA veya peer trust ayrıca yapılandırılabilir.
• Revocation bilgisi (CRL/OCSP status) policy gerektiriyorsa ayrı kaynaktan sorgulanır; certificate kaynak konumunu işaret edebilir ama status response certificate’in içine gömülü değildir.

İki anahtar, tek yön

Asimetrik key pair’de anahtarlar birbirinin yerine geçmez. Private key ile üretilen signature eşleşen public key ile doğrulanır; yeterince güçlü bir public key’den private key’i türetmek hesaplama açısından pratik değildir.

Bu nedenle “sertifika çalındı” ifadesi çoğu zaman yanlış hedefi gösterir. Certificate dağıtılmak üzere tasarlanmış public bir belgedir. Hassas olan matching private key ve onu kullanma yetkisidir; normal enrollment’da key sahibinde kalır, açıkça yapılandırılan encrypted key archival bunun istisnası olabilir.

Sertifika ne söyler, ne söylemez

X.509 Certificate üç üst seviye alan içerir: TBSCertificate, signature algorithm ve signature value. TBSCertificate serial number, issuer, validity, subject, SubjectPublicKeyInfo ve extensions alanlarını içerir.

Certificate, public-key ve identity bilgisinin validity interval boyunca CA tarafından imzalanmış bağını kaydeder. Hesabın hâlâ aktif olduğunu, key’in ele geçirilmediğini veya identity bilgisinin güncel kaldığını tek başına göstermez. Verifier time, usage ve policy gerektiriyorsa revocation kontrollerini ayrıca uygular.

Candidate path ve trust anchor

Chain building, target certificate’den başlayıp issuer alanı/diğer bilgilerle destekleyici issuer certificate’lerini bulur ve candidate path kurar. Path validation trust-anchor bilgisini girdi alıp path’i anchor’dan target’a doğru değerlendirir; candidate path’in nasıl bulunduğu/verifier tarafından seçildiği implementation’a göre değişebilir.

Güven target certificate’in içinde yazan bir flag değildir. Windows chain engine kullandığı trust/store yapılandırmasını belirler; application custom engine veya trust policy kullanabilir. İlgili Trusted Root store’daki root yaygın bir anchor’dır, ancak açıkça yapılandırılan non-self-signed intermediate veya peer trust da kullanılabilir.

Ara CA certificate’leri path kısıtlarına bağlı olarak alt sertifikaları imzalayabilir. basicConstraints CA rolünü ve varsa path length sınırını belirtir; key-usage ve application-policy kontrolleri kullanımını ayrıca sınırlayabilir.

Zaman, revocation ve operasyonel davranış

Validity verifier’ın kullandığı saate göre değerlendirilir. Clock skew, geçerli certificate’in reddedilmesine veya yanlış yapılandırılmış verifier’ın süresi dolan certificate’i geçerli görmesine yol açabilir.

Revocation, application/profile policy gerektirdiğinde ayrıca değerlendirilir. CRL veya OCSP kaynağına erişilemediğinde verifier’ın davranışı client/application policy’sine bağlıdır: kimi reddeder, kimi soft-fail ile devam edebilir. Bu davranış protokolün sabiti değildir ve gerçek ortamda doğrulanmalıdır.

Durum ve veri akışı

1. Sahip public/private key pair üretir; private key normalde yerel veya donanım korumalı storage’da kalır.
2. Normal request public key ve istenen identity bilgisini CA’e taşır; private key archival yalnız ayrıca yapılandırılan bir istisnadır.
3. CA talebi policy’sine göre değerlendirir; onaylarsa certificate alanlarını belirler.
4. CA DER-encoded TBSCertificate’ı signing key’iyle imzalar; signature alanları TBSCertificate dışında yer alır.
5. Certificate sahibine döner. Olağan enrollment’da private key CA’e gitmez; key archival yapılandırılmışsa CA recovery için encrypted copy saklayabilir.
6. Verifier target certificate’den başlar ve candidate certification path oluşturmak için issuer certificate’lerini bulur.
7. Path validation trust-anchor bilgisini girdi alır ve anchor’dan target certificate’e doğru signature ve name/key binding’i değerlendirir.
8. Her path halkasında validity, basicConstraints/CA status, key usage ve uygulanan diğer kısıtlar verifier policy’sine göre kontrol edilir.
9. Revocation status application/profile policy gerektiriyorsa ayrıca sorgulanır; kaynağa erişilememesi durumunda client policy’si uygulanır.

2. Exploitation / İstismar

Broken trust assumption

Saldırgan açısından değerli hedef certificate dosyası değil; matching private key’e erişim, trusted CA’in signing capability’si veya verifier trust-anchor yapılandırmasını etkileme yetkisidir.

Technical prerequisites

• Saldırgan private key’e erişebilmeli veya trusted CA/trust configuration’ı etkileyebilmelidir.
• Private key materyali exportable veya okunabilir olmalı; alternatif olarak CA signing/recovery capability ya da trust configuration etkilenebilir olmalı.
• Doğrulama zincirindeki bir kontrol (path constraint, kullanım, trust-anchor governance veya policy gerektiren revocation) etkisizleştirilmiş olmalı.

Exploitation mechanism / İstismar mekanizması

Zincir doğrulaması candidate path, signature ve name/key binding, süre, CA/key-usage kısıtları, intended application purpose ve policy gerektiriyorsa revocation kontrollerini birleştirir. Risk signing key veya trust anchor compromise olduğunda, private key açığa çıktığında ya da verifier gerekli bir kontrolü atladığında oluşur. Encrypted key archive açıksa onun erişim/recovery governance’ı da key custody yüzeyidir.

Zayıf halka nerede

Certificate authentication’da tehdit modeli “signature’ı kırmak” değildir. Gerçekçi senaryolar exportable private key’in host/backup’tan okunması, açıkça yapılandırılmış encrypted key archive’ın kötü yönetilmesi veya trusted signer’ın issuance yetkisinin kötüye kullanılmasıdır.

İkinci yaygın konu trusted CA’in ne imzalayacağı üzerindeki kontroldür. Kimlerin certificate talep veya onaylayabildiği ve CA’in hangi identity alanlarını çıkardığı authorization sorularıdır; 11.02’deki template ve enrollment izinleriyle bağlantılıdır.

Doğrulamanın atlandığı yerler

Bir relying party basicConstraints/CA denetimini atlıyorsa end-entity certificate’i CA gibi kullanan uygunsuz bir path’i kabul edebilir. Benzer şekilde policy revocation check gerektiriyor fakat status kaynağına erişilemiyorken client sessizce devam ediyorsa revoked certificate kullanılabilir kalabilir.

Bu sınırlar ürün, sürüm ve application policy’ye bağlıdır; bu derste belirli istemcinin nasıl davrandığına dair kesin iddia yapılmaz. Hedef ortamda her kontrol ayrı doğrulanmalıdır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Hangi root ve ara CA'ler bu ortamda güvenilir kabul ediliyor ve bu liste kim tarafından değiştirilebiliyor?
• Private key'ler nerede üretiliyor, exportable mı ve donanım koruması var mı?
• Revocation kaynağı erişilemediğinde doğrulayan taraflar reddediyor mu, devam mı ediyor?
• Zincirdeki ara CA sertifikalarının süresi ve basicConstraints kısıtı beklendiği gibi mi?
• Sertifika doğrulama hataları merkezi olarak toplanıyor mu, yoksa yalnız istemcide mi kalıyor?

Events and relevant fields

• Certificate authentication hataları verifier/service ve client tarafında ayrı kanıtlar bırakabilir; tek taraflı kayıt sonucu açıklamayabilir.
• Path-building, signature, time, purpose, revoked ve revocation-source-unavailable sonuçları farklı failure category’leridir; birbirinden ayırın.
• Verifier’ın Trusted Root veya açıkça yapılandırılmış trust-anchor set’ine certificate eklenmesi hangi certification path’lerin kabul edilebileceğini etkileyebilir. Yalnızca chain building için CA store’a eklenen intermediate otomatik olarak trust anchor olmaz.
• CA database request kaydı ile issued certificate’i eşleştirmek requester/request ile CA’in imzaladığı Subject/SAN/public-key alanlarını incelemeye yardım eder. Bu kayıtlar private key’in host’ta veya hardware store’da nerede tutulduğunu kanıtlamaz.
• Bu derste sabit Windows Event ID iddia edilmez; event kaynağı deployed version, role ve audit policy’ye göre doğrulanmalıdır.

Neyi izlemek anlamlı

PKI telemetry’de yüksek değerli sinyal, verifier’ın trusted-root veya explicit trust-anchor set’inin değişmesidir. Intermediate CA-store additions’ı ayrı izle: chain building’i tamamlayabilir ama otomatik olarak trust anchor oluşturmaz.

İkinci kanıt CA database’deki request ve issued certificate kayıtlarıdır. Bunları eşleştirmek requester/request’i, kayıtlıysa template’i ve issued certificate’in imzalı identity/public-key alanlarını gösterir; private key’in nerede tutulduğunu tek başına açıklamaz.

Failure mesajını kök nedene çevirin

“Certificate invalid” tek bir failure state değildir. Incomplete path, invalid signature, time range dışında olma, purpose mismatch, revoked certificate ve erişilemeyen revocation source farklı sonuçlardır.

Verifier’ın specific status ve policy sonucunu koruyun. Kategoriler birleştirilirse trust/revocation sorunu clock skew veya chain-building sorunuyla karışabilir.

Detection logic · KQL

// Sentetik schema örneği: Root store eklemelerini chain building için kullanılan intermediate materyalinden ayrı sınıflandır.
// Tablo ve field adları ortama göre doğrulanmalıdır; bu sorgu çalıştırılmamıştır.
CertificateStoreChange
| where StoreName in ("Root", "CA")
| where Operation == "Add"
| extend ChangeClass = iff(StoreName == "Root", "Root-store addition", "Intermediate CA-store addition")
| summarize Count = count(), Thumbprints = make_set(Thumbprint, 20) by Computer, Actor, ChangeClass, bin(TimeGenerated, 1h)
| where Count > 0

Query assumptions

• Dataset yoktur; sorgu çalıştırılmamıştır.
• Tablo ve field adları örnektir; Windows event şemasının birebir karşılığı değildir.
• Trust store değişikliklerinin merkezi toplandığı varsayılmıştır. Root ve intermediate CA-store additions ayrı sınıflandırılır; trust-anchor sonucu chain engine/application yapılandırmasına bağlıdır.

False positives

• Planlı root veya intermediate CA rollover/deployment işlemleri.
• Yeni makinelerin ilk yapılandırmasında beklenen certificate-store doldurma adımları.
• Gerekli issuing/intermediate certificate ekleyen meşru yazılım kurulumu.

Hardening

• Offline root CA’i koruyun; trusted-root ve application-specific anchor yapılandırmasını değiştirebilecek yöneticileri sınırlayın.
• Private key üretimini uygun olduğunda hardware-protected storage’a taşı ve exportable key’leri belgelenmiş istisna yap. Encrypted CA key archive’ını ayrı roller ve denetimli recovery ile yönet.
• Root ve intermediate certificate store’larını merkezi yönet; trusted root/anchor set’ini chain-building intermediate’larından ayrı gözden geçir.
• CRL/OCSP hizmetlerini uygun erişilebilirlikte yayımlayın ve status kaynakları erişilemezken client davranışını bilinçli seçin.
• Yenileme veya deployment öncesi CA certificate’in validity, basicConstraints/path length ve key usage kısıtlarını kontrol edin.

Örnekler üzerinde oku / Read the examples

30 82 01 8c 30 82 01 56 a0 03 02 01 02 02 04 4a
1f 00 c2 30 0d 06 09 2a 86 48 86 f7 0d 01 01 0b
05 00 30 58 31 17 30 15 06 0a 09 92 26 89 93 f2
2c 64 01 19 0c 07 65 78 61 6d 70 6c 65 31 19 30
17 06 0a 09 92 26 89 93 f2 2c 64 01 19 0c 09 6f
75 74 72 65 61 73 6f 6e 31 22 30 20 06 03 55 04
03 0c 19 6f 75 74 72 65 61 73 6f 6e 2d 44 43 30
31 2d 49 53 53 55 49 4e 47 2d 43 41 30 1e 17 0d
32 36 30 31 30 31 30 30 30 30 30 30 5a 17 0d 32
37 30 31 30 31 30 30 30 30 30 30 5a 30 23 31 21
30 1f 06 03 55 04 03 0c 18 68 6f 73 74 30 31 2e
6f 75 74 72 65 61 73 6f 6e 2e 65 78 61 6d 70 6c
65 30 3c 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01
05 00 03 2b 00 30 28 02 21 00 c7 a3 1f 5b 9d 20
4e 68 a1 c3 f0 7b 55 6e 9a 4d 3b 82 f1 c6 5a d9
07 e2 4f b8 1c 3d 6e 5a 77 b1 02 03 01 00 01 a3
5d 30 5b 30 09 06 03 55 1d 13 04 02 30 00 30 0e
06 03 55 1d 0f 01 01 ff 04 04 03 02 05 a0 30 1d
06 03 55 1d 0e 04 16 04 14 3a 7f 10 c2 e4 5b 89
d1 06 6f 2b 4c 8e 3d 5a 91 7b 02 cc 41 30 1f 06
03 55 1d 23 04 18 30 16 80 14 91 b4 ce 07 25 d8
3f 6a 1e 44 08 b7 cd 52 f3 9a 6d 1e 7c 08 30 0d
06 09 2a 86 48 86 f7 0d 01 01 0b 05 00 03 21 00
5e 2d 9c 40 ab 13 7f 66 81 d4 e0 b2 c9 5a 73 f8
10 2e c6 b4 99 3a 5d 7e 2c 08 f4 1b 6a 5d 37 92

İki yanlış kanı / Two reality checks

Sanılan: Certificate gizlidir; onu alan herkes subject’i taklit edebilir.

Gerçekte: Certificate public veridir ve public key taşır. İmza üretmek matching private key veya ayrıca yetkili bir signing capability gerektirir; certificate kopyası tek başına bunları sağlamaz.

Sanılan: Certificate signature matematiksel olarak doğrulanıyorsa certificate trusted’dır.

Gerçekte: Signature doğrulaması chain/path kontrolünün yalnızca bir parçasıdır. Verifier’ın kabul ettiği path ve trust anchor, name/key binding, validity ve uygulanabilir constraints ayrıca kontrol edilir; revocation da application/profile policy gerektiriyorsa sorgulanır.

Kaynaklar / Sources

• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  Bölüm 4: Certificate ve TBSCertificate alanları; Bölüm 4.2.1.1/4.2.1.2 AKI ve SKI; Bölüm 4.2.1.9 basicConstraints; Bölüm 6 certification path validation.
• Microsoft · Public Key Infrastructure (Windows PKI) genel bakış
  Public/private key çiftleri, sertifika ve CA rolleri; Windows tarafında trust store ve zincir kavramları.
• Microsoft · Certificate chains ve certificate trust
  Chain building, trust anchor kavramı ve zincir doğrulama adımlarının genel açıklaması.
• Microsoft · Certificates and Public Keys
  A normal request carries the subject public key, not its private key; private-key roles and key-pair behavior.
• Microsoft · CERT_CHAIN_ENGINE_CONFIG
  Windows chain engines can use configured/restricted stores, exclusive trust, and an explicitly trusted non-self-signed intermediate CA.
• Microsoft · Certificate Directory
  CA database can retain requests, issued/revoked certificates, and archived keys; Trusted Root and Intermediate CA stores have distinct roles.
• Microsoft · Key Recovery Server
  Explicit key archival uses an encrypted private-key copy and KRA recovery; this is a configured exception to ordinary key custody.