X.509

Vikipedi, özgür ansiklopedi

İnternet güvenlik
protokolleri
Anahtar yönetimi
Uygulama katmanı
Domain Name System
İnternet Katmanı

Kriptografide, X.509 açık anahtar sertifikalarının formatını tanımlayan bir standarttır. X.509 sertifikaları, internette gezinmek için güvenli protokol olan HTTPS'nin temeli olan TLS/SSL dahil olmak üzere birçok internet protokolünde kullanılmaktadır. Elektronik imzalar gibi çevrimdışı uygulamalarda da kullanılırlar. Bir X.509 sertifikası bir açık anahtar ve bir kimlik (bir ana bilgisayar adı veya bir kuruluş veya bir birey) içerir ve bir sertifika yetkilisi tarafından imzalanır veya kendinden imzalı olarak imzalanır. Sertifika güvenilir bir sertifika yetkilisi tarafından imzalandığında veya başka yollarla doğrulandığında, bu sertifikayı tutan biri, başka bir tarafla güvenli iletişim kurmak için sertifikanın içerdiği açık anahtara güvenebilir veya ilgili özel anahtar ile dijital olarak imzalanmış belgeleri doğrulayabilir.

Sertifikaların formatının yanı sıra, X.509 artık geçerli olmayan sertifikalar hakkında bilgi dağıtmak için sertifika iptal listelerini ve sertifikaların, diğer sertifikalar tarafından imzalanan ve sonunda bir güvenilir bağlantıya ulaşan ara sertifika yetkilisi sertifikaları tarafından imzalanmasını sağlayan bir sertifika yolu doğrulama algoritmasını belirtir.

X.509, Uluslararası Telekomünikasyon Birliği Standardizasyon sektörü (ITU-T) tarafından tanımlanmıştır ve bir başka ITU-T standardı olan ASN.1'e dayanmaktadır.

Tarihi ve Kullanımı[değiştir | kaynağı değiştir]

X.509, başlangıçta 3 Temmuz 1988'de yayınlandı ve X.500 standardı ile birlikte başlatıldı. Sertifika vermek için sertifika yetkililerinin sıkı bir hiyerarşik sistemi olduğunu varsayar. Bu, herkesin (sadece özel sertifika yetkililerinin değil) imzalayabileceği ve dolayısıyla başkalarının anahtar sertifikalarının geçerliliğini onaylayabileceği PGP gibi güven ağı modelleri ile çelişir. X. 509'un 3. versiyonu, ağ köprüleri ve örgü topolojileri[1] gibi diğer topolojileri destekleme esnekliğini içerir. Eşler arası, OpenPGP benzeri bir güven ağında kullanılabilir, ancak 2004'ten bu yana nadiren kullanılmıştır. X.500 sistemi sadece devlet kimliği bilgi paylaşımı antlaşması yerine getirilmesi amacıyla egemen ülkeler tarafından uygulanmıştır ve IETF'nin açık anahtar altyapısı (X.509), veya PKIX, çalışma grubu, standardı İnternet'in daha esnek bir örgütleşimine uyarlamıştır. Aslında, X.509 sertifikası genellikle IETF'nin PKIX sertifikasına ve RFC 5280'de belirtilen ve genellikle Açık Anahtar Altyapısı (X.509) a karşılık olarak PKIX olarak adlandırılan X.509 v3 sertifika standardının sertifika iptal listesi profiline refere eder.

Sertifikalar[değiştir | kaynağı değiştir]

X.509 sisteminde, imzalı bir sertifika isteyen bir kuruluş bir sertifika imzalama isteği yoluyla bir tane ister.

Bunu yapmak için, önce bir anahtar çifti oluşturur, özel anahtarı gizli tutar ve sertifika imzalama isteğini imzalamak için kullanır. Bu başvuru sahibini ve başvuru sahibinin sertifika imzalama isteğinin imzasını ve sertifikanın verildiği Distinguished Name (DN)'i doğrulamak için kullanılacak açık anahtarını tanımlayan bilgiyi içerir. Sertifika imzalama isteğine sertifika yetkilisi tarafından talep edilen diğer kimlik belgeleri veya kimlik kanıtları eşlik edebilir.

Sertifika yetkilisi, belirli bir ayırt edici isme açık bir anahtarı ilişkilendiren bir sertifika verir.

Bir kuruluşun güvenilen kök sertifikaları, tüm çalışanlara şirket PKI sistemini kullanabilmeleri için dağıtılabilir. Internet Explorer, Firefox, Opera, Safari ve Chrome gibi tarayıcılar önceden kurulmuş olan önceden belirlenmiş bir kök sertifika seti ile birlikte gelir, böylece büyük sertifika yetkililerinden SSL sertifikaları anında çalışır; Aslında tarayıcıların geliştiricileri, tarayıcıların kullanıcıları için hangi sertifika yetkililerinin güvenilir üçüncü taraf olduğunu belirler. Örneğin, Firefox, dahil edilen sertifika yetkililerinin listesini içeren bir CSV ve / veya HTML dosyası sağlar.[2] X.509 ve RFC 5280 ayrıca sertifika iptal listesi (CRL) uygulamaları için standartlar içerir. Sertifikanın geçerliliğini kontrol etmenin başka bir IETF onaylı yolu da, Çevrimiçi Sertifika Durum Protokolüdür (OCSP). Firefox 3 en az Vista ve sonrası Windows sürümlerinde olduğu gibi, OCSP'nin varsayılan olarak denetlenmesini sağlar.[3]

Sertifika yapısı[değiştir | kaynağı değiştir]

Standartların öngördüğü yapı, resmi bir dilde ifade edilmiştir, Abstract Syntax Notation One (ASN.1).

X.509 v3 dijital sertifikasının yapısı aşağıdaki gibidir:

  • Sertifika
    • Versiyon numarası
    • Seri Numarası
    • İmza Algoritması Kimliği
    • Verenin Adı
    • Geçerlilik süresi
      • Önce değil
      • Sonra değil
    • Özne ismi
    • Özne Açık Anahtar Bilgisi
      • Açık Anahtar Algoritması
      • Özne Açık Anahtarı
    • Verenin Benzersiz Belirteci (isteğe bağlı)
    • Öznenin Benzersiz Belirteci (isteğe bağlı)
    • Uzantıları (isteğe bağlı)
      • ...
  • Sertifika İmza Algoritması
  • Sertifika İmzası

Her bir uzantı, kritik veya kritik olmayan bir göstergeyle birlikte bir değer kümesi olan nesne tanımlayıcısı olarak ifade edilen kendi kimliğine sahiptir. Sertifika kullanan bir sistem, tanımadığı kritik bir uzantıyla veya işleyemediği bilgileri içeren kritik bir uzantıyla karşılaşırsa o sertifikayı reddetmelidir. Kritik olmayan bir uzantı tanınmıyorsa göz ardı edilebilir, ancak tanınması durumunda işlenmelidir.[4]

Versiyon 1'in yapısı RFC 1422'de verilmiştir.[5]

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).

Sertifikanın belirli bir kullanımını bildiren uzantılar[değiştir | kaynağı değiştir]

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:

  • Temel Kısıtlamalar, { id-ce 19 },[6] sertifikanın bir CA'ya ait olup olmadığını belirtmek için kullanılır.
  • Anahtar Kullanımı, { id-ce 15 },[7] sertifikada bulunan açık anahtar kullanılarak gerçekleştirilebilecek şifreleme işlemlerini belirten bir bitmap sağlar; örneğin, anahtarın imzalar için kullanılması gerektiğini, ancak şifreleme için kullanılmaması gerektiğini gösterebilir.
  • Genişletilmiş Anahtar Kullanımı, { id-ce 37 },[8] genellikle sertifikanın içerdiği açık anahtarın amacını belirtmek için bir yaprak sertifikasında kullanılır. Her biri izin verilen kullanımı gösteren OID'lerin bir listesini içerir. Örneğin, { id-pkix 3 1 } anahtarın TLS veya SSL bağlantısının sunucu ucunda kullanılabileceğini gösterir; { id-pkix 3 4 } anahtarın e-posta güvenliğini sağlamak için kullanılabileceğini gösterir.

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.[9]

Sertifika dosya adı uzantıları[değiştir | kaynağı değiştir]

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.

  • .pem – (Privacy-enhanced Electronic Mail) "-----BEGIN CERTIFICATE-----" ve "-----END CERTIFICATE-----" arasında Base64 kodlanmış DER sertifikası
  • .cer, .crt, .der – genellikle ikili DER formundadır , ancak Base64 kodlu sertifikalar da yaygındır.
  • .p7b, .p7c – PKCS#7 Verisiz SignedData yapısı, sadece sertifika(lar) veya sertifika iptal listesi ya da listeleri
  • .p12 – PKCS#12, sertifika(lar) (açık) ve özel anahtarlar (şifre korumalı) içerebilir
  • .pfx – PFX, PKCS#12'nin öncülüdür ve genellikle PKCS #12 biçimindeki verileri içerir, örn. IIS'de oluşturulan PFX dosyaları

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 zincirleri ve çapraz sertifikasyon[değiştir | kaynağı değiştir]

Sertifika zinciri (RFC 5280 tarafından tanımlanan "sertifika yolu" eşdeğer kavramına bakınız)[10] 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):

  1. Her sertifikanın Veren'i (sonuncusu hariç) listedeki bir sonraki sertifikanın Özne'si ile eşleşir.
  2. Her sertifikanın (sonuncusu hariç) zincirdeki bir sonraki sertifikaya karşılık gelen özel anahtar tarafından imzalanması gerekir. (yani bir sertifikanın imzası kendini takip eden sertifikada yer alan özel anahtar kullanılarak doğrulanabilir.)
  3. Listedeki son sertifika bir güven bağlayıcısıdır ve bazı güvenilir prosedürlerle size teslim edildiği için güvendiğiniz bir sertifikadır.

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ı gibi ek kontroller içeren) hakkında basitleştirilmiş bir görünümdür.

Örnek 1: İki PKI arasında çapraz sertifikasyon
Örnek 2: CA sertifikası yenileme

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.[11] Aşağıdaki örneklere bakınız.

Bu şemalarda:

  • Her kutu, öznesi kalın harflerle yazılmış bir sertifikayı temsil eder.
  • A → B, "A, B tarafından imzalanır" anlamına gelir (veya daha kesin olarak, "A, B içinde bulunan açık anahtara karşılık gelen özel anahtar tarafından imzalanır").
  • Aynı renkteki (beyaz/şeffaf olmayan) sertifikalar aynı açık anahtarı içerir.

Örnek 1: İki PKI arasında kök sertifika yetkilisi (CA) düzeyinde çapraz sertifikasyon[değiştir | kaynağı değiştir]

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.[12] Ş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.

Örnek 2: CA sertifikası yenileme[değiştir | kaynağı değiştir]

Understanding Certification Path Construction (PDF). PKI Forum. Eylül 2002. 4 Şubat 2019 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 7 Nisan 2018. To allow for graceful transition from the old signing key pair to the new signing key pair, the CA should issue a certificate that contains the old public key signed by the new private signing key and a certificate that contains the new public key signed by the old private signing key. Both of these certificates are self-issued, but neither is self-signed. Note that these are in addition to the two self-signed certificates (one old, one new). 

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.[13]

Örnek X.509 sertifikaları[değiştir | kaynağı değiştir]

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.

Son varlık sertifikası[değiştir | kaynağı değiştir]

Certificate:     Data:         Version: 3 (0x2)         Serial Number:             10:e6:fc:62:b7:41:8a:d5:00:5e:45:b6     Signature Algorithm: sha256WithRSAEncryption         Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2         Validity             Not Before: Nov 21 08:00:00 2016 GMT             Not After : Nov 22 07:59:59 2017 GMT         Subject: C=US, ST=California, L=San Francisco, O=Wikimedia Foundation, Inc., CN=*.wikipedia.org         Subject Public Key Info:             Public Key Algorithm: id-ecPublicKey                 Public-Key: (256 bit)                 pub:                      04:c9:22:69:31:8a:d6:6c:ea:da:c3:7f:2c:ac:a5:                     af:c0:02:ea:81:cb:65:b9:fd:0c:6d:46:5b:c9:1e:                     ed:b2:ac:2a:1b:4a:ec:80:7b:e7:1a:51:e0:df:f7:                     c7:4a:20:7b:91:4b:20:07:21:ce:cf:68:65:8c:c6:                     9d:3b:ef:d5:c1                 ASN1 OID: prime256v1                 NIST CURVE: P-256         X509v3 extensions:             X509v3 Key Usage: critical                 Digital Signature, Key Agreement             Authority Information Access:                  CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt                 OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2              X509v3 Certificate Policies:                  Policy: 1.3.6.1.4.1.4146.1.20                   CPS: https://www.globalsign.com/repository/                 Policy: 2.23.140.1.2.2              X509v3 Basic Constraints:                  CA:FALSE             X509v3 CRL Distribution Points:                   Full Name:                   URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl              X509v3 Subject Alternative Name:                  DNS:*.wikipedia.org, DNS:*.m.mediawiki.org, DNS:*.m.wikibooks.org, DNS:*.m.wikidata.org, DNS:*.m.wikimedia.org, DNS:*.m.wikimediafoundation.org, DNS:*.m.wikinews.org, DNS:*.m.wikipedia.org, DNS:*.m.wikiquote.org, DNS:*.m.wikisource.org, DNS:*.m.wikiversity.org, DNS:*.m.wikivoyage.org, DNS:*.m.wiktionary.org, DNS:*.mediawiki.org, DNS:*.planet.wikimedia.org, DNS:*.wikibooks.org, DNS:*.wikidata.org, DNS:*.wikimedia.org, DNS:*.wikimediafoundation.org, DNS:*.wikinews.org, DNS:*.wikiquote.org, DNS:*.wikisource.org, DNS:*.wikiversity.org, DNS:*.wikivoyage.org, DNS:*.wiktionary.org, DNS:*.wmfusercontent.org, DNS:*.zero.wikipedia.org, DNS:mediawiki.org, DNS:w.wiki, DNS:wikibooks.org, DNS:wikidata.org, DNS:wikimedia.org, DNS:wikimediafoundation.org, DNS:wikinews.org, DNS:wikiquote.org, DNS:wikisource.org, DNS:wikiversity.org, DNS:wikivoyage.org, DNS:wiktionary.org, DNS:wmfusercontent.org, DNS:wikipedia.org             X509v3 Extended Key Usage:                  TLS Web Server Authentication, TLS Web Client Authentication             X509v3 Subject Key Identifier:                  28:2A:26:2A:57:8B:3B:CE:B4:D6:AB:54:EF:D7:38:21:2C:49:5C:36             X509v3 Authority Key Identifier:                  keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C      Signature Algorithm: sha256WithRSAEncryption          8b:c3:ed:d1:9d:39:6f:af:40:72:bd:1e:18:5e:30:54:23:35:          ...

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:

Issuer C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
Authority Key Identifier 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

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.

Ara sertifika[değiştir | kaynağı değiştir]

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. 

Certificate:     Data:         Version: 3 (0x2)         Serial Number:             04:00:00:00:00:01:44:4e:f0:42:47     Signature Algorithm: sha256WithRSAEncryption         Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA         Validity             Not Before: Feb 20 10:00:00 2014 GMT             Not After : Feb 20 10:00:00 2024 GMT         Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2         Subject Public Key Info:             Public Key Algorithm: rsaEncryption                 Public-Key: (2048 bit)                 Modulus:                     00:c7:0e:6c:3f:23:93:7f:cc:70:a5:9d:20:c3:0e:                     ...                 Exponent: 65537 (0x10001)         X509v3 extensions:             X509v3 Key Usage: critical                 Certificate Sign, CRL Sign             X509v3 Basic Constraints: critical                 CA:TRUE, pathlen:0             X509v3 Subject Key Identifier:                 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C             X509v3 Certificate Policies:                 Policy: X509v3 Any Policy                   CPS: https://www.globalsign.com/repository/              X509v3 CRL Distribution Points:                  Full Name:                   URI:http://crl.globalsign.net/root.crl              Authority Information Access:                 OCSP - URI:http://ocsp.globalsign.com/rootr1              X509v3 Authority Key Identifier:                 keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B      Signature Algorithm: sha256WithRSAEncryption          46:2a:ee:5e:bd:ae:01:60:37:31:11:86:71:74:b6:46:49:c8:          ...

Kök sertifikası[değiştir | kaynağı değiştir]

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. 

Certificate:     Data:         Version: 3 (0x2)         Serial Number:             04:00:00:00:00:01:15:4b:5a:c3:94     Signature Algorithm: sha1WithRSAEncryption         Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA         Validity             Not Before: Sep  1 12:00:00 1998 GMT             Not After : Jan 28 12:00:00 2028 GMT         Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA         Subject Public Key Info:             Public Key Algorithm: rsaEncryption                 Public-Key: (2048 bit)                 Modulus:                     00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:                     ...                 Exponent: 65537 (0x10001)         X509v3 extensions:             X509v3 Key Usage: critical                 Certificate Sign, CRL Sign             X509v3 Basic Constraints: critical                 CA:TRUE             X509v3 Subject Key Identifier:                  60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B     Signature Algorithm: sha1WithRSAEncryption          d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:          ...

Güvenlik[değiştir | kaynağı değiştir]

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

Mimari zayıflıkları[değiştir | kaynağı değiştir]

  • Kara listeye alınan geçersiz sertifikaların kullanımı (CRL ve OCSP kullanarak),
    • İstemci yalnızca CRL'ler mevcut olduğunda sertifikalara güveniyorsa, PKI'yi cazip hale getiren çevrimdışı yeteneklerini kaybederler. Bu nedenle çoğu istemci CRL'ler mevcut olmadığında sertifikalara güvenir, ancak bu durumda iletişim kanalını kontrol eden bir saldırgan CRL'leri devre dışı bırakabilir. Google'dan Adam Langley, kısmi başarısız CRL kontrollerinin, bir kaza geçirdiğiniz zamanlar dışında çalışan bir emniyet kemeri gibi olduğunu söylemiştir.[17]
  • Büyük boyutlar ve kıvrık dağıtım modelleri nedeniyle CRL'ler zayıf bir seçim olması,
  • Belirsiz OCSP semantiği ve geçmişteki iptal durumunun eksikliği,
  • Kök sertifikaların iptalinin ele alınmaması,
  • Toplama sorunu: Kimlik hak talepleri (bir tanımlayıcıyla kimlik doğrulaması), özellik talepleri (bir miktar onaylanmış özellik sunumu) ve politika talepleri tek bir kapsayıcıda birleştirilir. Bu gizlilik, politika eşleme ve bakım sorunlarını artırır.
  • Yetkilendirme sorunu: CA'lar, alt CA'ların sınırlı ad alanlarının veya özellik kümelerinin dışındaki sertifikaların yayınlanmasını teknik olarak engelleyemez; X.509'un bu özelliği kullanımda değil. Bu nedenle, İnternet'te çok sayıda CA var ve bunları ve politikalarını sınıflandırmak başa çıkılmaz bir görevdir. Bir kurumda yetki devri alelade bir iş uygulamasında olduğu gibi üstesinden gelinemez.
  • Federasyon sorunu: Alt CA'ların, köprü CA'larının ve çapraz imzalamanın sonucu olan sertifika zincirleri, işlem süresi açısından doğrulamayı karmaşık ve pahalı hale getirir. Yol doğrulama semantiği belirsiz olabilir. Güvenilir üçüncü taraflı hiyerarşi tek modeldir. İkili bir güven ilişkisi zaten mevcut olduğunda bu durum elverişsizdir.
  • Bir ana bilgisayar adı için bir Genişletilmiş Doğrulama (EV) sertifikası verilmesi aynı ana makine adı için geçerli olan daha düşük bir geçerlilik sertifikasının verilmesini engellemez. Bu şu anlama gelir ki EV'nin yüksek doğrulama seviyesi, ortadaki adam saldırılarına karşı koruma sağlamamaktadır.
    [18]

Sertifika yetkilileri ile ilgili sorunlar[değiştir | kaynağı değiştir]

  • Güvenen taraf değil, özne sertifika satın alır. Özne genellikle en ucuz sertifika veren kurumu kullanacak, dolayısıyla rekabet piyasasında kaliteye ödeme yapılmıyor. Bu kısmen Genişletilmiş Doğrulama sertifikaları tarafından ele alınmaktadır.
  • Sertifika yetkilileri kullanıcıya (özne veya güvenilir taraflar da dahil) neredeyse hiçbir garanti vermez.
  • Kullanım süresi bitimi anahtar gücünün yeterli olduğu süreyi sınırlamak için kullanılmalıdır. Bu parametre, sertifika yetkilileri tarafından müşteriye bir uzatma ücreti talep etmek için kötüye kullanılır. Bu, kullanıcıya süre uzatma gibi gereksiz bir yük getirir.
  • "Kullanıcılar, iptal edilmek üzere gerçek bir yol olmaksızın varolmayan bir dizinde belirsiz bir konumda yayınlanan bir sertifika almak için tanımlanmamış bir sertifika isteği protokolü kullanır.
  • Tüm işletmeler gibi, CA'lar da içinde bulundukları yasal yargı alanlarına tabidir ve yasal olarak müşterilerinin ve kullanıcılarının çıkarlarını tehlikeye atmak zorunda kalabilirler. İstihbarat kurumları, ortadaki adam saldırılarını yürütmek için DigiNotar gibi, CA'ların yasa dışı uzlaşma yoluyla verilen sahte sertifikalardan da yararlanmıştır. Bir başka örnek ise, 1 Ocak 2018 tarihinden itibaren başlayan ve Hollanda istihbarat ve güvenlik hizmetlerine yeni yetkiler veren Hollanda yasaları sayesinde Hollanda hükûmeti CA iptal talebi vermiştir.[19]

Uygulama sorunları[değiştir | kaynağı değiştir]

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

  • Birçok uygulama iptal onayını kapatır:
    • Engel olarak görülen politikalar uygulanmaz
    • Varsayılan olarak, kod imzalama dahil olmak üzere tüm tarayıcılarda açıksa, büyük olasılıkla altyapının çökmesine neden olur.
  • DN'ler karmaşıktır ve çok az anlaşılırlar (kanonikleşme eksikliği, uluslararasılaşma sorunları, ..)
  • rfc822Name'in iki gösterimi vardır.
  • İsim ve politika kısıtları pek desteklenmiyor
  • Anahtar kullanım yoksayıldı ve listedeki ilk sertifika kullanılıyor.
  • Özel OID'lerin uygulanması zor
  • Öznitelikleri kritik hale getirilmemelidir çünkü istemcileri çökertir.
  • Belirtilmemiş özelliklerin uzunluğu, ürüne özel sınırlara yol açar
  • X.509'da gerçekleme hataları vardır. Mesela geçersiz sonlandırılmış dizeleri[20] kullanarak sahte özne isimlerine izin verir veya sertifikalarda kod enjeksiyon saldırılarına izin verir.
  • Nesne belirleyicilerinin yasa dışı[21] 0x80 doldurulmuş alt tanımlayıcılarını, yanlış uygulamalarını veya istemcinin tarayıcılarının tam sayı taşmasını kullanarak, bir saldırgan, CA'nın imzalayacağı bilinmeyen bir öznitelik içerebilir ve bu da istemcinin "CN" olarak yanlış yorumladığı anlamına gelir. (OID=2.5.4.3). Dan Kaminsky at the 26th Chaos Communication Congress "Black OPs of PKI"[22]

Kriptografik zayıflıklar[değiştir | kaynağı değiştir]

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.

  • MD2 tabanlı sertifikalar uzun bir süredir kullanılmış ve önleyici saldırılara karşı savunmasız kalmıştır. Kök sertifika zaten kendi imzasına sahip olduğundan, saldırganlar bu imzayı kullanabilir ve bir ara sertifika için kullanabilirler.
  • 2005 yılında, Arjen Lenstra ve Benne de Weger, "Özet çarpışmaları, aynı imzaları içeren ve yalnızca açık anahtarlarda farklılık gösteren iki X.509 sertifika oluşturmak için nasıl kullanılır" sorusunu MD5 özet fonksiyonu üzerinde bir çarpışma saldırısı kullanarak gösterdi.
    [23]
  • 2008 yılında, Alexander Sotirov ve Marc Stevens, Chaos Communication Congress'te, MD5'e dayanan RapidSSL'nin hala X.509 sertifikaları yayınladığı gerçeğini kullanarak, tüm yaygın tarayıcılar tarafından kabul edilen hileli bir Sertifika Yetkilisi oluşturmalarına izin veren pratik bir saldırı sundular.
    [24]
  • 2009 yılının Nisan ayında, Eurocrypt Konferansı'nda,[25] Macquarie Üniversitesi'nden Avustralyalı Araştırmacılar, "Automatic Differential Path Searching for SHA-1" adlı makaleyi sundu.[26] Araştırmacılar, bir çarpışma olasılığını birkaç büyüklük derecesine göre arttıran bir yöntem çıkarmayı başardılar.[27]
  • Şubat 2017'de bir grup araştırmacı, SHA-1'in zayıflığını gösteren bir SHA-1 çarpışması üretti.[28]

Kriptografik zayıflıklar için düzeltmeler[değiştir | kaynağı değiştir]

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.[29]

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

X.509 için PKI standartları[değiştir | kaynağı değiştir]

PKIX Çalışma Grubu[değiştir | kaynağı değiştir]

1995 yılında, Ulusal Standartlar ve Teknoloji Enstitüsü[40] 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[41] 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.

X.509 sertifikalarını kullanan büyük protokoller ve standartlar[değiştir | kaynağı değiştir]

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 standardı, kimlik doğrulamayı TLS aracılığıyla veya kendi sertifika profili aracılığıyla tanımlar.[42] Her iki yöntem de X.509 kullanır.

Microsoft Authenticode kod imzalama sistemi, hangi bilgisayar programlarını kimin yaptığını tanımlamak için X.509'u kullanır.

OPC UA endüstriyel otomasyon iletişim standardı X.509 kullanmaktadır.

SSH genellikle "trust on first use" (ilk kullanımda güven) modelini kullanır ve sertifikalara ihtiyaç duymaz. Ancak, popüler OpenSSH uygulaması X.509 olmayan sertifika formatına dayanan CA imzalı bir kimlik modelini desteklemektedir.[43]

Ayrıca bakınız[değiştir | kaynağı değiştir]

Kaynakça[değiştir | kaynağı değiştir]

  1. ^ RFC 4158
  2. ^ "CA:IncludedCAs - MozillaWiki". wiki.mozilla.org. 15 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Ocak 2017. 
  3. ^ "Bug 110161 - (ocspdefault) enable OCSP by default". 15 Mart 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 17 Mart 2016. 
  4. ^ RFC 5280 section 4.2, retrieved 12 February 2013
  5. ^ "RFC 1422". 5 Mayıs 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  6. ^ "RFC 5280, Section 'Basic Constraints'". 15 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  7. ^ "'RFC 5280, Section 'Key Usage'". 15 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  8. ^ "RFC 5280, Section 'Extended Key Usage'". 15 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  9. ^ "All About Certificate Extensions". 15 Aralık 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  10. ^ "Certification Path Validation". Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Network Working Group. 2008. 15 Mart 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  11. ^ Lloyd, Steve (Eylül 2002). Understanding Certification Path Construction (PDF). PKI Forum. 4 Şubat 2019 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 7 Nisan 2018. 
  12. ^ "Cross-Certification Between Root CAs". Qualified Subordination Deployment Scenarios. Microsoft. Ağustos 2009. 30 Nisan 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  13. ^ Nash; Duane; Joseph; Brink (2001). "Key and Certificate Life Cycles. CA Certificate Renewal". PKI: Implementing and Managing E-Security. RSA Press - Osborne/McGraw-Hill. ISBN 0-07-213123-3. 
  14. ^ Carl Ellison and Bruce Schneier. "Top 10 PKI risks" (PDF). Computer Security Journal (Volume XVI, Number 1, 2000). 24 Kasım 2015 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  15. ^ Peter Gutmann. "PKI: it's not dead, just resting" (PDF). IEEE Computer (Volume:35, Issue: 8). 29 Ocak 2018 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 7 Nisan 2018. 
  16. ^ Gutmann, Peter. "Everything you Never Wanted to Know about PKI but were Forced to Find Out" (PDF). 29 Ocak 2018 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 14 Kasım 2011. 
  17. ^ Langley, Adam. "Revocation checking and Chrome's CRL (05 Feb 2012)". Imperial Violet. 8 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 2 Şubat 2017. 
  18. ^ "Zusman and Sotirov Blackhat 2009" (PDF). 7 Ekim 2016 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 7 Nisan 2018. 
  19. ^ van Pelt, Cris. "Logius: Dutch Government CA trust issue". Bugzilla. 30 Ekim 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Ekim 2017. 
  20. ^ "Marlinspike Blackhat 2009" (PDF). 12 Haziran 2018 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 7 Nisan 2018. 
  21. ^ Rec. ITU-T X.690, clause 8.19.2
  22. ^ "26C3: Black Ops Of PKI". Events.ccc.de. 8 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Eylül 2013. 
  23. ^ Lenstra, Arjen; de Weger, Benne (19 Mayıs 2005). On the possibility of constructing meaningful hash collisions for public keys (PDF). Murray Hill, NJ, USA & Eindhoven, The Netherlands: Lucent Technologies, Bell Laboratories & Technische Universiteit Eindhoven. 14 Mayıs 2013 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 28 Eylül 2013. 
  24. ^ "MD5 considered harmful today". Win.tue.nl. 20 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 29 Eylül 2013. 
  25. ^ "Eurocrypt Conference". 9 Nisan 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 8 Nisan 2018. 
  26. ^ ""Automatic Differential Path Searching for SHA-1"" (PDF). 22 Şubat 2012 tarihinde kaynağından arşivlendi (PDF). Erişim tarihi: 8 Nisan 2018. 
  27. ^ Litke, Pat. "SHA-1 Collision Attacks Now 252". SecureWorks. SecureWorks Insights. 9 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 24 Şubat 2016. 
  28. ^ "The first collision for full SHA-1" (PDF). 15 Mayıs 2018 tarihinde kaynağından (PDF) arşivlendi. 
  29. ^ "Baseline Requirements Documents - CAB Forum". CAB Forum (İngilizce). 20 Ekim 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 
  30. ^ "SHA-1 Certificates in Chrome". Google Online Security Blog (İngilizce). 2 Mart 2019 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 
  31. ^ "The end of SHA-1 on the Public Web". Mozilla Security Blog (İngilizce). 6 Şubat 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 
  32. ^ "Microsoft Security Advisory 4010323". technet.microsoft.com (İngilizce). 10 Temmuz 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Mayıs 2017. 
  33. ^ "Safari and WebKit do not support SHA-1 certificates". Apple Support (İngilizce). 19 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 16 Mayıs 2017. 
  34. ^ "Lesser HTTPS for non-browsers | daniel.haxx.se". daniel.haxx.se (İngilizce). 26 Aralık 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 
  35. ^ "PKCS #7: Cryptographic Message Syntax Version 1.5". 30 Eylül 2017 tarihinde kaynağından arşivlendi. 
  36. ^ "The Transport Layer Security (TLS) Protocol Version 1.2". 24 Kasım 2017 tarihinde kaynağından arşivlendi. 
  37. ^ "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP". 15 Ocak 2018 tarihinde kaynağından arşivlendi. 
  38. ^ "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". 15 Mart 2018 tarihinde kaynağından arşivlendi. 
  39. ^ "RSA Laboratories - PKCS #12: Personal Information Exchange Syntax Standard". www.emc.com. 6 Temmuz 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 
  40. ^ "Public-Key Infrastructure (X.509) (pkix) - Charter". datatracker.ietf.org. Fremont, CA, USA: Internet Engineering Task Force. 12 Ocak 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 1 Ekim 2013. 0
  41. ^ "Pkix Status Pages". tools.ietf.org. 12 Mart 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 10 Mart 2017. 
  42. ^ "Web Services Security X.509 Token Profile Version 1.1.1". docs.oasis-open.org. 19 Eylül 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 14 Mart 2017. 
  43. ^ "How To Create an SSH CA to Validate Hosts and Clients with Ubuntu | DigitalOcean". www.digitalocean.com (İngilizce). 23 Ocak 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 19 Mart 2017. 

Dış bağlantılar[değiştir | kaynağı değiştir]

"https://tr.wikipedia.org/w/index.php?title=X.509&oldid=31192226" sayfasından alınmıştır