edilebilir, ancak tanınması durumunda işlenmelidir.

Versiyon 1'in yapısı RFC 1422'de verilmiştir.
ITU-T, bir süreden sonra verenin veya özne isminin yeniden kullanılmasına izin vermek için 2 numaralı sürümde veren ve özne benzersiz belirteçlerini tanıttı. Yeniden kullanım örneği, bir CA'nın iflas etmesi ve adının ülkenin genel listesinden silinmesidir. Bir süre sonra, aynı ada sahip başka bir CA, birincisi ile ilgisi olmamasına rağmen kendisini kaydedebilir. Ancak, IETF hiçbir veren ve özne isminin tekrar kullanılmasını önermemektedir. Bu nedenle, sürüm 2, Internet'te yaygın olarak kullanılmamaktadır.
Uzantılar versiyon 3'te tanıtıldı. Bir CA, yalnızca belirli bir amaç için bir sertifika vermek için uzantıları kullanabilir (örneğin, yalnızca dijital nesneleri imzalamak için).

Tüm sürümlerde, seri numarası, belirli bir CA tarafından verilen her sertifika için benzersiz olmalıdır (RFC 5280'de belirtildiği gibi).

RFC 5280 (ve öncülleri), sertifikanın nasıl kullanılması gerektiğini gösteren bir dizi sertifika uzantısı tanımlar. Bunların büyük çoğunluğu joint-iso-ccitt(2) ds(5) id-ce(29) OID'den arklardır. Bölüm 4.2.1'de tanımlanan en yaygın olanlardan bazıları şunlardır:


Genel olarak, bir sertifikanın kullanımını kısıtlayan çeşitli uzantıları varsa, belirli bir kullanım için gereken tüm kısıtlamaların uygun olması gerekir. RFC 5280, hem keyUsage (anahtar kullanımı) hem de extendedKeyUsage (genişletilmiş anahtar kullanımı) öğelerini içeren bir sertifikanın belirli bir örneğini verir: bu durumda, her ikisi de işlenmeli ve sertifika yalnızca her iki uzantı bir sertifikanın kullanımını belirlerken tutarlı ise kullanılabilir. Örneğin, NSS (network security services) sertifika kullanımını belirtmek için her iki uzantıyı kullanır.

X.509 sertifikaları için yaygın olarak kullanılan birkaç dosya adı uzantısı vardır. Maalesef, bu uzantılardan bazıları özel anahtarlar gibi diğer veriler için de kullanılmaktadır.


PKCS#7, veriyi imzalamak veya şifrelemek için bir standarttır. Sertifika, imzalanmış verileri doğrulamak için gerekli olduğundan, bunları SignedData yapısına dahil etmek mümkündür. Bir.P7C dosyası imzalanacak herhangi bir veri olmadan, dejenere bir SignedData yapısıdır.
PKCS#12, kişisel bilgi alışverişi (PFX) standardından evrildi ve tek bir dosyada açık ve özel nesneleri değiştirmek için kullanıldı.

Sertifika zinciri (RFC 5280 tarafından tanımlanan "sertifika yolu" eşdeğer kavramına bakınız) aşağıdaki özelliklere sahip bir veya daha fazla CA sertifikası (genellikle sonuncusu kendinden imzalı bir sertifikadır) tarafından takip edilen sertifikaların listesidir (genellikle bir son varlık sertifikası ile başlıyor):


Sertifika zincirleri, bir hedef sertifikada (zincirdeki ilk sertifika) yer alan açık anahtarın (PK) ve içerdiği diğer verilerin etkin bir şekilde özneye ait olup olmadığını kontrol etmek için kullanılır. Bunu doğrulamak için, hedef sertifikanın üzerindeki imza, bir sonraki sertifikanın içerdiği PK kullanılarak, ki onun imzası da ondan sonraki sertifika kullanılarak doğrulanmış, zincirdeki son sertifikaya ulaşılana kadar doğrulanır. Son sertifika bir güvenilir bağlantı olduğundan, başarılı bir şekilde ulaşılması hedef sertifikanın güvenilir olduğunu kanıtlayacaktır.

Önceki paragraftaki açıklama, RFC 5280 tarafından tanımlanan sertifika yolu doğrulama süreci (sertifikalarda geçerlilik tarihlerinin doğrulanması, CRL'lerin aranması vb. gibi ek kontroller içeren) hakkında basitleştirilmiş bir görünümdür.
Sertifika zincirlerinin nasıl oluşturulduğunu ve doğrulandığını inceleyerek, somut bir sertifikanın çok farklı sertifika zincirlerinin (hepsi geçerli) bir parçası olabileceğine dikkat edilmelidir. Bunun nedeni, aynı özne ve açık anahtar için birkaç CA sertifikası oluşturulabilmesi, ancak farklı özel anahtarlarla (farklı CA'lardan veya aynı CA'dan farklı özel anahtarlardan) imzalanabilmesidir. Dolayısıyla, tek bir X.509 sertifikasının yalnızca bir veren ve bir CA imzası olsa da, tamamen farklı sertifika zincirleri oluşturarak birden fazla sertifikaya bağlanabilir. Bu PKI'lar ve diğer uygulamalar arasında çapraz sertifikasyon için çok önemlidir.
Aşağıdaki örneklere bakınız.

Bu şemalarda:


PKI 2'de ("Kullanıcı 2" gibi) bulunan kullanıcı sertifikalarının PKI 1 tarafından güvenilmesini sağlamak için CA1, CA2'nin açık anahtarını içeren bir sertifika (cert2.1) oluşturur.
Şimdi hem "cert2 hem de cert2.1 (yeşil) aynı özneye ve açık anahtara sahiptir, bu nedenle cert2.2 (Kullanıcı 2) için iki geçerli zincir vardır: " cert2.2 → cert2 "ve" cert2.2 → cert2. 1 → cert1".

Benzer şekilde, CA2, CA1'in açık anahtarını içeren bir sertifika (cert1.1) oluşturabilir, böylece PKI 1'de ("Kullanıcı 1" gibi) bulunan kullanıcı sertifikaları PKI 2 tarafından güvenilir hale gelir.

Hem cert1 hem de cert3 aynı açık anahtarı (eskisinden) içerdiğinden, cert5 için iki geçerli sertifika zinciri vardır: "cert5 → cert1" ve "cert5 → cert3 → cert2" ve cert6 için de benzer şekildedir. Bu, eski kullanıcı sertifikalarının (cert5 gibi) ve yeni sertifikaların (cert6 gibi) yeni CA anahtarlarına geçiş sırasında yeni kök CA sertifikasına sahip olan veya güvenilen bağlantı olarak eski tarafa kayıtsız bir şekilde güvenebilmesini sağlar.

Bu, wikipedia.org ve diğer bazı Wikipedia web siteleri tarafından kullanılan kodu çözülmüş bir X.509 sertifikası örneğidir. Veren alanında belirtildiği gibi GlobalSign tarafından verilmiştir. Özne alanı Wikipedia'yı bir kurum olarak tanımlar ve Özne Alternatif Adı alanı, kullanılabileceği ana makine adlarını açıklar. Özne Açık Anahtar Bilgisi alanında bir ECDSA açık anahtarı bulunur, alt kısımdaki imza ise GlobalSign'ın RSA özel anahtarı ile oluşturulmuştur.

 Certificate:
Bu son varlık sertifikasını doğrulamak için, Veren ve Yetkili Anahtar Tanımlayıcısı ile eşleşen bir ara sertifikaya ihtiyaç vardır:

TLS bağlantısında, uygun şekilde yapılandırılmış bir sunucu, ara bağlantıyı el sıkışmasının bir parçası olarak sağlayacaktır. Ancak, ara sertifikayı son varlık sertifikasından "CA Verenleri (Issuers)" URL'sini getirerek de almak mümkündür.

Bu, bir sertifika yetkilisine ait bir ara sertifikanın örneğidir. Bu sertifika, yukarıdaki son varlık sertifikasını imzaladı ve aşağıdaki kök sertifika tarafından imzalandı. Bu ara sertifikanın özne alanı, imzaladığı son varlık sertifikasının veren alanı ile eşleşmektedir. Ayrıca, aradaki "özne anahtar tanımlayıcısı" alanı, son varlık sertifikasındaki "yetki anahtarı tanımlayıcısı" alanıyla eşleşir.

Bu, bir sertifika yetkilisini temsil eden, kendinden imzalı bir kök sertifika örneğidir. Veren ve özne alanları aynıdır ve imzası kendi açık anahtarı ile doğrulanabilir. Güven zincirinin geçerliliği burada bitmelidir. Doğrulama programının güven deposunda bu kök sertifika varsa, son varlık sertifikası TLS bağlantısında kullanılmak üzere güvenilir kabul edilebilir. Aksi takdirde, son varlık sertifikası güvenilmez olarak kabul edilir.

Bruce Schneier, Peter Gutmann ve diğer güvenlik uzmanları tarafından PKI sorunları hakkında bir dizi yayın vardır.



Gerçeklemeler tasarım kusurları, hatalar, standartların farklı yorumları ve farklı standartların birlikte çalışmamasının eksikliğinden muzdariptir. Bazı problemler:

Dijital imza sistemleri çalışmak için kriptografik özet fonksiyonlarına ihtiyaç duyar. Açık anahtar altyapısı artık güvenli olmayan bir özet fonksiyonu kullanılmasına izin verdiğinde, bir saldırgan sertifikaları oluşturmak için özet fonksiyonundaki zayıflıkları kullanabilir. Özellikle, bir saldırgan özet çakışması üretebiliyorsa, bir CA'yı zararsız içerikli bir sertifikayı imzalamaya ikna edebilirler; ve bu içeriğin özeti, saldırganın seçtiği değerlerle oluşturduğu bir başka, kötü niyetli sertifika içeriğinin özetiyle özdeştir. Saldırgan daha sonra CA tarafından sağlanan imzayı kötü amaçlı sertifika içeriğine ekleyebilir ve CA tarafından imzalanmış gibi görünen kötü amaçlı bir sertifikayla sonuçlanabilir. Kötü niyetli sertifika içerikleri yalnızca saldırgan tarafından seçildiğinden, zararsız sertifikadan farklı geçerlilik tarihleri veya ana bilgisayar adlarına sahip olabilirler. Kötü amaçlı sertifika, daha güvenilir sertifikalar verebilecek bir "CA: true" alanı bile içerebilir.


X.509 imzalarını oluşturmak için özet çarpışması kullanmak, saldırganın sertifika yetkilisinin imzalayacağı verileri tahmin edebilmesini gerektirir. Bu, CA tarafından imzalanan sertifikalarda, tipik olarak seri numarasında rastgele bir bileşen üreterek hafifletilebilir. CA/Browser Forum, 2011'den bu yana Baseline Requirements Section 7.1'de seri numarası entropisine ihtiyaç duymuştur.

1 Ocak 2016 itibariyle, Temel Koşul Gereksinimleri, SHA-1 kullanan sertifikaların verilmesini yasaklamıştır. 2017'nin başından itibaren, Chrome ve Firefox, SHA-1 kullanan sertifikaları reddetmiştir. Mayıs 2017 itibariyle hem Edge hem de Safari , SHA-1 sertifikasını reddetmiştir. Tarayıcı olmayan X.509 doğrulayıcıları, SHA-1 sertifikalarını henüz reddetmiyor.


1995 yılında, Ulusal Standartlar ve Teknoloji Enstitüsü ile birlikte İnternet Mühendisliği Görev Gücü, Açık Anahtar Altyapısı (X.509) çalışma grubunu oluşturdu. Haziran 2014'te  sonuçlanan çalışma grubu, genellikle "PKIX" olarak adlandırılmaktadır. X.509'un kullanımının dağıtılmasının ile ilgili RFC'ler ve diğer standartlar belgeler oluşturuldu. Özellikle, Internet protokollerinde X.509'un nasıl kullanılacağını tanımlayan RFC 3280 ve onun halefi RFC 5280 üretildi.

TLS/SSL ve HTTPS, S/MIME (Güvenli Çok Amaçlı Internet Posta Uzantıları) ve WiFi kimlik doğrulaması için EAP-TLS yöntemi X.509'un RFC 5280 profilini kullanır. SMTP, POP, IMAP, LDAP, XMPP ve daha fazlası gibi TLS kullanan herhangi bir protokol, doğal olarak X.509'u kullanır. IPsec, RFC 4945'te tanımlanan kendi X.509 profilini kullanır.

OpenCable güvenlik belirtimi, kablo sektöründe kullanılmak üzere X.509'un kendi profilini tanımlar.

Akıllı kartlar ve TPM'ler gibi cihazlar genellikle kendilerini veya sahiplerini tanımlamak için sertifikalar taşırlar. Bu sertifikalar X.509 biçimindedir.

WS-Security s