Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
Bu belgede, Private Cloud'un 4.17.09 ve önceki sürümleri için Edge'de anahtar depoları ve güven depoları oluşturma, değiştirme ve silme hakkında bilgi verilmektedir.
Anahtar depoları ve güven depoları hakkında
Anahtar depoları ve güven depoları, TLS şifrelemesi için kullanılan güvenlik sertifikası depolarını tanımlar. İkisi arasındaki temel fark, TLS el sıkışma sürecinde kullanılmalarıdır:
- Anahtar deposu, TLS el sıkışma 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ı (genel sertifika) istemciye sunar. Ardından istemci, bu sertifikayı Symantec veya VeriSign gibi bir Sertifika Yetkilisi (CA) ile doğrular.
İki yönlü TLS'de hem istemci hem de sunucu, kendi sertifikasına ve karşılıklı kimlik doğrulama için kullanılan özel anahtara sahip bir anahtar deposu tutar. - Güven deposu, TLS el sıkışma 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 imzalanırsa güven deposu gerekli değildir. TLS istemcisi tarafından alınan sertifika geçerli bir CA tarafından imzalanırsa istemci, sertifikanın kimliğini doğrulamak için CA'ya bir istek gönderir. 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üven 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ı bir sertifika kullandığı bir TLS sunucusuna bağlanır. Kendinden imzalı bir sertifika olduğu için istemci bu sertifikayı bir CA ile doğrulayamaz. Bunun yerine istemci, sunucunun kendinden imzalı sertifikasını güven deposuna önceden yükler. Ardından istemci, sunucuya bağlanmayı denediğinde sunucudan alınan sertifikayı doğrulamak için güven deposunu kullanır.
İki yönlü TLS için hem TLS istemcisi hem de TLS sunucusu bir güven deposu kullanabilir. Edge, TLS sunucusu olarak davrandığında iki yönlü TLS gerçekleştirirken bir güven deposu gerekir.
Sertifikalar bir sertifika yetkilisi (CA) tarafından verilebilir veya oluşturduğunuz özel anahtarla kendinden imzalı olabilir. Bir CA'ya erişiminiz varsa anahtar oluşturmak ve sertifika vermek için CA'nız tarafından sağlanan talimatları uygulayın. Bir CA'ya erişiminiz yoksa Opensl gibi herkese açık birçok ücretsiz araçtan birini kullanarak kendinden imzalı bir 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. Burada JAR dosyası şunları içerir:
- PEM dosyası olarak TLS sertifikası: Sertifika yetkilisi (CA) tarafından imzalanmış bir sertifika, son sertifikanın bir CA tarafından imzalandığı sertifika zinciri veya kendinden imzalı bir sertifika.
- PEM dosyası olarak özel anahtar. Edge, 2.048 bite kadar anahtar boyutlarını destekler. Parola isteğe bağlıdır.
Truststore, yalnızca PEM dosyası olarak sertifikaları içerir ancak özel anahtar içermemesi dışında anahtar deposuna benzer.
Sertifika bir zincirin parçasıysa anahtar deposu/güvenilir depo, bağımsız PEM dosyaları veya tek bir dosya olarak zincirdeki tüm sertifikaları içermelidir. Tek bir dosya kullanıyorsanız sertifikaların ilk sırada TLS için kullanılan sertifika, ardından da CA sertifikasına giden sertifika zinciri yer almalıdır. Dosyadaki her sertifikanın arasına boş bir satır eklemeniz gerekir.
Edge, anahtar depoları ve güven depoları oluşturmak için kullanabileceğiniz bir API sunar. Gerçek API'ler aynıdır. Aralarındaki fark, bir anahtar deposu oluşturduğunuzda sertifikayı ve özel anahtarı içeren bir JAR dosyası iletmenizdir. Truststore oluşturduğunuzda yalnızca sertifikayı PEM dosyası olarak geçirirsiniz.
Sertifikanın ve anahtar dosyalarının biçimi hakkında
Bu dokümandaki örneklerde, X.509 biçimine uygun olan TLS sertifikası ve PEM dosyaları olarak tanımlanan anahtar gösterilmektedir. Sertifikanız veya özel anahtarınız bir PEM dosyası tarafından tanımlanmamışsa Opensl 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 ekliyse:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
veya:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
Bu durumda dosyalar PEM biçimiyle uyumludur. Bunları PEM dosyasına dönüştürmeden bir anahtar deposunda veya güven deposunda kullanabilirsiniz.
Sertifika zinciriniz varsa ve bu zinciri bir anahtar deposunda veya güven deposunda kullanmak istiyorsanız tüm sertifikaları tek bir PEM dosyasında, her sertifikanın arasına yeni bir satır gelecek şekilde birleştirebilirsiniz. Sertifikaların sıralı olması ve son sertifikanın kök sertifika veya kök sertifika tarafından imzalanmış bir ara sertifika olması gerekir:
-----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 deposuyla ilgili ayrıntıları alma
List Keystores and Truststores API'yi kullanarak ortamınızda mevcut anahtar depoları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ındaki ücretsiz deneme kuruluşları için varsayılan bir anahtar deposu sağlanır. Her iki ortamda da bu çağrı için aşağıdaki sonuçları görmeniz gerekir:
[ "freetrial" ]
API'lerinizi test etmek ve API'lerinizi üretime aktarmak için bu varsayılan anahtar deposunu kullanabilirsiniz ancak genellikle üretime dağıtmadan önce kendi sertifikanız ve anahtarınızla kendi anahtar deponuzu oluşturursunuz.
Private Cloud müşterileri için döndürülen dizi, siz ilk anahtar deponuzu oluşturana kadar boş olur.
Get a Keystore veya Truststore API'yi kullanarak anahtar deposunun içeriğini kontrol edin. Bulut müşterileri için tek bir sunucu TLS sertifikası görürsünüz. 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:password
Yanı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önetimi kullanıcı arayüzü menüsünde Admin > TLS Certificates'i (Yönetici > TLS Sertifikaları) seçin.
TLS sertifikası ayrıntılarını alma
Anahtar deposundaki TLS sertifikalarıyla ilgili geçerlilik bitiş tarihi ve yayıncı gibi ayrıntıları görüntülemek için Anahtar Deposu veya Truststore'dan Sertifika Ayrıntıları Alma API'sini kullanabilirsiniz. Öncelikle, ilgilendiğiniz sertifikanın adını öğrenin. Bu örnekte, "freetrial" adlı anahtar deposunun bilgileri getirilmektedir.
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>, Management Server düğümünün IP adresidir. - Edge yönetimi kullanıcı arayüzü menüsünde Admin > TLS Certificates'i (Yönetici > TLS Sertifikaları) seçin.
Edge kullanıcı arayüzünde, Edge'in bir sertifikanın süresinin dolacağını ne kadar süre önceden belirteceğini belirtebilirsiniz. Varsayılan olarak, kullanıcı arayüzü sonraki 10 gün içinde süresi dolacak şekilde planlanan sertifikaları vurgular.
Anahtar deposu oluşturma
Anahtar deposu, kuruluşunuzdaki bir ortama (ör. test veya üretim ortamı) özeldir. Bu nedenle, anahtar deposunu üretim ortamınıza dağıtmadan önce bir test ortamında test etmek isterseniz anahtarı 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, sertifika ve manifest içeren 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 dizininde aşağıdaki içeriklere sahip descriptor.properties adlı bir dosya oluşturun:
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 ekleyin:
jar -uf myKeystore.jar META-INF/descriptor.properties
Anahtar deposunu oluşturun ve JAR dosyasını yükleyin.
Bir ortamda anahtar deposu oluşturmak için Create a Keystore veya Truststore API'ye anahtar deposu adını belirtmeniz yeterlidir. 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ış anahtar deposu oluşturduktan sonra JAR dosyasını Keystore'a Yükle 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 deposunda sertifikayı ve anahtarı tanımlar. Bir sanal ana makine oluşturduğunuzda sertifikaya ve anahtara takma ad adıyla referans verirsiniz.password- Özel anahtarın şifresi. Özel anahtarda şifre yoksa bu parametreyi dahil etmeyin.
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ılan API'lerle 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üven deposuna ayrı olarak yüklemeniz veya tüm sertifikaları içeren tek bir dosya oluşturup dosyadaki her sertifikanın arasına yeni bir satır eklemeniz gerekir. Nihai sertifika genellikle sertifikayı veren tarafından imzalanır. Örneğin, güven deposuna bir istemci sertifikası (client_cert_1) ve istemci sertifikasını verenin 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 client_cert_1 istemcisini istemciye gönderdiğinde istemci kimlik doğrulaması başarılı olur.
Alternatif olarak, aynı sertifika tarafından imzalanmış client_cert_2 adlı ikinci bir sertifikanız daha olur: ca_cert. Ancak client_cert_2 güven deposuna yüklenmez. Güven deposu hâlâ client_cert_1 ve ca_cert öğelerini içeriyor.
Sunucu, TLS el sıkışma işleminin bir parçası olarak client_cert_2 değerini ilettiğinde istek başarılı olur. Bunun nedeni, client_cert_2 güven deposunda mevcut olmadığında ancak güven deposunda bulunan bir sertifika tarafından imzalandığında Edge'in TLS doğrulamasının başarılı olmasına izin vermesidir. ca_cert CA sertifikasını güven deposundan kaldırırsanız TLS doğrulaması başarısız olur.
Anahtar deposu oluşturmak için kullandığınız API'nin aynısı olan Anahtar Deposu veya Truststore Oluştur'u kullanarak ortamda boş bir güven deposu oluşturun:
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
Sertifikayı Truststore'a Yükle API'sini kullanarak sertifikayı güven deposuna PEM dosyası olarak 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 deposu veya güven deposu silme
Delete a Keystore veya Truststore API'sini kullanarak bir anahtar deposunu veya güven 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.