Share via


PKI ‘ın Temelleri–2 ( Certification Authorities, Certificate Revocation Lists )

 

 

Certification Authorities

Bir certification authority (CA) Microsoft PKI çözümünün temel bir bilesenidir. Bir Windows Server 2008 network’ünde Certificate Services in kurulu oldugu bir Windows Server 2008 computer ‘ü asagidaki görevleri yerine getirir.

¦ Sertifika isteyicisinin kimligini dogrular CA isteyicinin kimligini, bir sertifikayi issue dagitmadan önce onaylamalidir. Bu onaylama sertifika isteyicisi ile yüz yüze bir görüsme yapabilecek bir sertifika yöneticisine sahip olmakla beraber belirli bir tipte sertifikayi istemek için requestor’in geekli izinlere sahip olduguna güvence vermeyi saglayabilir

¦Requester’lara sertifikalari issue eder Sertifika Requester’in kimligi dogrulandiginda , CA request edilen tipte sertifikayi user, computer, network device, ya da service’e issue eder. Request edilen sertifikanin tipi issue edilen sertifikanin içerigini belirler.

Örnek olarak , Bir IPsec sertifika requesti bir sertifikada IPsec communications için end pointleri authenticate etmek için sadece server ya da client sertifikasi kullanir

¦Certificate revocation’i yönetir. CA zamanlanmis araliklarda bir CRL ‘I publish eder. CRL revoke edilmis sertifikalarin seri numaralarini ve her bir revocation için nedenini ( reason code ) içeren bir liste içerir.Bir Enterprise PKI da genellikle birden fazla CA uygulanmistir..Bir CA hiyerarsisinde organize edilmis CA ler single Root CA ve bir kaç diger subordinate CAs olabilir. Asagidaki Resimde bu duruma örneklemeyi görebilirsiniz

Blog-1

Resim CA hiyerarsi rolleri

Resimde , CA’ler CA hiyerarsisinin güvenligini ve ölçeklenilebilirligini non-issuing CA’lerin network’e bagli kalmamasi ile artiran bir Root CA hiyerarsisinde organize edilmistir. Eger bir Root CA hiyerarsisinde Root CA ve Second-Tier CA’ler networkte olmazlar ise ( offline ) , bu offline CA ler network kaynakli saldirilardan da korunmus olurlar

Not Root CA hiyerarsisinin sadece offline CA lerde uygulandigini düsünmeyiniz. Root CA i offline CA’ler olmaksizin uygulayabilirsiniz . fakat güvenlik sorunlari nedeniyle önerilmemektedir.

Bir root CA hierarchy bir organizasyon içerisinde farkli ünitelere ya da bölümlere yönetimi delege etmeye izin verir. Common-Criteria role dagitimi hiyerarside her bir CA de CA Management rolünün delegasyonu na izin verir .Farkli administration gruplara CA’i CA hiyerarsisinde yönetme fakat digerlerine yönetmeme gibi durumlar

Not Root CA hiyerarsisi RSA, Thawte, ve VeriSign dahil tüm lider ticari CA vendorleri tarafindan desteklenmektedir . Root CA hiyerarsisi ayrica bir çok uygulamalar  ve çesitli uygulamalar ve network device larin birlikte çalisabilirliklerine izin veren , network device lar tarafindan desteklenmektedir.

Root CA

Bir Root CA bir CA hiyerarsisinde en üstte bulunan CA dir. Bir PKI yapisinda , Root CA hiyerarsideki CA ler tarafindan issue edilmis sertifikalar için bir güven noktasidir. Bu demektir ki , eger bir sertifika bir CA hiyerarsisi içerisinden bir Root CA ‘e bir user, computer, network device, ya da service’ içerisinden trace edilebiliyor ise bu sertifika trusted olarak görünür. Bir Root CA sertifikasi self-issued oldugu için özeldir. Bu demektir ki sertifikanin Issuer Name ve Subject Name alanlari ayni distinguished name’i içerir. Root Sertifikanin geçerli olup olmadigini anlamak için tek yol Trusted Root Store da Root Sertifikasini görmektir. Trusted root store sertifikati trusted olarak belirleyen gerçek Root CA sertifikasini içerir.

Not Eger bir self-signed certificate trusted root store da degilse bu nontrusted root CA olarak gözönüne alinilir.

Root CA diger CA lere ya da users, computers, network devices, ya da networkte servislere sertifika issue edebilir. . Root CA baska bir (entity) kurulus’a sertifika issue ettiginde , Root CA sertifikasi sertifikayi kendi private key i ile imzalayarak içerik modifikasyonuna karsi korur ve sertifikanin bu Root CA tarafindan issue edildigini gösterir.

Not Genellikle root CA diger CA’lere sertifika issue eder. Users, computers,network devices, ya da network te servisler’e issue etmez.

Intermediate CA

Birintermediate CA bir diger CA’e ast olan bir CA dir ve CA hiyerarsisindeki diger CA lere sertifika issue eder. intermediate CA , CA hiyerarsisinde root CA seviyesi hariç herhangi bir levelda olabilir.

Not Bir baska CA ye sertifika issue eden CA genelde parent CA olarak refere edilir. Örnek olarak , bir intermediate CA ye sertifika issue eden bir Root CA bu intermediate CA in parent CA i olarak referans edilir.intermediate CA ayrica subordinate CA olarak refere edilir.

Policy CA

policy CA Intermediate CA in özel bir kategorisidir. policy CA , CA hiyerarsisindeki CA lerin güvenligini saglamak ve certificate-holder’in kimligini dogrulamak için bir organizasyonun uyguladigi policy ler ve prosedürleri tanimlar. Bir policy CA sadece hiyerarsideki diger CA lere sertifika issue eder. Bir policy CA ‘e subordinate olan tüm CA’lerin , ki direk olarak subordinate de olabilir ya da 2 ya da daha fazla level Policy CA den asagida olabilir , Policy CA de tanimlanan Policy ve prosedürleri yerine getirecegi farz edilir.

Not Policyler ve prosedürler tipik olarak mantiksal kontrollerinin ( policy CA de yapilandirma ayarlari ) ve nitelikli kontrollerin ( yazilan polcy ler operasyonlar sirasinda izlenmelidir ) kombinasyonudur.

Eger bir organizasyon sertifikalari dagitirken birden fazla policy ve prosedür uygular ise birden fazla policy CA ‘in organizasyonda olmasi erekir. Bu durumu asagidaki diyagramdan görebilirsiniz.

Blog-2

Resim  Policy CA örnegi

Bu örnekte iki policy CA CA hiyerarsisinde yer alir. Internal Policy CA sertifika requester’in kimligini dogrulamak için kullanilan policyleri ve prosedürleri tanimlar. Internal policy CA ye direk olarak subordinate olan Iki issuing CA (Americas CA ve Europe CA) Internal Policy CA tarafindan tanimlanmis policyleri ve prosedürleri yerine getirmelidir. External Policy CA ise bu sirkette çalisan olmayan kisilere sertifika issue etmek için process ‘i güvenli hale getirmek ve kimlik dogrulama islemi policyleri ve prosedürleri tanimlamak için kullanilir. External Policy CA ‘e subordinate olarak Customers CA, External Policy CA tarafindan tanimlanan policyler ve prosedürler’I yerine getirmelidir.

Not Birden fazla policy ve prosedür bir policy CA de tanimlanabilir. Fakat ayrica organizasyon tarafindan uygulanmis her bir policy ve prosedürleri bir policy ca ‘e uygulamak geçerlidir.

Issuing CA

Bir issuing ca networkte sertifikalari users, computers, network devices, ya da services ‘e issue eden yapidir . Bir issuing CA genellikle bir CA yapisinda 3. Tier olarak yer alir , fakat CA hiyerarsi rolleri resminde gösterildigi gibi ayrica ikinci levelda da yer alabilir.Belirtildigi üzere , bir issuing ca ,CA hiyerarsisinde bir Root Ca ve issuing ca arasinda mevcut olan bir policy ca tarafindan belirtilen policy ve prosedürleri yerine getirmelidir. Eger bir issuing CA ikinci tier de deploy edilmis ise bu durumda genellikle hem policy ca hem de issuing ca olarak kendi policy ve prosedürlerini uygular.

Certificate Revocation Lists

Bazi durumlarda , bir CA bir sertifikayi validity period expire olmadan önce revoke etmes olabilir. Sertifika revoke edildiginde , CA bu sertifikanin serial numarasini ve revocation nedenini içeren bilgiyi CRL de tutar.

CRL Tipleri

Windows Server 2008 iki tip CRL ‘in issue edilmesini destekler : Base CRL ve Delta CRL .Bir base CRL bir CA üzerinde zamani halen geçerli olup revoke edilmis tüm sertifikalarin serial numaralarini her biri için  revocationin nedenleri ile birlikte tutar. Bir base CRL CA’in spesifik bir private key’i tarafindan imzalanmis tüm time-valid revoke edilmis sertifikalari içerir .Eger bir CA’in sertifikasi yeni bir key çifti ( key pair ) ile yenilenir ise , sadece CA in yeni private key ‘i ile imzalanmis ve revoke edilmis sertifikalari içeren yeni bir base CRL olusur.

Bir Delta CRL sadece son base CRL publish edildikten sonra revoke edilen sertifikalarin seri numaralarini ve revocation nedenini içerir.Delta CRL CA den daha yeni revocation bilgisini saglamak ve CRL ‘i alirken download edilen datanin büyük olmamasini saglamak için uygulanir. Yeni bir Base CRL publish edildiginde , delta CRL deki revoke edilen sertifikalar yeni base CRL ‘e eklenir. Yeni delta CRL sadece yeni base CRL publish edildikten sonra revoke edilen certifikalari içermektedir.Delta CRL base CRL den oldukça küçüktür çünkü sadece son revocationlari içerir.Tüm revoke edilen sertifikalari içeren Base CRL , daha az siklikta download edilebilir.

Not Eger delta CRL uygularsaniz güvenen bilesenler ( sertifika olan user , computer . network device , service vb. ) halen base crl ‘i download etmelidir . Base CRL ve Delta CRL ‘in kombinasyonu tüm revoke edilmis sertifikalarin bilgisini saglar.

Önemli  Tüm güvenen bilesenler delta CRL’i support etmez. Eger bir güvenen bilesen delta crl ‘i support etmez ise, güvenen bilesen bir sertifikanin revocation status’unu belirlemek için sadece base crl i arastirir.

Revocation Reasons

Bir sertifika revoke edildiginde CRL entry revocation hakkinda daha fazla bilgi içermelidir. Bunlar reason code olarak isimlendirilir. Reason code lar asagidakileri içerebilir :

¦Key Compromise Sertifika ile eslestirilmis Private key çalinmis ya da yetkisiz bir kisi tarafindan ele geçirilmis ise bu seçenek sertifika revoke edilirken kullanilabilir.Örnek olarak bir bilgisayarin çalinmasi ya da bir smart card’in kaybedilmesi olarak gösterilebilir.

¦CA Compromise CA ‘in kendi key ‘i compromise olmus olabilir. Bu durum Certificate Services çalisan computer ‘ün ya da CA ‘in private key ‘ini içeren fiziksel device ‘in ( HSM ) çalinmasi nedeni ile olabilir. Eger CA ‘in sertifikasi revoke edilirse ayrica bu CA tarafindan issue edilmis tüm sertifikalarda revoke edilmis olarak öngörülür çünkü bu sertifikalari issue eden CA artik güvenli olarak öngörülmez.

¦Affiliation Changed Sertifikanin subject ‘i , ki genellikle user , organizasyona artik bagli degildir.

¦Superseded Revoke edilen sertifika yeni bir sertifika ile degistirilmistir. Bu sertifikanin extensionlarinda olabilecek bir degisiklik nedeniylede olabilir ya da sertifikanin subject name degisikligi nedeni ile de olabilir.

¦Cessation Of Operation certificate’nin subject ‘i hizmetten çikartilmis oldugunda kullanilir. Bu mesela bir eski web server yeni bir isimle yeni bir web server ile degistirildiginde kullanilabilir. Bunun haricinde bir birlesme oldugunda ve önceki dns ismi hizmetten çikartilmis oldugunda , tüm web server sertifikalarinin yenilenmesine ihtiyaç duyar.

¦Certificate Hold Bu revocation sertifikanin geçici olarak revoke edilmesi için kullanilir. Mesela bu bir çalisanin yokluk zamanlari için kullanilabilir. Bu seçenek revocation’in geri alinabilecegi yegane seçenektir.

Not Certificate Hold sertifikani unrevoked edilmesini saglamasina ragmen bu kullanim önerilmez çünkü eger bir sertifika belirli bir zamanda geçerli ise bu durumu belirlemek çok zordur.

¦Remove From CRL Bu neden bir sertifikanin Certificate Hold reason ‘i ile birlikte revoke edildikten sonra unrevoked edildiginde kullanilir. Remove From CRL base crl de revoked olan olan sertifikanin delta crl de unrevoke oldugunu belirtmek için sadece delta crl de kullanilir

¦Unspecified Eger bir sertifika bir revocation reason belirtilmeden revoke edilmek istenilirse bu kod otomatik olarak crl ‘e eklenir.

Not Certificate revocation reason code lar için daha fazla bilgiye https://www.faqs.org/rfcs/rfc3280.html linkindeki RFC 3280 dökümanindan ulasabilirsiniz.

Kaynak : Windows Server 2008 PKI and Certificate Security