Bir örnekle açıklayayım.
Normal anahtar çifti tabanlı PKI'da, özel anahtar ve genel anahtar vardır.
Sertifika tabanlı bir sistemde, özel anahtar ve sertifika vardır. Sertifika, genel anahtardan daha fazla bilgi tutar.
Demo (Bir sertifika ve özel anahtar oluşturabilirsiniz): http://www.selfsignedcertificate.com/
Özel anahtar dosyasını ve sertifika dosyasını açabilirsiniz, sertifika dosyasının aşağıda gösterildiği gibi birçok bilgi içerdiğini görebilirsiniz.
Bu siteden oluşturulan sertifikanızı (bir metin editörünün açılmasıyla) ve özel anahtarla (bir metin editörünün açılmasıyla) bu siteden eşleştirebilirsiniz: https://www.sslshopper.com/certificate-key-matcher.html
Sertifika müşterinin özel anahtarıyla eşleşiyorsa, müşterinin o sertifikanın müşteri tarafından verildiğinden veya müşterinin güvenilir aracısı (CA) tarafından verildiğinden emin olun.
Ancak, yalnızca özel anahtar ve sertifika tabanlı iletişimde sorunlar vardır .
Çünkü, herkes kendi sertifikasını ve özel anahtarını oluşturabilir, bu nedenle basit bir el sıkışma sunucuyla ilgili olarak, sunucunun sertifikanın genel anahtarıyla eşleşen özel anahtarı bilmesi dışında hiçbir şey kanıtlamaz. Bu problemi çözmek için bir yolu istemci sahip olmasıdır kümesi o güvendiği bir veya birden fazla sertifika. Sertifika sette değilse, sunucuya güvenilmemelidir .
Bu basit yaklaşımın birkaç dezavantajı vardır. Sunucular, sertifikadaki genel anahtarı yenisiyle değiştiren, zaman içinde daha güçlü anahtarlara ("anahtar döndürme") yükseltme yapabilmelidir. Maalesef, şimdi istemci uygulamasının esasen sunucu yapılandırma değişikliği nedeniyle güncellenmesi gerekiyor. Sunucu özellikle uygulama geliştiricisinin kontrolü altında değilse, örneğin bir üçüncü taraf web hizmeti ise bu özellikle sorunludur. Bu yaklaşım, uygulamanın bir web tarayıcısı veya e-posta uygulaması gibi rastgele sunucularla konuşması durumunda da sorunlara neden olur.
Bu dezavantajları ele almak için, sunucular tipik olarak Sertifika Yetkilileri (CA) adı verilen tanınmış sağlayıcıların sertifikalarıyla yapılandırılır. Ana bilgisayar platformu (istemci) genellikle güvendiği tanınmış CA'ların bir listesini içerir. Bir sunucuya benzer şekilde, CA'nın bir sertifikası ve özel bir anahtarı vardır. Bir sunucuya sertifika verirken, CA sunucu sertifikasını özel anahtarını kullanarak imzalar. İstemci daha sonra, sunucunun platform tarafından bilinen bir CA tarafından verilen bir sertifikaya sahip olduğunu doğrulayabilir.
Bununla birlikte, bazı problemleri çözerken, CA'ları kullanmak bir tane daha sunar. CA, birçok sunucu için sertifika verdiğinden, istediğiniz sunucuyla konuştuğunuzdan emin olmak için hala bir yol gerekir. Bunu ele almak için CA tarafından verilen sertifika, sunucuyu ya gmail.com gibi belirli bir adla ya da * .google.com gibi joker karakterli bir ana bilgisayar grubunu tanımlar.
Aşağıdaki örnek, bu kavramları biraz daha somut hale getirecektir. Bir komut satırından aşağıdaki kod parçasında openssl aracının s_client komutu Wikipedia'nın sunucu sertifikası bilgilerine bakar. Bağlantı noktası 443'ü belirtir, çünkü HTTPS için varsayılandır. Komut, openssl s_client'in çıkışını, sertifikalar hakkındaki bilgileri X.509 standardına göre biçimlendiren openssl x509'a gönderir. Özellikle, komut, sunucu adı bilgisini içeren konuyu ve CA'yı tanımlayan yayıncıyı sorar.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
Sertifikanın * .wikipedia.org ile eşleşen sunucular için RapidSSL CA tarafından verilmiş olduğunu görebilirsiniz.
Gördüğünüz gibi, CA tarafından Sunuculara gönderilen bu ek bilgiler nedeniyle, müşteri sunucusuyla iletişim kurup kurmadığını kolayca anlayabilir.
