Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. info
Bu dokümanda, Private Cloud 4.17.09 ve önceki sürümleri için Edge 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, bunların TLS el sıkışmasında kullanıldığı yerdir. işlem:
- keystore, bir TLS sertifikasını ve
.
Tek yönlü TLS'de, bir istemci sunucudaki TLS uç noktasına bağlandığında sunucunun anahtar mağazası, sunucunun sertifikasını (ortak sertifika) istemciye sunar. Müşteri daha sonra Symantec veya VeriSign gibi bir Sertifika Yetkilisi (CA) ile sertifikalandırabilirsiniz.
İ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ının bulunduğu bir anahtar deposu bulundurur. - truststore, şu şekilde alınan sertifikaları doğrulamak için kullanılan sertifikaları içerir:
TLS el sıkışmasının bir parçasıdır.
Bir 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ğrulaması için CA'ya bir istek gönderir. TLS istemcisi, TLS sunucusundan alınan kendinden imzalı sertifikaları veya güvenilir bir CA tarafından imzalanmamış sertifikaları doğrulamak için genellikle bir güvenilir sertifika deposu kullanır. Bu senaryoda istemci, güven deposunu güvenir. Ardından, istemci bir sunucu sertifikası aldığında gelen sertifika, güven mağazasındaki sertifikalarla karşılaştırılarak doğrulanır.
.
. Örneğin, bir TLS istemcisi, sunucunun kendinden imzalı sertifikası. Kendinden imzalı bir sertifika olduğundan istemci bunu bir CA ile doğrulayamaz. Bunun yerine istemci, sunucunun kendinden imzalı sertifikasını güven mağazasına önceden yükler. Ardından istemci, sunucuya bağlanmaya çalışırken sunucudan aldığı sertifikayı doğrulamak için güven mağazasını kullanır.
İki yönlü TLS için hem TLS istemcisi hem de TLS sunucusu bir güvenilir sertifika deposu kullanabilir. Truststore Edge, TLS sunucusu gibi davranırken iki yönlü TLS gerçekleştirilirken gereklidir.
Sertifikalar, bir sertifika yetkilisi (CA) tarafından verilebileceği gibi, sertifika yetkilisi tarafından gizli anahtar bulunur. Bir CA'ya erişiminiz varsa anahtar oluşturma ve sertifika verme ile ilgili olarak CA'nız tarafından sağlanan talimatları uygulayın. Bir CA'ya erişiminiz yoksa openssl gibi herkese açık birçok ücretsiz araçtan birini kullanarak kendinden imzalı sertifika oluşturabilirsiniz.
Proje yönetiminde Edge'de anahtar deposu ve güven deposu
Edge'de anahtar deposu, bir veya daha fazla JAR dosyası içerir. JAR dosyası şunları içerir:
- PEM dosyası olarak TLS sertifikası (bir sertifika yetkilisi tarafından imzalanmış bir sertifika) (CA), son sertifikanın bir CA tarafından imzalandığı bir sertifika zinciri veya kendinden imzalı bir sertifika sertifikası.
- PEM dosyası olarak özel anahtar. Edge, 2048 bite kadar anahtar boyutlarını destekler. Parola isteğe bağlıdır.
Truststore, yalnızca sertifikaları PEM dosyası olarak içermesi dışında anahtar deposuna benzer, ancak hiçbir özel anahtarlar.
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, dosyanın ilk sertifikasının TLS için kullanılan sertifika olduğu ve ardından CA sertifikasına kadar sertifika zincirinin sırayla yer aldığı şekilde olmalıdır. her sertifika için geçerli olacak.
Edge, anahtar depoları ve güven depoları oluşturmak için kullanabileceğiniz bir API sağlar. Gerçek API'ler aynı. Aralarındaki fark, bir anahtar deposu oluşturduğunuzda sertifika ve özel anahtar. Truststore oluşturduğunuzda yalnızca sertifikayı PEM dosyası olarak iletirsiniz.
sertifika ve anahtar dosyaları
Bu belgedeki örneklerde, PEM dosyası olarak tanımlanan TLS sertifikası ve anahtarı, kullanın. Sertifikanızın veya özel anahtarınızın PEM dosyası ile tanımlanmadığı durumlarda 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 biçimindeyse ve aşağıdakilerin içine eklenir:
-----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
veya:
-----BEGIN ENCRYPTED PRIVATE KEY----- -----END ENCRYPTED PRIVATE KEY-----
Bu durumda dosyalar PEM biçimiyle uyumlu olur ve bunları bir anahtar deposunda ya da güven deposunu kullanarak, PEM dosyasına dönüştürmeyin.
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ında yeni bir satır olacak şekilde birleştirebilirsiniz. Sertifikaların sırayla olması ve son sertifikanın bir 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 kapsülü hakkında ayrıntılı bilgi edinme
curl -X GET \ https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \ -u email:password
Cloud müşterileri için hem test hem de üretim ortamlarında ücretsiz deneme kuruluşları için varsayılan bir anahtar kutusu sağlanır. Bu çağrı için her iki ortamda da aşağıdaki sonuçları göreceksiniz:
[ "freetrial" ]
API'lerinizi test etmek ve API'lerinizi üretime göndermek 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.
Özel Bulut müşterileri için, ilk anahtar deponuzu oluşturana kadar döndürülen dizi boştur.
Anahtar deposunun içeriğini Anahtar Deposu veya Truststore API'si alın. Bulut müşterisi 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) adresinde 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 sertifika veren) görüntülemek için Anahtar Deposundan veya Güven Deposundan Sertifika Ayrıntıları Alın API'sini kullanabilirsiniz. Öncelikle, Google Cloud Platform ve bu bilgileri görebilirsiniz. Bu örnekte, "freetrial" adlı anahtar deposu için bilgiler 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 Uç yönetim kullanıcı arayüzüne giriş yapın. Burada<ms-ip>
, Yönetim Sunucusu düğümünün IP adresidir. - Kenar yönetimi kullanıcı arayüzü menüsünde Yönetici > TLS Sertifikaları.
Edge kullanıcı arayüzünde, Edge'in bir sertifikanın ilerleme durumunu ne kadar önceden sona erecektir. Kullanıcı arayüzü, varsayılan olarak geçerlilik süresi önümüzdeki 10 gün içinde sona erecek şekilde programlanan sertifikaları vurgular. gün.
Anahtar deposu oluşturma
Anahtar depoları, 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 istiyorsanız her iki ortamda da oluşturmanız gerekir.
Anahtar mağazası oluşturma işlemi iki adımdan oluşur:
- 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 manifest dosyasıyla bir JAR dosyası oluşturun. JAR dosyası aşağıdaki dosyaları ve dizinleri içermelidir:
/META-INF/descriptor.properties myCert.pem myKey.pem
Anahtar çiftinizi ve sertifikanızı içeren dizinde,
/META-INF
Ardından bir dosya oluşturun
adı descriptor.properties
Şunları içeren /META-INF
içerik:
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 or Truststore API'sine 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ış bir anahtar deposu oluşturduktan sonra, Bir anahtar deposuna JAR dosyası yükleme 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 deposuna taşımayı öğreteceğim. Sanal ana makine oluşturduğunuzda sertifikaya ve anahtara, takma adı üzerinden 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" }
Truststore oluşturma
Truststore oluşturmak için kullandığınız API'ler, anahtar deposu oluşturmak için kullanılanlarla aynıdır. Aralarındaki tek fark, sertifika dosyasını JAR dosyası yerine PEM dosyası olarak iletmenizdir.
Sertifika bir zincirin parçasıysa zincirdeki tüm sertifikaları ayrı olarak yüklemeniz gerekir
veya tüm sertifikaları içeren tek bir dosya oluşturun. Ardından,
tıklayın. Nihai sertifika genellikle sertifika veren tarafından imzalanır. Örneğin,
Örneğin, güven deposunda bir istemci sertifikası, client_cert_1
ve istemci sertifikası
sertifikayı verenin sertifikası, ca_cert
.
İ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
) da olabilir. Ancak client_cert_2
dosyasını güven mağazasına yüklemezsiniz. Truststore hâlâ client_cert_1
ve ca_cert
içeriyor.
Sunucu, TLS el sıkışma işleminin bir parçası olarak client_cert_2
'ü iletirse istek başarılı olur. Bunun nedeni, client_cert_2
güven deposunda bulunan bir sertifikayla imzalanmış olabilir. CA'yı kaldırırsanız
ca_cert
sertifikası,
Trampet, TLS doğrulaması başarısız olur.
Ortamda boş bir güven deposu oluşturmak için Create a Anahtar deposu veya Truststore, anahtar deposu oluşturmak için kullandığınız API:
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
Truststore API'sine bir sertifika yükleme:
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 or Truststore API'yi 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 ya da hedef tarafından kullanılan anahtar deposunu veya güven deposunu silerseniz uç nokta/hedef/sunucu, sanal ana makine veya hedef uç nokta/hedef sunucu üzerinden yapılan tüm API çağrıları başarısız olur.