Bu sayfa salt okunur. Kaynağı görebilirsiniz ama değiştiremezsiniz. Bunun yanlış olduğunu düşünüyorsanız yöneticiye danışın.
ESYA Certificate Validation API uses path building and path validation algorithms. Briefly, when a certficate is to be validated, a certificate chain ending at a trusted root certificat is created first and then the chain is tried to be validated.Until a valid chain is found,these steps are repeated for all possible certificate chains.
ESYA Certificate validation API performs validation steps taking place in structural validation and chain validation within the certificate processing step. The details of the certificate processing can be seen in the figure above.
Certificate Processing consists of some groups of validation steps which can be configured by the certificate validation policy file at run-time. The structure of the policy file takes place in certificate validation policy section. The validation steps are designed and organized to be atomic and for each atomic step a (Checker) class is defined. Checker classes , when performing the defined check operation, may need some resources like certificate, crl, or OCSP response which are found by Finder classes. The resources founded by Finders must be matched if they are the correct ones. For this purpose, Matcher classes are defined. The check operations to be performed (Checkers), the locations and methods for resources that are searched for (Finders) and the methods for resource matching (Matchers) are defined by the validation policy file at run-time. Upon validation, the policy file is read and the corresponding objects of Checker, Finder, Matcher classes are created.
Checker classes check the compatibility of the structural characteristics of the certificate and crls and the chain relation to the standards. The details of these classes are out of the scope of the document. Certificate validation policy files determines which checkers are used in validation. The check operations performed by the checkers and defined in RFC 5280 are organized as follows:
Structural Control Operations includes validity checks of the information taking place in the certificate or crl both structurally and contextually. These operations are:
Chain Relation Validation includes the controls validating the relation between the certificte or crl and the issuer certificate.
These controls are related with the revocation status of the certificate.
The subject field of the certificate can only take certain values according to the rules included in the name constraints extension in the issuer certicate. These rules are denoted in RFC 5480 in detail. Name controls check if the certificate is compatible with these rules.
The policy information in the certificate can only take certain values according to the rules included in the policy constraints extension in the issuer certicate. These rules are denoted in RFC 5480 in detail. Policy controls check if the certificate is compatible with these rules.
Th list of all checkers defined in ESYA Certificate Validation API is shown in Table 1
Kontrolcü sınıflar çalışırken bir takım dış verilere ihtiyaç duyabilirler. Bunlar SİL bilgisi , OCSP sorgusu ya da SM sertifikası olabilir. Yine zincir oluşturma sırasında SM sertifikalarının çeşitli yerlerden (http adresi, yerel seritifika deposu vb.) bulunması gerekebilir. Genel olarak sertifika doğrulama sırasında dışarıdan bulunması gereken sertifika , SİL, OCSP Cevabı verilerini bulma işlemini bulucu sınıflar gerçekleştirir. Bir sertifika , SİL ya da OCSP cevabı bulunurken politika dosyasında tanımlı Bulucular sırayla çalıştırılır ve aranılan veri bulunduğunda bulma işlemi sonlandırılır. Bu nedenle bulucuların uygun bir sırayla politika dosyasına yerleştirilmiş olması performans açısından oldukça önemlidir. Örneğin yerel depodan sertifika bulucunun uzak kaynaklardan(LDAP,HTTP vb.) sertifika bulculardan önce yerleştirilmesi sertifika arama işlemlerinin sertifika yerel depoda varsa uzak kaynaklara başvurulmadan sonuçlanmasını sağlar ve bu da ciddi performans kazanımları getirir. Sertifika Doğrulama politikası aracılığıyla hangi bulucuların hangi sırayla çalıştırılacakları bilgisi tanımlanmaktadır.
Esya Sertifika Doğrulama Kütüphanesinde tanımlı bulucular şu şekilde gruplanabilir.
Doğrulama kütüphanesinin güvenilir olarak tanıdığı SM sertifikalarını bulan sınıflardır.
SM sertifikası bulmaktan sorumlu sınıflardır.Bu bulucular sertifikanın üzerinde yer alan Yetkili Erişim Noktası (AIA) eklentisine bakarak SM sertifikası bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan sertifika bulan sınıflar olabilir.
SİL bulmaktan sorumlu sınıflardır. Sertifika üzerinde yazan Sil Dağıtım Noktaları (CDP) eklentisine bakarak SİL bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan SİL bulan sınıflar olabilir.
OCSP cevabı bulmaktan sorumlu sınıflardır. Sertifika üzerinde yazan Yetkili Erişim Noktası (AIA) bakarak OCSP cevabı bulan sınıflar olabileceği gibi bir http adresinden, bir LDAP adresinden ya da dosya sistemindeki bir adresten ya da yerel sertifika deposundan OCSP cevabı bulan sınıflar olabilir.
Esya Sertifika Doğrulama API’sinde tanımlı ve politika dosyasında kullanılabilecek tüm bulucuların listesi Table 3’te yer almaktadır.
Bulunan sertifika, SİL ya da OCSP cevabı bilgilerinin gerçekten aranılan veriler olup olmadığını anlamak için gerekli eşleştirmeden sorumlu sınıflardır.Bu eşleştirme kuralları RFC 5280'de yer almaktadır. Esya Sertifika Doğrulama Kütüphanesinde tanımlı bulucular şu şekilde gruplanabilir.
Sertifika ile yayıncı sertifikasını eşleştiren sınıflardır. Örneğin RFC 5280'de bir X509 sertifikası üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Esya Sertifika Doğrulama kütüphanesinde bu eşleştirme işini gerçekleştiren eşleştirici (IssuerSubjectMatcher) sınıfı vardır. Eşleştiricilerin eşleştiremediği sertifikalar yayıncı sertifikası olarak sertifika zincirine eklenmezler.
Sertifika ile SİL'i ya da SİL ile SİL yayınlayan sertifikayı eşleştiren sınıflardır. Örneğin RFC 5280'de , dolaylı SİL (indirect crl) kullanılmıyorsa, bir SİL üzerinde yazan issuer alanı ile yayıncı sertifikası üzerinde yer alan subject alanı aynı olmalıdır şeklinde bir ifade yer alır. Bir SİL'in yayıncı sertifikası olan sertifikanın bulunması için bu ifadenin doğruluğu kontrol edilir. Bu kontrol işlemi için bir eşleştirici (CRLIssuerMatcher) tanımlıdır.
Sertifika ile OCSP cevabını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir
SİL ile Delta-SİL'i eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir
SM Sertifikası ile çapraz SM sertifikasını eşleştiren sınıflardır. Çalışma şekilleri sertifika ve SİL eşleştiriciler gibidir.
Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm eşleştiricilerin listesi Table 2’de yer almaktadır.
Esya Sertifika Doğrulama API'si doğrulama sırasında bulduğu sertifika ve SİL'leri yerel depoya kaydeder. Bu işlemi kaydediciler (Saver) gerçekleştirir ve yine politika dosyası aracılığıyla hangi kaydedicilerin çalışacağı tanımlanabilir. Örneğin istenildiği kadar kaydedici tanımlanarak doğrulama sırasında bulunan ve doğrulanan bütün sertifikalar istenilen yerlere kaydedilirler.
Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm kaydedicilerin listesi Table 4’te yer almaktadır.
Sertifika doğrulama işlemi bir çok kontrol işleminin arka arkaya yapılmasından oluşan bir süreçtir. Bu kontrol işlemlerinin hangilerinin yapılıp hangilerinin yapılmayacağını ve bu kontroller sırasında kullanılan bir takım parametrelerin çalışma zamanında belirlenebilmesi için XML formatında bir doğrulama politikası dosyası kullanılmaktadır. Bu XML dosyasında yer alan her bir “class” elemanı bir sınıfı temsil eder ve bu sınıflar doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıflarıdır. Bu dosya, doğrulama işleminin başında okunarak doğrulama politikası nesnesi oluşur ve bütün doğrulama adımları bu politikada belirtilen yapılandırma bilgileri doğrultusunda gerçekleştirilir. Doğrulamada kullanılacak kontrol, bulma ve eşleştirme sınıfları, sertifika politikası kontrolleri ile ilgili ayarlar bu yapılandırma bilgilerinden bazılarıdır.
A sample validation policy
< !--Dosyayı xml olarak kaydediniz--> < ?xml version="1.0" encoding="UTF-8"?> < policy> <find> <trustedcertificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromECertStore"> <param name="securitylevel" value="legal,organizational"/> </class> <!--class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem"> <param name="dizin" value="path\to\trusted certificates"/> </class--> </trustedcertificate> <certificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromECertStore"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromHTTP"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromLDAP"/> </certificate> <deltacrl/> </find> <match> <certificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.match.certificate.IssuerSubjectMatcher"/> </certificate> <crl> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.match.crl.CRLIssuerMatcher"/> </crl> <deltacrl> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.BaseCRLNumberMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.CRLNumberMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.DeltaCRLIssuerMatcher"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.deltacrl.ScopeMatcher"/> </deltacrl> <ocsp> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.match.ocsp.CertIDOCSPResponseMatcher"/> </ocsp> </match> <save> <crl> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreCRLSaver"/> </crl> <!--ocsp> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreOCSPResponseSaver"/> </ocsp> <certificate> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.save.CertStoreCertificateSaver"/> </certificate--> </save> <validate> <certificate> <self> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.SignatureAlgConsistencyChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.PositiveSerialNumberChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateDateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateExtensionChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.VersionChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.QualifiedCertificateChecker"> <param name="statementoids" value="(0.4.0.1862.1.1 AND 2.16.792.1.61.0.1.5070.1.1)"/> </class> </self> <trustedcertificate> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.SelfSignatureChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.self.CertificateDateChecker"/> </trustedcertificate> <issuer> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.BasicConstraintCAChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.PathLenConstraintChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.KeyIdentifierChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateKeyUsageChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateNameChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.issuer.CertificateSignatureChecker"/> </issuer> <revocation> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.revocation.RevocationFromOCSPChecker"> <param name ="devam" value="false"/> <find> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.ocsp.OCSPResponseFinderFromAIA"/> <!--class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.ocsp.OCSPResponseFinderFromECertStore"/--> </find> </class> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.certificate.revocation.RevocationFromCRLChecker"> <param name ="cevrimdisicalis" value="false"/> <param name ="checkallcrls" value="false"/> <param name ="devam" value="false"/> <find> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromECertStore"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromECertStore"> <param name = "getactivecrl" value="true"/> </class> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderFromHTTP"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.find.crl.CRLFinderfromLDAP"/> </find> </class> </revocation> </certificate> <crl> <crlself> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.self.CRLDateChecker"/> <class name = "tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.self.CRLExtensionChecker"/> </crlself> <crlissuer> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.issuer.CRLSignatureChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.crl.issuer.CRLKeyUsageChecker"/> </crlissuer> </crl> <ocsp> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.OCSPResponseDateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.ResponseStatusChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.SigningCertificateChecker"/> <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.check.ocsp.OCSPSignatureChecker"/> </ocsp> </validate> <parameters> <UserPolicySet value="2.5.29.32.0"/> <InitialExplicitPolicy value="false"/> <InitialAnyPolicyInhibit value="false"/> <InitialPolicyMappingInhibit value="false"/> </parameters> < /policy>
Politika dosyası, sertifika doğrulama sırasında kullanılacak verilerin nasıl bulunacağını (find), doğru verilerin bulunup bulunmadığının kontrolü için nasıl eşleştirme yapılacağını (match) ve doğrulama sırasında hangi kontrollerin yapılacağını (validate) belirten sınıfları bulunduran dosyadır.
Politika dosyasının değiştirilememesi imza doğrulama için hayati önem taşır. Politika dosyasında hangi kontrollerin yapılacağı ve hangi sertifikalara güvenileceği bilgisi yer almaktadır. Kötü niyetli kişiler politika dosyasını değiştirerek, kötü niyetle yaratılmış imzaların doğrulanmasını sağlayabilirler. Politika dosyası için aşağıdaki güvenlik önlemleri uygulanabilir;
</class> Yine xml depodan sertifika bulucu aşağıdaki şekilde tanımlanır: <class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.CertificateFinderFromXml"> <param name="storepath" value="http:www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/> </class> </sxh> XML depodan güvenilir sertifika bulucu parametre olarak bir URL almaktadır. Performans arttırmak için yerel ağlarda bu dosyanın bir kopyasını bulundurmak ve onunla çalışmak faydalı olur. Bunun yanında xml sertifika deposu sadece ESYA sertifika doğrulama kütüphanesi ile kullanılmalıdır. Aksi taktirde man-in-the-midle saldırısına kapı açılmış olur. ESYA Kütüphanesi bu dosyadaki güvenilir sertifikalar için imza kontrolü yapmaktadır. Bir diğer göz önünde bulundurulması gereken konu performanstır. Yerel sertifika deposu kullanılırken imza doğrulamada kullanılan iptal listeleri depoya kaydedilip tekrar kullanılabilirken, xml sertifika deposu sadece okuma özellikli olduğu için bu avantajdan mahrumdur. Bu yüzden iptal listeleri her doğrulamada tekrar indirilmek zorunda kalınacaktır. Bu da ciddi performans kaybına yol açar.