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:

• Serial Numer Control : To check if the certificate serial number is a poisitive integer.
• Certificate Date Control : To check if the validity period of the certificate covers the validation date.
• Version Control : To check if the version information is valid.
• Extension Control: To check if the extensions of the certificate are valid.
• Signature Algorithm Control: To check if the signature algorithm defined in the certificate matches with the the one used in the signature of the certificate.

Chain Relation Validation includes the controls validating the relation between the certificte or crl and the issuer certificate.

• Name Control:To check if the issuer field of the certificate or the crl matches with the subject field of the issuer certificate.
• Signature Control : To verify the signature in the certificate or the crl by using the public key of the iissuer certificate.
• Basic Constraints Control : To check if the issuer certificate has Basic Constraints extension and this extension contains issuer flag as defined in RFC 5280.
• Key Identifier Control : To check if the authority key identifier field extensionin the certificate or the crl matches with the subject key identifier extension in the issuer certificate.
• Path Length Control:To check if the length of the certificate chain does not exceed the value taking place in the issuer certificate
• Key Usage Control: To check if the key usage of the issuer certificate includes certificate signing usage.

These controls are related with the revocation status of the certificate.

• Revocation Control From CRL :To check revocation status of the certificate by using its CRL.
• Revocation Control From OCSP :To check revocation status of the certificate by using its OCSP.

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.

The list of all checkers defined in ESYA Certificate Validation API is shown in Table 1

Checker classes may need some external data when performing their jobs. These data may be a crl info, an OCSP query response, or an issuer certificate. In general, those external data needed during certificate validaton is found and retrieved by finder classes. When a certificate, crl or OCSP Response is searched for, the finders are operated in the order defined by the validation policy until the demanded data is found. Therefore the order of the Finders is very important for performance. For example, if the Local Certificate Store Finder class is placed before the Remote (HTTP, LDAP, etc.)Certificate Finder class in the policy file, then certificate validation does not search for the certificate at remote places if it is found in the local certificate store which can provides significant performance gain.

Finder classes are orgainzed as follows:

These classes find the CA certificates trusted by the Validation API.

Certificate finders are responsible for finding CA certificates. For example, CertificateFinderFromAIA finds the issuer certificate of a certificate by looking at the authority information access (AIA) extension in the certificate. The certificate finder class finding the certificate at a specied http address is another example.

CRL finders are responsible for finding CRL for revocation control. For example CRLFinderFromCDP finds the crl for a certificate, by looking at the crl distribution points (CDP) extension in the certificate. The crl finder class finding the crl at a specied LDAP address is another example.

OCSP Response finders are responsible for finding or retrieving OCSP response for revocation control. For example, OCSPResponseFinderFromAIA , retrieves the OCSP response for a certificate by querying at the OCSP server whose address is taking place in the authority information access (AIA) extension in the certificate. The ocsp response finder class finding the ocsp response in the local certificate store is another example.

The list of all finders defined in ESYA Certificate Validation API is shown in Table 3

The certificates, crs and OCSP responses that Finders have found, must be matched according to certain criteria in order to guarantee that they are the correct ones. Matchers perform these matching operations according to the rules defined in RFC 5280. Matcher classes are organized as follows:

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

certval-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;

• Politika dosyası sunucudan çekilir ve bellekte tutulur. Böylelikle politika dosyasına dışardan müdahale olasılığı azalır.
• Politika dosyasının özeti sunucuda tutulur. İstemcideki politika dosyasının özeti alınır ve sunucudan çekilen özet ile karşılaştırılır. DigestUtil sınıfı ile özet işlemini gerçekleştirebilirsiniz.
• Politika dosyası istemcide parola tabanlı şifrelenerek tutulur ve şifresi bellekte çözülür. Bunun nasıl yapıldığı gösteren örneği “http://www.java2s.com/Tutorial/Java/0490Security/PBEFileEncrypt.htm” adresinde bulabilirsiniz.
• Politika dosyası imzalı bir şekilde tutulur. Politika dosyasına karar verildikten sonra politika dosyası bir kere imzalanır ve bu imzalı dosya istemcilerde tutulur. İmzalanan politika dosyasının imzası doğrulanırsa ve imza doğru kişi tarafından atılmışsa; politika dosyasına güvenilebilir. Doğru kişi imzalamış mı kontrolünün yapılması için, kodunuzun içine imzacı sertifikasının gömülmesi gerekmektedir. Kodunuzu, devamlı değiştiremeyeceğinizden imzalama işleminde kullandığınız akıllı kartı veya pfx dosyasını kesinlikle kaybetmemeniz gerekmektedir. Politika dosyasını PKCS7 standardında imzalayabilirsiniz. PKCS7 tipindeki imza için buraya bakabilirsiniz.

Yukarıdaki güvenlik önlemleri birlikte veya tek olarak uygulanabilir. Politika dosyasının güvensiz bir şekilde istemcilerde durmasını kesinlikle önermiyoruz.

Esya Sertifika Doğrulama Kütüphanesi sertifika ve SİL doğrulama işlemi sonucunda Sertifika Durum Bilgisi (CertificateStatusInfo) ve SİL Durum Bilgisi (CRLStatusInfo) sınıflarından bir nesne oluşturur. Bu sınıf içerisinde ayrıntılı kontrol detayları , oluşturulmuş ve doğrulanmaya çalışılan farklı sertifika zincirleri doğrulanma sonuçlarıyla birlikte detaylı olarak saklanır. Bu sınıfın nesnesinin kullanımı, örnek kodlarla birlikte CAdES İmza Kütüphanesi bölümünde daha detaylı olarak görülebilir.

Sertifika deposu, güvenilir olduğu kabul edilen yayıncı sertifikalarının saklanabileceği bir kök sertifika deposu olarak geliştirilmiştir.

Sertifika deposu aynı zamanda doğrulama işlemi sırasında bulunması gereken yayıncı sertifikası, SİL, OCSP cevabı gibi verilerin sürekli uzak kaynaklardan çekilmesini engellemek için bu verilerin yerelde saklanabilmesinden sorumludur.

Sertifika deposunun varsayılan yeri, kullanıcının ana klasörünün(user home directory) altındaki ”.sertifikadeposu” klasörünün içidir. Varsayılan dosya ismi ise “SertifikaDeposu.svt”dir. Eğer farklı bir dosya yolu ve dosya ismi kullanılması isteniyorsa, sertifika doğrulama politika dosyasında belirtilmelidir. Bunun için storepath parametresi kullanılmalıdır.

Esya Sertifika Doğrulama API'si yerel sertifika deposunda güvenilir kök sertifikası olarak tanımlanmış seritikaları güvenilir olarak kabul eder ve doğrulama sırasında oluşturduğu sertifika zincirlerinin bu sertifikalardan biriyle sonlanmasını bekler. API'deki yerel sertifika deposundan sertifika ve sil bulucular kullanılarak doğrulama verileri istenildiğinde yerel depodan bulunabilir.

<class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromECertStore">
<param name="storepath" value="T:\MA3\api-parent\certStore\SertifikaDeposu.svt"/>
</class>

Test sertifikalarıyla çalışırken sertifikanın doğrulanması sırasında PATH_VALIDATION_FAILURE hatası alabilirsiniz. Bu durumun muhtemel sebebi, test sertifikaların köklerinin sertifika deposunda güvenilir sertifika olarak tanımlanmamasıdır. Bu kök sertifikaları dosya yoluyla belirtebilirsiniz. Yalnız bu kullanım sadece test amacıyla yapılmalıdır.

<class name="("tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromFileSystem">
<param name="dizin" value="T:\\MA3\\api-cmssignature\\testdata\\support\\UGRootCerts\\"/>
</class>

Dosya sistemine herhangi bir şekilde erişimin olmadığı durumlarda kullanılması için XML tabanlı sertifika deposu dosyası geliştirilmiştir. Bu şekilde internet üzerindeki bir depo ile çalışabilmek mümkün olmaktadır.

Sertifika doğrulama konfigürasyon dosyasında XML depodan güvenilir sertifika bulucu aşağıdaki gibi tanımlanır:

<class name="tr.gov.tubitak.uekae.esya.api.certificate.validation.find.certificate.trusted.TrustedCertificateFinderFromXml">
<param name="storepath" value="http://www.kamusm.gov.tr/depo/xml/XmlDepo.xml"/>
</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>

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.