Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
Bu belgede, Özel Bulut sürümü 4.17.09 ve önceki sürümlerde Edge için anahtar depolarının ve güven depolarının nasıl oluşturulacağı, değiştirileceği ve silineceği açıklanmaktadır.
Anahtar depoları ve güven depoları hakkında
Anahtar depoları ve güvenilir sertifika depoları, TLS şifrelemesi için kullanılan güvenlik sertifikalarının depolarını tanımlar. İkisi arasındaki temel fark, TLS el sıkışma sürecinde kullanıldıkları yerdir:
- Anahtar deposu, TLS el sıkışması sırasında varlığı tanımlamak için kullanılan bir TLS sertifikası ve özel anahtar içerir.
Tek yönlü TLS'de, bir istemci sunucudaki TLS uç noktasına bağlandığında sunucunun anahtar deposu, sunucunun sertifikasını (ortak sertifika) istemciye sunar. İstemci daha sonra bu sertifikayı Symantec veya VeriSign gibi bir sertifika yetkilisi (CA) ile doğrular.
İki yönlü TLS'de hem istemci hem de sunucu, karşılıklı kimlik doğrulama için kullanılan kendi sertifikası ve özel anahtarıyla bir anahtar deposu tutar. - truststore, TLS el sıkışması kapsamında alınan sertifikaları doğrulamak için kullanılan sertifikaları içerir.
Tek yönlü TLS'de, sertifika geçerli bir CA tarafından imzalanmışsa güvenilir sertifika deposu gerekmez. Bir TLS istemcisi tarafından alınan sertifika geçerli bir CA tarafından imzalanmışsa istemci, sertifikanın kimliğini doğrulamak için CA'ya istekte bulunur. TLS istemcisi genellikle TLS sunucusundan alınan kendinden imzalı sertifikaları veya güvenilir bir CA tarafından imzalanmamış sertifikaları doğrulamak için bir güvenilir sertifika deposu kullanır. Bu senaryoda istemci, güven deposunu güvendiği sertifikalarla doldurur. Ardından, istemci bir sunucu sertifikası aldığında gelen sertifika, güven deposundaki sertifikalara göre doğrulanır.
Örneğin, bir TLS istemcisi, sunucunun kendinden imzalı sertifika kullandığı bir TLS sunucusuna bağlanır. Kendinden imzalı bir sertifika olduğundan istemci, bunu bir CA ile doğrulayamaz. Bunun yerine, istemci sunucunun kendinden imzalı sertifikasını güvenli deposuna önceden yükler. Ardından, istemci sunucuya bağlanmayı denediğinde, sunucudan alınan sertifikayı doğrulamak için güvenilen sertifika deposunu kullanır.
İki yönlü TLS için hem TLS istemcisi hem de TLS sunucusu güvenilir sertifika deposu kullanabilir. Edge, TLS sunucusu olarak hareket ettiğinde iki yönlü TLS gerçekleştirilirken bir güvenli depo gerekir.
Sertifikalar bir sertifika yetkilisi (CA) tarafından verilebilir veya oluşturduğunuz özel anahtar tarafından kendinden imzalı olabilir. CA'ya erişiminiz varsa anahtar oluşturma ve sertifika verme konusunda CA'nızın talimatlarını uygulayın. CA'ya erişiminiz yoksa openssl gibi herkese açık olarak sunulan ücretsiz araçlardan birini kullanarak kendinden imzalı sertifika oluşturabilirsiniz.
Edge'de anahtar deposu ve güven deposu uygulama
Edge'de bir anahtar deposu, bir veya daha fazla JAR dosyası içerir. JAR dosyası şunları içerir:
- PEM dosyası olarak TLS sertifikası: Sertifika yetkilisi (CA) tarafından imzalanmış bir sertifika, son sertifikanın CA tarafından imzalandığı bir sertifika zinciri veya kendinden imzalı bir sertifika.
- PEM dosyası olarak özel anahtar. Edge, 2048 bit'e kadar anahtar boyutlarını destekler. Parola isteğe bağlıdır.
Güven deposu, yalnızca PEM dosyası olarak sertifikalar içerdiği için anahtar deposuna benzer ancak özel anahtar içermez.
Sertifika bir zincirin parçasıysa anahtar deposu/güven deposu, zincirdeki tüm sertifikaları ayrı PEM dosyaları veya tek bir dosya olarak içermelidir. Tek bir dosya kullanıyorsanız sertifikalar sıralı olmalıdır. Dosyadaki ilk sertifika, TLS için kullanılan sertifika olmalı, ardından da CA sertifikasına kadar olan sertifika zinciri sıralı bir şekilde gelmelidir. Dosyadaki her sertifika arasına boş bir satır eklemeniz gerekir.
Edge, anahtar depoları ve güvenilen depolar oluşturmak için kullandığınız bir API sağlar. Gerçek API'ler aynıdır. Aradaki fark, anahtar deposu oluştururken sertifikayı ve özel anahtarı içeren bir JAR dosyası iletmenizdir. Güvenilirlik deposu oluşturduğunuzda yalnızca sertifikayı PEM dosyası olarak iletirsiniz.
Sertifika ve anahtar dosyalarının biçimi hakkında
Bu belgedeki örneklerde, TLS sertifikası ve anahtarı X.509 biçimine uygun PEM dosyaları olarak tanımlanmıştır. Sertifikanız veya özel anahtarınız PEM dosyasıyla tanımlanmamışsa openssl gibi yardımcı programları kullanarak PEM dosyasına dönüştürebilirsiniz.
Ancak birçok .crt dosyası ve .key dosyası zaten PEM biçimindedir. Bu dosyalar metin dosyalarıysa ve şu karakterlerle çevriliyse:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
veya:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
Bu durumda dosyalar PEM biçimiyle uyumlu olur ve PEM dosyasına dönüştürmeden bir anahtar deposunda veya güven deposunda kullanılabilir.
Bir sertifika zinciriniz varsa ve bu zinciri bir anahtar deposunda veya güven deposunda kullanmak istiyorsanız tüm sertifikaları tek bir PEM dosyasında birleştirebilirsiniz. Her sertifika arasında yeni bir satır olmalıdır. Sertifikalar sıralı olmalı ve son sertifika, kök sertifika veya kök sertifika tarafından imzalanmış bir ara sertifika olmalıdır:
-----BEGIN CERTIFICATE----- (Your Primary TLS certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root certificate or intermediate certificate signed by a root certificate) -----END CERTIFICATE-----
Mevcut bir anahtar deposu hakkında ayrıntılı bilgi edinme
List Keystores and Truststores API'yi kullanarak ortamınızda mevcut anahtar depoları olup olmadığını kontrol edin:
curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
Bulut müşterileri için hem test hem de üretim ortamlarında ücretsiz deneme kuruluşlarına varsayılan bir anahtar deposu sağlanır. Bu çağrı için her iki ortamda da aşağıdaki sonuçları görmeniz gerekir:
[ "freetrial" ]
API'lerinizi test etmek ve üretim ortamına aktarmak için bu varsayılan anahtar deposunu kullanabilirsiniz. Ancak genellikle üretim ortamına dağıtmadan önce kendi sertifikanız ve anahtarınızla kendi anahtar deponuzu oluşturursunuz.
Özel bulut müşterileri için, ilk anahtar deponuzu oluşturana kadar döndürülen dizi boştur.
Get a Keystore or Truststore API'sini kullanarak anahtar deposunun içeriğini kontrol edin. Bir bulut müşterisi için tek bir sunucu TLS sertifikası görmeniz gerekir. Bu, Apigee Edge'in ücretsiz deneme hesapları için sağladığı varsayılan sertifikadır.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:passwordYanıt şu şekilde görünmelidir:
{ "certs" : [ "wildcard.apigee.net.crt" ], "keys" : [ "freetrial" ], "name" : "freetrial" }
Bu bilgileri Edge yönetim kullanıcı arayüzünde de görüntüleyebilirsiniz:
- https://enterprise.apigee.com (bulut) veya
http://<ms-ip>:9000(şirket içi) adresinden Edge yönetim kullanıcı arayüzüne giriş yapın. Burada<ms-ip>, yönetim sunucusu düğümünün IP adresidir. - Edge yönetim kullanıcı arayüzü menüsünde Yönetici > TLS Sertifikaları'nı seçin.
TLS sertifikası ayrıntılarını alma
Anahtar deposundaki TLS sertifikalarıyla ilgili ayrıntıları (ör. geçerlilik bitiş tarihi ve veren) görüntülemek için Get Cert Details from a Keystore or Truststore API'sini kullanabilirsiniz. Öncelikle ilgilendiğiniz sertifikanın adını öğrenin. Bu örnekte, "freetrial" adlı anahtar deposuyla ilgili bilgiler getirilir.
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:passwordÖrnek yanıt:
{ "certs" : [ "wildcard.apigee.net.crt" ], "keys" : [ "freetrial" ], "name" : "freetrial" }
Ardından, sertifika ayrıntılarını almak için certs özelliğinin değerini kullanın:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password
Örnek yanıt:
{ "certInfo" : [ { "expiryDate" : "Wed, 23 Apr 2014 20:50:02 UTC", "isValid" : "Yes", "issuer" : "CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US", "subject" : CN=*.example.apigee.net, OU=Domain Control Validated", "subjectAlternativeNames" : ["*.example.apigee.net","*.example.apigee.net" ], "validFrom" : "Tue, 15 Apr 2014 09:17:03 UTC", "version" : 3 } ], "name" : "example.apigee.net.crt" }
Bu bilgileri Edge yönetim kullanıcı arayüzünde de görüntüleyebilirsiniz:
- https://enterprise.apigee.com (bulut) veya
http://<ms-ip>:9000(şirket içi) adresinden Edge yönetim kullanıcı arayüzüne giriş yapın. Burada<ms-ip>, yönetim sunucusu düğümünün IP adresidir. - Edge yönetim kullanıcı arayüzü menüsünde Yönetici > TLS Sertifikaları'nı seçin.
Edge kullanıcı arayüzünde, Edge'in bir sertifikanın süresinin dolacağını ne kadar önceden bildireceğini belirtebilirsiniz. Kullanıcı arayüzü, varsayılan olarak önümüzdeki 10 gün içinde geçerlilik süresi dolacak sertifikaları vurgular.
Anahtar deposu oluşturma
Anahtar deposu, kuruluşunuzdaki bir ortama (ör. test veya üretim ortamı) özgüdür. Bu nedenle, üretim ortamınıza dağıtmadan önce test ortamında anahtar deposunu test etmek istiyorsanız her iki ortamda da oluşturmanız gerekir.
Anahtar deposu oluşturmak iki adımlı bir işlemdir:
- Sertifikanızı ve özel anahtarınızı içeren bir JAR dosyası oluşturun.
- Anahtar deposunu oluşturun ve JAR dosyasını yükleyin.
Sertifikanızı ve özel anahtarınızı içeren bir JAR dosyası oluşturun.
Özel anahtarınız, sertifikanız ve manifestinizle bir JAR dosyası oluşturun. JAR dosyası aşağıdaki dosya ve dizinleri içermelidir:
/META-INF/descriptor.properties myCert.pem myKey.pem
Anahtar çiftinizi ve sertifikanızı içeren dizinde /META-INF adlı bir dizin oluşturun. Ardından, /META-INF içinde descriptor.properties adlı bir dosya oluşturun ve aşağıdaki içerikleri ekleyin:
certFile={myCertificate}.pem keyFile={myKey}.pem
Anahtar çiftinizi ve sertifikanızı içeren JAR dosyasını oluşturun:
jar -cf myKeystore.jar myCert.pem myKey.pem
JAR dosyanıza descriptor.properties dosyasını ekleyin:
jar -uf myKeystore.jar META-INF/descriptor.properties
Anahtar deposunu oluşturma ve JAR dosyasını yükleme
Bir ortamda anahtar deposu oluşturmak için Anahtar Deposu veya Güvenilir Anahtar Deposu Oluşturma API'sinde yalnızca anahtar deposu adını belirtmeniz gerekir. Ad yalnızca alfanümerik karakterler içerebilir:
curl -X POST -H "Content-Type: text/xml" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-d '<KeyStore name="myKeystore"/>' -u email:password
Örnek yanıt:
{ "certs" : [ ], "keys" : [ ], "name" : "myKeystore" }
Bir ortamda adlandırılmış bir anahtar deposu oluşturduktan sonra, Upload a JAR file to a Keystore API'sini kullanarak sertifika ve özel anahtar içeren JAR dosyalarınızı yükleyebilirsiniz:
curl -X POST -H "Content-Type: multipart/form-data" \
-F file="@myKeystore.jar" -F password={key_pass} \ "https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/{myKeystore}/keys?alias={key_alias}" \
-u email:password
burada -F seçeneği, JAR dosyasının yolunu belirtir.
Bu çağrıda iki sorgu parametresi belirtirsiniz:
alias- Anahtar deposundaki sertifikayı ve anahtarı tanımlar. Sanal ana makine oluşturduğunuzda sertifikaya ve anahtara, diğer adıyla referans verirsiniz.password- Özel anahtarın şifresi. Özel anahtarın şifresi yoksa bu parametreyi atlayın.
Anahtar deponuzun düzgün şekilde yüklendiğini doğrulayın:
curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password
Örnek yanıt:
{ "certs" : [ "myCertificate" ], "keys" : [ "myKey" ], "name" : "myKeystore" }
Güven deposu oluşturma
Güven deposu oluşturmak için kullandığınız API'ler, anahtar deposu oluşturmak için kullanılanlarla aynıdır. Tek fark, sertifika dosyasını JAR dosyası yerine PEM dosyası olarak iletmenizdir.
Sertifika bir zincirin parçasıysa zincirdeki tüm sertifikaları güvenli sertifika deposuna ayrı ayrı yüklemeniz veya tüm sertifikaları içeren tek bir dosya oluşturmanız gerekir. Dosyada her sertifika arasında yeni bir satır ekleyin. Nihai sertifika genellikle sertifikayı veren kuruluş tarafından imzalanır. Örneğin, güvenli sertifika deposuna bir istemci sertifikası (client_cert_1) ve istemci sertifikasını veren kuruluşun sertifikası (ca_cert) yüklersiniz.
İki yönlü TLS kimlik doğrulaması sırasında, sunucu TLS el sıkışma sürecinin bir parçası olarak istemciye client_cert_1 gönderdiğinde istemci kimlik doğrulaması başarılı olur.
Alternatif olarak, aynı sertifika (ca_cert) tarafından imzalanmış ikinci bir sertifikanız (client_cert_2) var. Ancak client_cert_2 öğesini güvenli depoya yüklemezsiniz. Güven deposunda hâlâ client_cert_1 ve ca_cert bulunuyor.
Sunucu, TLS el sıkışması kapsamında client_cert_2 değerini ilettiğinde istek başarılı olur. Bunun nedeni, Edge'in güven deposunda client_cert_2 bulunmadığı ancak güven deposunda bulunan bir sertifika tarafından imzalandığı durumlarda TLS doğrulamasının başarılı olmasına izin vermesidir. CA sertifikasını, ca_cert, güvenilen sertifika deposundan kaldırırsanız TLS doğrulaması başarısız olur.
Anahtar deposu veya güven deposu oluşturma'yı kullanarak ortamda boş bir güven deposu oluşturun. Bu, anahtar deposu oluşturmak için kullandığınız API ile aynıdır:
curl -X POST -H "Content-Type: text/xml" -d \
'<KeyStore name="myTruststore"/>' \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password
Upload a Certificate to a Truststore API'sini kullanarak sertifikayı PEM dosyası olarak güvenilen sertifika deposuna yükleyin:
curl -X POST -H "Content-Type: multipart/form-data" -F file="@trust.pem" \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myTruststore/certs?alias=myTruststore \
-u email:password
Burada -F seçeneği, PEM dosyasının yolunu belirtir.
Anahtar deposunu veya güven deposunu silme
Delete a Keystore or Truststore API'sini kullanarak bir anahtar deposunu veya güvenilen sertifika deposunu silebilirsiniz:
curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password
Örnek yanıt:
{ "certs" : [ ], "keys" : [ ], "name" : "myKeystoreName" }
Bir sanal ana makine veya hedef uç nokta/hedef/sunucu tarafından kullanılan bir anahtar deposunu ya da güven deposunu silerseniz sanal ana makine veya hedef uç nokta/hedef sunucu üzerinden yapılan tüm API çağrıları başarısız olur.