Esya Sertifika Doğrulama API'si zincir oluşturma ve zincir doğrulama algoritmalarını kullanır. Özetle bir sertifika ya da SİL için doğrulama isteğinde bulunulduğunda , önce güvenilir bir kök sertifikada sonlanan bir sertifika zinciri oluşturulur ve bu zincir doğrulanmaya çalışılır. Geçerli bir zincir bulununcaya kadar bu işlem tekrarlanır.

Esya Sertifika Doğrulama API'si zincir doğrulama sırasında gerçekleştirilen yapısal doğrulama ve zincir ilişkisinin doğrulanması ile ilgili kontrolleri diyagramda yer alan Sertifika İşleme adımında gerçekleştirir. Sertifika İşleme adımının detayları yukarıdaki şekilde görüntülenmektedir.

Bu aktivite gruplara ayrılmış bir takım kontrol işlemlerinden oluşur ve bu kontrol işlemleri bir sertifika doğrulama politika dosyasında çalışma zamanında yapılandırılabilir. Bu politika dosyasının yapısı bu bölümde yer almaktadır. Bu kontrol işlemleri atomik olarak ayrı ayrı tanımlanmış ve her bir atomik kontrol için bir kontrolcü (Checker) sınıf tanımlanmıştır. Kontrolcü sınıflarının kontrol işlemlerini yaparken ihtiyaç duyduğu sertifika , SİL, OCSP cevabı gibi kaynakları çeşitli yollarla ve çeşitli yerlerden bulmak için bulucu (Finder) sınıfları tanımlanmıştır. Bulucuların bulduğu kaynakların doğru kaynaklar olup olmadığının test edilmesi gerekmektedir ve bu amaçla eşleştirici (Matcher) sınıfları oluşturulmuştur. Esya Sertifika Doğrulama Kütüphanesi hangi kontrollerin yapılacağını yani hangi kontrolcü sınıflarının kullanılacağını, ihtiyaç duyulan kaynaklar için nerelere bakılacağını yani hangi bulucu sınıflarının kullanılacağını ve bulunan kaynakların nasıl eşleştirileceğini yani hangi eşleştirici sınıflarının kullanılacağını belirlemek amacıyla çalışma zamanında işlemek üzere doğrulama politikası dosyasını kullanır. Doğrulama işleminin öncesinde bu politika dosyası okunarak gerekli kontrolcü, bulucu, ve eşleştirici alt sınıfları oluşturulur.

Sertifika ve SİL'lerin yapısal özelliklerinin ve sertifika zincir ilişkisinin standartlara uygunluğunu kontrol eden sınıflardır. Bu sınıfların detayları bu dökümanın kapsamı dışındadır. Bu kontrolcülerin hangilerinin çalışacağı, doğrulama politika dosyası aracılığıyla belirlenir. Sertifika doğrulama işleminde gerçekleştirilen ve RFC 5280'de tanımlanan kontrolcüler temel olarak şunlardır;

Yapısal kontroller, sertifikanın ve SİL'in üzerindeki bilgilerin içerik ve biçimsel olarak geçerliliğinin kontrollerini kapsar. Temel olarak aşağıdaki gibi listelenebilir

• Seri Numarası Kontrolü : Sertifika üzerindeki seri numarasının pozitif bir tamsayı olduğunun kontrolü.
• Sertifika Geçerlilik Tarihi Kontrolü :Sertifika üzerindeki geçerlilik tarihlerinin doğrulama zamanını kapsadığının kontrolü.
• Versiyon Kontrolü : Sertifika üzerindeki versiyon bilgisinin geçerliliğinin kontrolü.
• Eklenti Kontrolü :Sertifika üzerindeki eklentilerin geçerliliğinin kontrolü.
• İmza Algoritması Kontrolü :Sertifika üzerinde yazan imza algoritmasının imzalanmış imza algoritması bilgisiyle aynı olması kontrolü.

Zincir İlişkisi kontrolleri, sertifika veya SİL ile bu seritifika veya SİL'i yayınlayan yetkili makam sertifikası arasındaki ilişkiyi inceleyen kontrolleri içerir.

• İsim Kontrolü:Sertifika veya SİL üzerindeki yayıncı(issuer) alanı ile yayıncı sertifikası üzerindeki özne(subject) alanının aynı olduğunun kontrolü.
• İmza Kontrolü :Sertifika veya SİL üzerindeki imzanın yayınlayan sertifikasındaki açık anahtar ile kriptografik olarak doğrulanması.
• Temel Kısıtlar Kontrolü :Yayıncı sertifikası üzerinde Temel Kısıtlar (Basic Constraints) eklentisinin bulunduğu ve bu eklentideki yayıncı işaretçisinin RFC 5280'de belirtildiği şekilde yer aldığı kontrolü.
• Anahtar Tanımlayıcısı Kontrolü :Sertifika veya SİL üzerindeki yetkili anahtar tanımlayıcısı (Authorithy Key Identifier) eklentisindeki değer ile yayıncı sertifikasındaki anahtar tanımlayıcısı değerinin uyuşması kontrolü.
• Yol Uzunluğu Kontrolü:Sertifika zincirinin uzunluğunun, yayıncı sertifikasındaki yol uzunluğu eklentisinde yer alan değerden uzun olmaması kontrolü.
• Anahtar Kullanımı Kontrolü:Yayıncı sertifikasındaki anahtar kullanımı (Key Usage) eklentisinde sertifika imzalama özelliğinin bulunması kontrolü.

Sertifikanın iptal durumu kontrollerini içerir.

• SİL'den İptal Durumu Kontrolü :Sertifikaya ilişkin SİL'den sertifikanın iptal durumunun kontrolü.
• OCSP'den İptal Durumu Kontrolü :Sertifikaya ilişkin OCSP cevabından sertifikanın iptal durumunun kontrolü.

Sertifika'daki özne bilgisi yayıncı sertifikasında yer alan isim kısıtlamaları eklentisinde tanımlı bir takım kurallara göre değerler alabilir. Bu detaylar RFC 5280'de belirtilmiştir ve isim kontrolleri kapsamında bu kurallara uyulup uyulmadığı kontrol edilmektedir.

Sertifikadaki politika bilgileri eklentisinde yer alan politika bilgileri, yayıncı sertifikasındaki isim kısıtlamaları eklentisinde tanımlı bir takım kurallara göre değerler alabilir. Bu detaylar RFC 5280'de belirtilmiştir ve politika kontrolleri kapsamında bu kurallara uyulup uyulmadığı kontrol edilmektedir.

Esya Sertifika Doğrulama API'sinde tanımlı ve politika dosyasında kullanılabilecek tüm kontrolcülerin listesi Table 1'de yer almaktadır.

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.

Örnek Sertifika Doğrulama Politikası Dosyası

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 güvenilir(kök) sertifika ayarları 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/Code/Java/Securit/ExampleofusingPBEwithaPBEParameterSpec.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.