Enterprise CA ve certificate templates: Subject, SAN, EKU ve kullanım amacı.

1. Core Mechanism / Temel mekanizma

Standalone CA talepleri template kullanmadan kendi issuance policy’sine göre değerlendirir; Enterprise CA ise AD DS’de tutulan ve ilgili CA üzerinde yayımlanan certificate template’lere göre çalışır. Template certificate alanlarını, kullanımları, key kurallarını ve talep edebilecek principal’ları belirler. Bu nedenle “CA ne imzalar?” sorusu template tanımı ve enrollment izinleriyle birlikte yanıtlanır. Certificate issuance, hedef protokolün bu certificate’i bir hesaba map edip authentication’da kabul edeceğini tek başına göstermez.

Arabirimler ve belirtimler

• Certificate template, AD DS'de tutulan bir directory nesnesidir; Enterprise CA template'i kullanabilmek için onu kendi published listesinde bulundurmalıdır.
• Template, Subject alanının AD bilgisinden mi kurulacağını yoksa request’ten mi sağlanacağını belirler; SAN davranışı ayrıca incelenmelidir.
• Subject Alternative Name (SAN), dNSName, rfc822Name veya UPN biçimli otherName gibi yapılandırılmış kimlik verileri taşıyabilir; hangi biçimin sayılacağı verifier/protokole bağlıdır.
• Extended Key Usage (EKU), extension mevcutsa certificate’i listelenen amaçlarla sınırlar; verifier’ın uyguladığı usage policy ayrıca önemlidir.
• Enroll ve AutoEnroll, template nesnesi üzerindeki extended right'lardır ve ACL ile verilir.
• CA manager approval veya authorized-signature koşulları, talebin issuance öncesi bekletilmesine ve onaylanmasına yol açabilir.
• Yayımlanmış template listesi CA nesnesinde tutulur; AD'de tanımlı olmak tek başına o CA'in o template'i imzalayacağı anlamına gelmez.
• AD certificate authentication’da güncel KDC mapping policy ayrıca denetlenir; SAN/Subject veya successful issuance tek başına belirli kullanıcıya strong mapping kanıtı değildir.

Template neyi belirler

Bir template en az dört şeyi birlikte tarif eder: sertifikada hangi isim alanlarının yer alacağı, bu isimlerin kaynağının ne olduğu, sertifikanın hangi kullanım amaçlarına açık olacağı ve kimin bu template ile talepte bulunabileceği. Bu dördü birbirinden bağımsız okunursa yanlış sonuç çıkar.

Özellikle Subject name source ayarı belirleyicidir. Subject Active Directory nesnesindeki seçili bilgilerden kuruluyorsa requester bu ayarla arbitrary Subject seçemez. Subject request’ten alınacak şekilde ayarlanmışsa değer request’ten gelebilir; SAN ise ayrı template/CA davranışı ve izinlerle incelenmelidir.

Subject ve SAN kardeş değil, farklı ağırlıkta

Subject alanı klasik Distinguished Name yapısıdır. SAN ise ek kimlikleri yapılandırılmış biçimde taşır: dNSName, rfc822Name ve Microsoft tarafında UPN taşıyan otherName biçimi gibi.

SAN, birçok protokolde kullanılabilen yapılandırılmış identity biçimleri taşıdığı için kritik bir alandır; ancak hangi alanın identity sayıldığı verifier, protokol ve yapılandırmaya bağlıdır. Subject’in doğru görünmesi SAN kaynağını veya AD KDC’nin certificate-to-account mapping kararını kanıtlamaz.

İsim kaynağını hem template hem CA düzeyindeki kurallar etkiler. CA genelindeki SAN override, template ayarından ayrıca incelenir. Bu ayarın varlığı certificate verilmesini, hesaba mapping yapılmasını veya authentication başarısını kanıtlamaz.

EKU: sertifikanın kullanım sözleşmesi

Extended Key Usage, sertifikanın amacını OID listesiyle sınırlar. Client Authentication (1.3.6.1.5.5.7.3.2) ve Microsoft'a özgü Smart Card Logon (1.3.6.1.4.1.311.20.2.2) gibi OID'ler, sertifikanın kimlik doğrulamada kullanılabileceğini bildirir.

EKU extension mevcutsa RFC 5280’e göre certificate yalnız listelenen amaçlarda kullanılmalıdır; uygulamalar belirli bir EKU’nun bulunmasını da şart koşabilir. Gerçek verifier’ın EKU ve key-usage kontrollerini uygulaması gerekir; certificate içindeki OID tek başına authorization değildir.

Enrollment bir yetkilendirme kararıdır

Template nesnesinin security descriptor'ı, hangi principal'ın o template ile sertifika talep edebileceğini belirler. Enroll ve AutoEnroll, standart okuma/yazma haklarından ayrı, control access right olarak modellenmiş extended right'lardır.

Bu yüzden PKI yüzeyini anlamak için CA yapılandırmasına bakmak yetmez; template ACL'lerinin kime açık olduğu okunmalıdır. Geniş bir grubun, isim seçimine izin veren ve kimlik doğrulama EKU'su taşıyan bir template üzerinde Enroll hakkına sahip olması, dizinde sessizce duran yüksek etkili bir yetkilendirmedir.

Durum ve veri akışı

1. Admin bir template tanımlar veya mevcut bir template'i kopyalayıp özelleştirir.
2. Template üzerinde Subject kaynağı, SAN davranışı, EKU listesi ve anahtar kuralları belirlenir.
3. Template'in ACL'inde hangi principal'ların Enroll veya AutoEnroll hakkı olduğu yazılır.
4. Template bir veya daha çok Enterprise CA üzerinde yayımlanır.
5. İstemci key pair üretir ve seçtiği template adıyla talep oluşturur.
6. CA, requester’ın ilgili template üzerinde Enroll hakkını ve template/CA issuance koşullarını değerlendirir.
7. CA template kurallarına göre Subject/SAN alanlarını üretir veya izin verilen request alanlarını kabul eder; Subject source kararı SAN davranışını otomatik olarak açıklamaz.
8. Manager approval veya authorized-signature gerekiyorsa talep bekletilir; koşullar karşılanınca certificate imzalanıp requester’a döner.
9. Verifier certificate purpose ve isim alanlarını kendi policy’sine göre değerlendirir. AD KDC authentication’da certificate-to-account mapping/strong-mapping koşulları ayrıca uygulanır; issuance bu sonucu kanıtlamaz.

2. Exploitation / İstismar

Broken trust assumption

Saldırgan için olası hedef, trusted CA’e seçtiği identity alanlarını taşıyan bir certificate issue ettirebilmektir. Bu issuance’ın başka bir AD principal adına authentication sağlaması, hedef protokolün account-mapping ve verifier policy’sine de bağlıdır.

Technical prerequisites

• Template authentication için kullanılabilen bir EKU veya amaç taşımalı.
• İlgili template ve CA kuralları talepteki kimlik verisine izin vermeli; yalnız template’in isim ayarı CA genelindeki SAN policy’sini göstermez.
• Talep eden principal enrollment için template üzerinde Enroll hakkına sahip olmalı. AutoEnroll, otomatik enrollment için ayrı bir haktır; Enroll yerine geçmez.
• Talep ile issuance arasında gerekli manager approval/authorized-signature kontrolü bulunmamalı veya atlanmış olmalı.
• Template, kimlik doğrulamayı kabul eden bir Enterprise CA üzerinde yayımlanmış olmalı.
• Authentication hedefleniyorsa ilgili verifier, güncel certificate-to-account mapping policy’sine göre bu certificate’i bir principal’a bağlayıp kabul etmelidir.

Exploitation mechanism / İstismar mekanizması

Risk tek bir ayarda değil, profile bileşiminde doğar. Authentication kullanımına uygun EKU, request’ten identity alanı sağlama, geniş Enroll, issuance onayının olmaması ve template’in ilgili Enterprise CA’de yayımlanması bir araya gelirse attacker-chosen identity alanlarıyla certificate issue edilebilir. Bu kriptografiyi kırmaz. Ancak certificate issue edilmesi tek başına başka bir AD hesabı olarak logon olmayı kanıtlamaz; güncel KDC strong-mapping kuralları ve hedef protokol ayrıca değerlendirilir.

Bileşim riski

Authentication EKU’su yaygın olabilir; request’ten identity alma bazı iş akışlarında gerekir; Enroll hakkı da meşru kullanıcı gruplarına verilebilir. Risk, bu koşulların aynı published template’te birleşip seçilebilir identity alanları için düşük bariyerli issuance sağlamasıdır; AD authentication sonucu ayrıca mapping kurallarına bağlıdır.

Bu nedenle PKI incelemesinde doğru birim tek tek ayarlar değil, template başına çıkarılan bileşik profildir: EKU listesi, isim kaynağı, onay gereksinimi ve Enroll sahipleri yan yana okunmalıdır.

Sonuç neden kalıcıdır

Template değişikliği daha önce issued edilen certificate’leri geriye dönük silmez veya iptal etmez. Eski certificate, validity süresi içinde ve hedef verifier’ın revocation/mapping policy’si izin veriyorsa kabul edilmeyi sürdürebilir.

Yanlış yapılandırmayı düzeltirken mevcut issuance kayıtlarını ve certificate’leri ayrıca envanterleyip, gerekirse iptal etmek gerekir. Password reset tek başına certificate’i revoke etmez.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Hangi template'ler kimlik doğrulamaya açık EKU taşıyor ve bunların Enroll sahipleri kimler?
• Hangi template'ler isim bilgisinin talepte sağlanmasına izin veriyor?
• Bu template'lerden hangilerinde manager approval devre dışı?
• Enroll ve AutoEnroll hakları hangi gruplara, ne zaman ve hangi gerekçeyle verilmiş?
• İmzalanmış sertifikaların Subject ve SAN değerleri, talep eden hesapların beklenen kimlikleriyle örtüşüyor mu?
• AD KDC certificate authentication için deployed strong-mapping davranışını, explicit mapping/SID-extension gereksinimlerini ve ilgili domain-controller update/policy durumunu doğrula.

Events and relevant fields

• CA database request/issuance kaydını issued certificate ile eşleştirmek; requester/request, template ve signed Subject/SAN alanlarını incelemeye yardım eder. Bu kayıt tek başına private-key custody veya authentication success kanıtı değildir.
• Template nesnesi üzerindeki izin değişikliği, directory tarafında bir ACL değişikliği olarak görünür ve yüksek değerli bir sinyaldir.
• Yeni template yayımlanması veya mevcut template'in EKU/isim davranışının değişmesi, nadir ve etkisi büyük bir yapılandırma olayıdır.
• Requester account identity ile issued Subject/SAN arasındaki beklenmedik uyumsuzluk inceleme sinyalidir; service/device ve delegated issuance senaryolarında meşru olabilir ve tek başına abuse kanıtlamaz.
• Microsoft KB5014754 strong certificate mapping için KDC Event 39’u, bazı eski desteklenen Windows Server sürümlerinde Event 41’i belgeler. Bunlar ilgili Windows update, KDC role ve mapping mode bağlamında yorumlanmalı; evrensel AD CS template-event listesi sayılmamalıdır.

İnceleme birimi: template profili

Savunma tarafında işe yarayan çıktı, template başına tek satırlık bir profildir: EKU listesi, isim kaynağı, onay gereksinimi, Enroll sahipleri ve hangi CA'lerde yayımlandığı. Bu tablo çıkarıldığında riskli bileşimler göz ile ayırt edilebilir hale gelir.

Bu çalışma periyodik olmalıdır. Template tanımları ve ACL'leri zaman içinde, çoğu zaman tek tek masum görünen taleplerle genişler.

İmza kaydı ile dizin kaydını birleştirmek

CA database talep ve issuance kanıtını, directory ACL ise talep anında Enroll hakkı kimdeydi sorusunu yanıtlar. Request record ile o tarihteki template ACL snapshot’ı birlikte okunmalı; güncel ACL geçmişteki izinleri tek başına kanıtlamaz.

İmzalı certificate’in Subject/SAN alanlarını ve template’i belirle, sonra CA request kaydı ile request-time template ACL’ini korele et. Authentication iddiası varsa KDC strong-mapping evidence ve verifier sonucunu da ekle. Bu kaynaklar birlikte bile gerçek authentication success veya private-key custody’yi tek başına göstermez.

Detection logic · KQL

// Sentetik şema örneği: talep eden hesabın kimliğiyle örtüşmeyen SAN/UPN içeren sertifika taleplerini yüzeye çıkarma.
// Alan adları ortamdaki tablo şemasına göre doğrulanmalıdır; bu sorgu çalıştırılmamıştır.
CertificateRequest
| where isnotempty(RequestedUpn)
| extend RequesterUpn = tolower(RequesterAccountUpn), ClaimedUpn = tolower(RequestedUpn)
| where RequesterUpn != ClaimedUpn
| project TimeGenerated, CaName, TemplateName, RequesterUpn, ClaimedUpn, RequestId
| order by TimeGenerated desc

Query assumptions

• Dataset yoktur; sorgu çalıştırılmamıştır.
• Tablo ve alan adları örnektir, Windows olay şemasının birebir karşılığı değildir.
• CA talep kayıtlarının merkezi olarak toplandığı varsayılmıştır.
• UPN mismatch yalnız triage adayıdır; signed certificate, KDC mapping ya da authentication sonucunu tek başına kanıtlamaz.

False positives

• Servis hesapları adına meşru olarak sertifika talep eden merkezi otomasyonlar.
• Cihaz veya servis sertifikalarında, isteyen hesabın kimliğiyle eşleşmesi beklenmeyen isim alanları.
• Göç ve yeniden adlandırma dönemlerinde geçici olarak eski kimliği taşıyan talepler.

Hardening

• Authentication için kullanılan template’lerde Subject/SAN bilgisini mümkünse AD DS’den al ve talepte isim sağlamayı sınırlandır. İlgili CA’nin EDITF_ATTRIBUTESUBJECTALTNAME2 ayarını da incele: CA genelindeki bu override açıksa template’te Supply in the request seçeneğini kapatmak, talepte SAN sağlanmasını tek başına engellemez. Override’ın kapalı olduğunu doğrula; CA policy’sini değiştirmeden önce bağlı issuance iş akışlarını değerlendir.
• Enroll ve AutoEnroll haklarını geniş gruplar yerine dar ve amaca özel gruplara ver.
• İsim seçimine izin vermesi zorunlu olan template'lerde manager approval'ı zorunlu tut.
• Yayımlanmış template listesini düzenli olarak gözden geçir ve kullanılmayanları CA üzerinden kaldır.
• Template ACL değişikliklerini ayrı bir değişiklik kategorisi olarak izle ve onaya bağla.
• Yanlış yapılandırma düzeltildiğinde, o template'ten üretilmiş mevcut sertifikaların iptalini de planla.
• AD certificate authentication için güncel strong-mapping gereksinimlerini uygula ve eski compatibility registry workaround’larına güvenme; target DC güncelleme/policy durumunu doğrula.

Örnekler üzerinde oku / Read the examples

30 81 d2 30 1f 06 03 55 1d 25 04 18 30 16 06 08
2b 06 01 05 05 07 03 02 06 0a 2b 06 01 04 01 82
37 14 02 02 30 4d 06 03 55 1d 11 04 46 30 44 a0
29 06 0a 2b 06 01 04 01 82 37 14 02 03 a0 1b 0c
19 73 76 63 2d 77 65 62 40 6f 75 74 72 65 61 73
6f 6e 2e 65 78 61 6d 70 6c 65 82 17 77 65 62 30
31 2e 6f 75 74 72 65 61 73 6f 6e 2e 65 78 61 6d
70 6c 65 30 31 06 09 2b 06 01 04 01 82 37 15 07
04 24 30 22 06 1a 2b 06 01 04 01 82 37 15 08 83
d7 89 2f 83 a8 9f 57 e9 e3 76 fd f1 39 02 81 0e
02 01 64 02 01 02 30 2d 06 09 2b 06 01 04 01 82
37 14 02 04 20 1e 1e 00 43 00 6f 00 72 00 70 00
57 00 65 00 62 00 53 00 65 00 72 00 76 00 65 00
72 00 56 00 32

O:DAG:DAD:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CR;0e10c968-78fb-11d2-90d4-00c04f79dc55;;S-1-5-21-1002233445-2244556677-3366778899-1137)(OA;;CR;a05b8cc2-17bc-4802-a710-e7c15ab866a2;;S-1-5-21-1002233445-2244556677-3366778899-1137)(A;;RPLCLORC;;;AU)

İki yanlış kanı / Two reality checks

Sanılan: Enterprise CA güvenli yapılandırıldığı sürece hangi template'in yayımlandığı ikincil bir ayrıntıdır.

Gerçekte: Enterprise CA template kurallarına göre certificate issue eder. Request-supplied Subject/SAN, authentication-use EKU, geniş Enroll, onay yokluğu ve publication birlikte yüksek issuance riski oluşturabilir. Certificate’in AD principal’a map edilip authentication’da kabulü ayrıca target protocol/KDC policy’sine bağlıdır.

Sanılan: Sertifikanın Subject alanı kimliği belirler; SAN yalnızca kozmetik bir ek alandır.

Gerçekte: SAN dNSName, UPN otherName gibi yapılandırılmış identity değerleri taşıyabilir. Verifier’ın hangi alanı nasıl kullandığı protokol/configuration ve AD KDC için güncel strong-mapping policy’sine bağlıdır; doğru Subject tek başına yeterli kanıt değildir.

Kaynaklar / Sources

• Microsoft · Active Directory Certificate Services (AD CS) genel bakış
  Enterprise CA ile standalone CA ayrımı; AD CS rol servisleri ve dizine bağlı enrollment modeli.
• Microsoft · Configure the User Certificate Template (Windows Server 2012)
  User certificate template örneği: Security sekmesinde Read/Enroll/Autoenroll; Subject Name kaynağının AD olması ve UPN; CA üzerinde Certificate Template to Issue. Tarihsel örnek, tüm template türleri için varsayılan iddiası değil.
• Microsoft Open Specifications · [MS-WCCE]: Windows Client Certificate Enrollment Protocol
  Enrollment talebi akışı, template referansı ve talep içinde taşınan isim/extension bilgisinin protokol düzeyindeki temsili.
• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  Bölüm 4.2.1.6 subjectAltName ve GeneralName biçimleri; Bölüm 4.2.1.12 extended key usage.
• Microsoft · Certificate template concepts
  Only Enterprise CAs issue from AD DS templates; templates define request/issuance rules and assigned permissions.
• Microsoft · Manage certificate templates
  Template issuance publication/removal on a CA and effect of template changes/deletion. Security considerations: CA-wide EDITF_ATTRIBUTESUBJECTALTNAME2 SAN override, separate from template Supply in the request; investigate dependencies before change.
• Microsoft Support · KB5014754 certificate-based authentication changes on Windows domain controllers
  Strong certificate mapping, SID extension, Full Enforcement, update timeline through September 9, 2025, and KDC Event 39/41 applicability.
• Microsoft Open Specifications · [MS-PKCA] Mapping Strength
  Strong versus weak certificate-to-account mapping distinctions and mapping behavior.
• Microsoft MS-CRTD · Determining Autoenrollment Permission of an End Entity for a Template
  Current section 2.5.2: CR + ObjectType GUID table, Enroll 0e10c968-78fb-11d2-90d4-00c04f79dc55 and AutoEnroll a05b8cc2-17bc-4802-a710-e7c15ab866a2.