Эта страница переведена с помощью Cloud Translation API.

Создайте хранилища ключей и доверенные хранилища для частного облака версии 4.17.09 и более ранних версий.

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee X.info

В этом документе описывается, как создавать, изменять и удалять хранилища ключей и доверенных сертификатов для Edge for the Private Cloud версии 4.17.09 и более ранних версий.

О магазинах ключей и трастовых магазинах

Хранилища ключей и хранилища доверенных сертификатов определяют репозитории сертификатов безопасности, используемых для шифрования TLS. Основное различие между ними заключается в том, где они используются в процессе установления TLS-соединения:

Хранилище ключей содержит TLS-сертификат и закрытый ключ, используемые для идентификации объекта во время установления TLS-соединения.

В одностороннем TLS, когда клиент подключается к конечной точке TLS на сервере, хранилище ключей сервера предоставляет клиенту сертификат сервера (открытый сертификат). Затем клиент проверяет этот сертификат в центре сертификации (ЦС), таком как Symantec или VeriSign.

В двустороннем TLS и клиент, и сервер поддерживают хранилище ключей, содержащее собственный сертификат и закрытый ключ, используемые для взаимной аутентификации.
В хранилище доверенных сертификатов хранятся сертификаты, используемые для проверки сертификатов, полученных в ходе установления соединения TLS.

В одностороннем TLS хранилище доверенных сертификатов не требуется, если сертификат подписан действительным центром сертификации (ЦС). Если сертификат, полученный TLS-клиентом, подписан действительным ЦС, то клиент отправляет запрос в ЦС для аутентификации сертификата. TLS-клиент обычно использует хранилище доверенных сертификатов для проверки самоподписанных сертификатов, полученных от TLS-сервера, или сертификатов, не подписанных доверенным ЦС. В этом сценарии клиент заполняет свое хранилище доверенных сертификатов сертификатами, которым он доверяет. Затем, когда клиент получает сертификат сервера, входящий сертификат проверяется на соответствие сертификатам в его хранилище доверенных сертификатов.

Например, TLS-клиент подключается к TLS-серверу, который использует самоподписанный сертификат. Поскольку это самоподписанный сертификат, клиент не может проверить его подлинность с помощью центра сертификации (CA). Вместо этого клиент предварительно загружает самоподписанный сертификат сервера в свое хранилище доверенных сертификатов. Затем, когда клиент пытается подключиться к серверу, он использует свое хранилище доверенных сертификатов для проверки сертификата, полученного от сервера.

Для двустороннего TLS-соединения как TLS-клиент, так и TLS-сервер могут использовать хранилище доверенных сертификатов. Хранилище доверенных сертификатов необходимо при выполнении двустороннего TLS-соединения, когда Edge выступает в качестве TLS-сервера.

Сертификаты могут быть выданы центром сертификации (ЦС) или самоподписаны с помощью сгенерированного вами закрытого ключа. Если у вас есть доступ к ЦС, следуйте инструкциям, предоставленным вашим ЦС, по генерации ключей и выдаче сертификатов. Если у вас нет доступа к ЦС, вы можете сгенерировать самоподписанный сертификат, используя один из множества общедоступных бесплатных инструментов, таких как openssl.

Реализация хранилища ключей и хранилища доверенных сертификатов на Edge.

В браузере Edge хранилище ключей содержит один или несколько JAR-файлов, где JAR-файл содержит:

TLS-сертификат в формате PEM — это либо сертификат, подписанный центром сертификации (ЦС), либо цепочка сертификатов, где последний сертификат подписан ЦС, либо самоподписанный сертификат.
Закрытый ключ в формате PEM. Edge поддерживает ключи размером до 2048 бит. Кодовая фраза необязательна.

Хранилище доверенных сертификатов похоже на хранилище ключей, за исключением того, что оно содержит только сертификаты в формате PEM, но не закрытые ключи.

Если сертификат является частью цепочки, то хранилище ключей/доверенных сертификатов должно содержать все сертификаты из цепочки либо в виде отдельных PEM-файлов, либо в виде одного файла. Если используется один файл, то сертификаты должны быть расположены в порядке следования: первый сертификат в файле — это сертификат, используемый для TLS, за которым следует цепочка сертификатов в порядке следования до сертификата центра сертификации. Между каждым сертификатом в файле необходимо вставить пустую строку.

Edge предоставляет API, который можно использовать для создания хранилищ ключей и хранилищ доверенных сертификатов. Сами API одинаковы. Разница заключается в том, что при создании хранилища ключей вы передаете JAR-файл, содержащий сертификат и закрытый ключ. При создании хранилища доверенных сертификатов вы передаете только сертификат в виде PEM-файла.

О формате файлов сертификата и ключа

В примерах, приведенных в этом документе, показаны сертификат и ключ TLS, определенные в виде PEM-файлов, соответствующих формату X.509. Если ваш сертификат или закрытый ключ не определены в PEM-файле, вы можете преобразовать их в PEM-файл с помощью таких утилит, как openssl.

Однако многие файлы .crt и .key уже находятся в формате PEM. Если эти файлы являются текстовыми и заключены в следующие форматы:

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

или:

-----BEGIN ENCRYPTED PRIVATE KEY-----
-----END ENCRYPTED PRIVATE KEY-----

В этом случае файлы будут совместимы с форматом PEM, и вы сможете использовать их в хранилище ключей или доверенных сертификатов без преобразования в файл PEM.

Если у вас есть цепочка сертификатов, и вы хотите использовать её в хранилище ключей или доверенных сертификатов, вы можете объединить все сертификаты в один PEM-файл, разделяя каждый сертификат новой строкой. Сертификаты должны быть расположены в порядке следования, а последний сертификат должен быть корневым сертификатом или промежуточным сертификатом, подписанным корневым сертификатом.

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

Получите подробную информацию о существующем хранилище ключей.

Проверьте свою среду на наличие существующих хранилищ ключей, используя API «Список хранилищ ключей и доверенных сертификатов» :

curl -X GET \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores \
-u email:password

Для облачных клиентов в организациях, участвующих в бесплатной пробной версии, предоставляется хранилище ключей по умолчанию как в тестовой, так и в производственной средах. В обеих средах вы должны увидеть следующие результаты выполнения этого вызова:

[ "freetrial" ]

Вы можете использовать это хранилище ключей по умолчанию для тестирования ваших API и развертывания ваших API в продакшене, но обычно перед развертыванием в продакшене вы создаете собственное хранилище ключей со своим сертификатом и ключом.

Для клиентов Private Cloud возвращаемый массив будет пустым до тех пор, пока вы не создадите первое хранилище ключей.

Проверьте содержимое хранилища ключей, используя API «Получить хранилище ключей» или «Хранилище доверенных сертификатов» . Для облачных клиентов вы должны увидеть сертификат TLS одного сервера — сертификат по умолчанию, предоставляемый Apigee Edge для бесплатных пробных учетных записей.

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Ответ должен выглядеть следующим образом:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Эту информацию также можно просмотреть в пользовательском интерфейсе управления Edge:

Войдите в пользовательский интерфейс управления Edge по адресу https://enterprise.apigee.com (облако) или http://<ms-ip>:9000 (локальная сеть), где <ms-ip> — IP-адрес узла сервера управления.
В меню пользовательского интерфейса управления Edge выберите «Администрирование» > «Сертификаты TLS» .

Получить данные TLS-сертификата

Вы можете использовать API « Получить сведения о сертификате из хранилища ключей или хранилища доверенных сертификатов» , чтобы просмотреть подробную информацию о TLS-сертификатах в хранилище ключей, такую как дата истечения срока действия и издатель. Сначала получите имя интересующего вас сертификата. В этом примере получается информация для хранилища ключей с именем «freetrial».

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial \
-u email:password

Пример ответа:

{
 "certs" : [ "wildcard.apigee.net.crt" ],
 "keys" : [ "freetrial" ],
 "name" : "freetrial"
}

Затем используйте значение свойства certs, чтобы получить сведения о сертификате:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/freetrial/certs/wildcard.apigee.net.crt \
-u email:password

Пример ответа:

{
 "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=&quot;GoDaddy.com, Inc.&quot;, 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"
}

Эту информацию также можно просмотреть в пользовательском интерфейсе управления Edge:

Войдите в пользовательский интерфейс управления Edge по адресу https://enterprise.apigee.com (облако) или http://<ms-ip>:9000 (локальная сеть), где <ms-ip> — IP-адрес узла сервера управления.
В меню пользовательского интерфейса управления Edge выберите «Администрирование» > «Сертификаты TLS» .

В пользовательском интерфейсе Edge можно указать, за какой срок до истечения срока действия сертификата Edge его отобразит. По умолчанию интерфейс выделяет все сертификаты, срок действия которых истекает в ближайшие 10 дней.

Создайте хранилище ключей

Хранилище ключей предназначено для конкретной среды в вашей организации, например, для тестовой или производственной среды. Поэтому, если вы хотите протестировать хранилище ключей в тестовой среде перед развертыванием в производственной среде, вам необходимо создать его в обеих средах.

Создание хранилища ключей — это двухэтапный процесс:

Создайте JAR-файл, содержащий ваш сертификат и закрытый ключ.
Создайте хранилище ключей и загрузите JAR-файл.

Создайте JAR-файл, содержащий ваш сертификат и закрытый ключ.

Создайте JAR-файл, содержащий ваш закрытый ключ, сертификат и манифест. JAR-файл должен содержать следующие файлы и каталоги:

/META-INF/descriptor.properties
myCert.pem
myKey.pem

В каталоге, содержащем вашу пару ключей и сертификат, создайте каталог с именем /META-INF . Затем создайте в каталоге /META-INF файл с именем descriptor.properties со следующим содержимым:

certFile={myCertificate}.pem
keyFile={myKey}.pem

Сгенерируйте JAR-файл, содержащий вашу пару ключей и сертификат:

jar -cf myKeystore.jar myCert.pem myKey.pem

Добавьте файл descriptor.properties в ваш JAR-файл:

jar -uf myKeystore.jar META-INF/descriptor.properties

Создайте хранилище ключей и загрузите JAR-файл.

Для создания хранилища ключей в среде достаточно указать имя хранилища ключей в API создания хранилища ключей или хранилища доверенных сертификатов . Имя может содержать только буквенно-цифровые символы:

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

Пример ответа:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystore"
}

После создания именованного хранилища ключей в среде вы можете загрузить JAR-файлы, содержащие сертификат и закрытый ключ, используя API «Загрузка JAR-файла в хранилище ключей» :

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

где опция -F указывает путь к JAR-файлу.

В этом вызове вы указываете два параметра запроса:

alias — идентифицирует сертификат и ключ в хранилище ключей. При создании виртуального хоста вы ссылаетесь на сертификат и ключ по их псевдониму.
password — Пароль для закрытого ключа. Если пароль для закрытого ключа отсутствует, этот параметр можно опустить.

Убедитесь, что ваше хранилище ключей загружено корректно:

curl https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystore \
-u email:password

Пример ответа:

{  
 "certs" : [ "myCertificate" ],
 "keys" : [ "myKey" ],
 "name" : "myKeystore"
}

Создайте хранилище доверенных сертификатов.

API-интерфейсы, используемые для создания хранилища доверенных сертификатов, идентичны тем, что используются для создания хранилища ключей. Единственное отличие заключается в том, что файл сертификата передается в формате PEM, а не JAR.

Если сертификат является частью цепочки, то необходимо либо загрузить все сертификаты из цепочки отдельно в хранилище доверенных сертификатов, либо создать один файл, содержащий все сертификаты. Между каждым сертификатом в файле должна быть новая строка. Окончательный сертификат обычно подписывается эмитентом сертификата. Например, в хранилище доверенных сертификатов вы загружаете клиентский сертификат, client_cert_1 , и сертификат эмитента клиентского сертификата, ca_cert .

В процессе двусторонней TLS-аутентификации аутентификация клиента считается успешной, если сервер отправляет клиенту client_cert_1 в рамках процесса установления TLS-соединения.

В качестве альтернативы, у вас есть второй сертификат, client_cert_2 , подписанный тем же сертификатом, ca_cert . Однако вы не загружаете client_cert_2 в хранилище доверенных сертификатов. Хранилище доверенных сертификатов по-прежнему содержит client_cert_1 и ca_cert .

Когда сервер передает client_cert_2 в рамках установления TLS-соединения, запрос выполняется успешно. Это происходит потому, что Edge позволяет успешно выполнить проверку TLS, даже если client_cert_2 отсутствует в хранилище доверенных сертификатов, но подписан сертификатом, который уже есть в этом хранилище. Если удалить сертификат центра сертификации ca_cert из хранилища доверенных сертификатов, проверка TLS завершится неудачей.

Создайте пустое хранилище доверенных сертификатов в среде, используя функцию «Создать хранилище ключей» или «Хранилище доверенных сертификатов» — тот же 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

Загрузите сертификат в хранилище доверенных сертификатов в формате PEM, используя API «Загрузка сертификата в хранилище доверенных сертификатов» :

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

где опция -F указывает путь к PEM-файлу.

Удалите хранилище ключей или хранилище доверенных сертификатов.

Вы можете удалить хранилище ключей или хранилище доверенных сертификатов, используя API для удаления хранилища ключей или хранилища доверенных сертификатов :

curl -X DELETE \
https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/keystores/myKeystoreName \
-u email:password

Пример ответа:

{
 "certs" : [ ],
 "keys" : [ ],
 "name" : "myKeystoreName"
}

Если удалить хранилище ключей или доверенных сертификатов, используемое виртуальным хостом или целевой конечной точкой/сервером, все вызовы API через виртуальный хост или целевую конечную точку/сервер завершатся с ошибкой.