Apigee Edge belgelerini görüntülüyorsunuz.
.
Git:
Apigee X belgeleri. bilgi
Bu dokümanda, 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üven depoları, TLS için kullanılan güvenlik sertifikası depolarını tanımlar bahsedeceğim. İ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 deposu Sunucunun sertifikasını (genel 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 kendi sertifikalarına ve karşılıklı kimlik doğrulama için kullanılan özel anahtar. - truststore, aşağıdaki ş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.
.
. Tek yönlü TLS'de, sertifika geçerli bir CA tarafından imzalandıysa güven deposu gerekli değildir. Öğe TLS istemcisinin aldığı sertifika geçerli bir CA tarafından imzalanır, ardından istemci istekte bulunur sertifikanın kimliğini doğrulamak üzere CA'ya bağlayın. TLS istemcileri, doğrulama işlemi için genellikle bir güven deposu kullanır TLS sunucusundan alınan kendinden imzalı sertifikalar veya bir güvenilir sertifika yetkilisi (CA) ile ilişkilidir. Bu senaryoda istemci, güven deposunu güvenir. Ardından, istemci bir sunucu sertifikası aldığında, gelen sertifika sertifikalarla doğrulandığından emin olun.
.
. Ö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 deposuna önceden yükler. Ardından, sunucuya bağlanmayı denediğinde istemci, kullandığı güven deposunu kullanarak sunucudan alınan sertifikayı doğrular.
.
. İki yönlü TLS için hem TLS istemcisi hem de TLS sunucusu bir güven 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 sertifika yetkilisinin Anahtar oluşturmak ve sertifika vermek için kullanılan CA. Bir CA'ya erişiminiz yoksa şunları yapabilirsiniz: herkese açık birçok ücretsiz araçtan birini kullanarak kendinden imzalı bir sertifika oluşturmak, openssl.
Proje yönetiminde Edge'de anahtar deposu ve güven deposu
Edge'de, bir 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, 2.048 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/truststore ya da tek bir dosya şeklinde oluşturabilirsiniz. Tek bir dosya kullanıyorsanız sertifikalar, dosyadaki ilk sertifikanın ardından TLS için kullanılan sertifika olacak şekilde olmalıdır sertifika zincirine göre sıralı olarak CA sertifikasına gönderilir. her sertifika için geçerli olacak.
Edge, anahtar depoları ve güven depoları oluşturmak için kullanabileceğiniz bir API sunar. 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 veya gizli anahtarınız bir PEM dosyası tarafından tanımlanmamışsa Opensl gibi yardımcı programlar kullanarak bunu bir 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 olduğundan bunları bir anahtar deposunda veya bir anahtar deposunda kullanabilirsiniz 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. İlgili içeriği oluşturmak için kullanılan her sertifikanın sıralı olması ve son sertifikanın da bir kök sertifika ya da ara sertifika olması gerekir bir kök sertifika tarafından imzalandı:
-----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
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 ücretsiz deneme kullanan kuruluşlar için varsayılan bir anahtar deposu test ve üretim ortamlarında yayınlanır. Her iki hesap için de bu çağrıya ait aşağıdaki sonuçları göreceksiniz: ortamlar:
[ "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şturur.
Private Cloud müşterileri için ilk kez oluşturulana kadar döndürülen dizi boş olur anahtar deposuna gidin.
Anahtar deposunun içeriğini Anahtar Deposu veya Truststore API'si alın. Bulut kullanan bir müşteri için tek bir sunucu TLS'si gösterilir. sertifika, 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 arayüzüne giriş yapın. burada<ms-ip>, IP'dir Yönetim Sunucusu düğümünün adresi. - Kenar yönetimi kullanıcı arayüzü menüsünde Yönetici > TLS Sertifikaları.
TLS sertifikası ayrıntılarını alma
URL parametrelerinin Google tarafından nasıl ele alınmasını istediğinizi belirtmek için Şuradaki TLS sertifikalarıyla ilgili ayrıntıları görüntülemek için bir Anahtar Deposu veya Truststore'dan Sertifika Ayrıntılarını alın geçerlilik bitiş tarihi ve kartı veren gibi anahtar deposunu içerir. Öncelikle, Google Cloud Platform ve bu bilgileri görebilirsiniz. Bu örnekte, "ücretsiz deneme".
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) sayfasından Edge yönetim arayüzüne giriş yapın
veya
http://<ms-ip>:9000(şirket içi) burada<ms-ip>, IP'dir Yönetim Sunucusu düğümünün adresi. - 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 deposu, kuruluşunuzdaki bir ortama (ör. test veya üretim) özgüdür bahsedeceğim. Bu nedenle, dağıtımdan önce anahtar deposunu bir test ortamında test etmek isterseniz bunu üretim ortamınıza ekleyebilmek için bunu her iki ortamda da oluşturmanız gerekir.
Anahtar deposu oluşturma 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.
JAR dosyası oluşturun sertifikanızı ve özel anahtarınızı içeren
Özel anahtarınız, sertifikanız ve manifest dosyasıyla bir JAR dosyası oluşturun. JAR dosyası şu dosyaları ve dizinleri içerir:
/META-INF/descriptor.properties myCert.pem myKey.pem. 'nı inceleyin.
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ı
Bir ortamda anahtar deposu oluşturmak için tek yapmanız gereken Oluştur Anahtar Deposu veya Truststore API'si. 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, Anahtar Deposu API'sine bir JAR dosyası yükleyin:
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 kontrol edin.
Bu çağrıda, iki sorgu parametresi belirtirsiniz:
alias- anahtar deposuna taşımayı öğreteceğim. Sanal ana makine oluşturduğunuzda, takma adla değiştirin.password- Şu hesabın şifresi: gizli anahtardır. Ö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. İlgili içeriği oluşturmak için kullanılan 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,
her sertifika için geçerli olacak. Nihai sertifika, genellikle sertifikayı 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,
client_cert_1 tarihinde müşteriye
TLS el sıkışma sürecinin bir parçasıdır.
Alternatif olarak, aynı sertifikayla imzalanmış client_cert_2 adlı ikinci bir sertifikanız daha vardır.
ca_cert. Ancak,
client_cert_2 dosyasını şuraya yükleyin:
güven deposu. Truststore hâlâ client_cert_1 ve ca_cert içeriyor.
Sunucu, TLS el sıkışmasının bir parçası olarak client_cert_2 testini geçtiğinde,
başarılı olur. Bunun nedeni, client_cert_2
güven deposunda bulunan bir sertifika tarafından 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 izler.
Anahtar deposu veya güven deposu silme
Bir anahtar deposunu veya güven deposunu silmek için Bir Anahtar Deposu veya Truststore API'sini silin:
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.