Могут быть ситуации, когда необходимо добавить дополнительные сертификаты в хранилище сертификатов АктивногоШлюза.
Добавление сертификатов во время установки АктивногоШлюза
При желании дополнительные доверенные корневые сертификаты можно указать во время установки АктивногоШлюза, указав параметры установки для Linux или Windows.
Убедитесь, нужен ли вам сертификат ЦС
АктивныйШлюз подключается к другим компонентам Ключа-Астром (кластерам, серверам) или сторонним системам (таким как VMware, Cloud Foundry, Kubernetes или OpenShift) с использованием защищенных SSL каналов. Встроенного хранилища АктивногоШлюза (набор сертификатов по умолчанию, поставляемый с Java), иногда недостаточно для покрытия всех необходимых вариантов использования. Это может произойти, если, например, сертификат был выдан внутри вашей организации для прокси-сервера, принимающего SSL-трафик. Также возможно, что некоторые серверы в вашей организации, к которым АктивныйШлюз должен подключаться, генерируют и используют самоподписанные сертификаты, и ваша организация не заменила их официальными сертификатами.
При возникновении таких ситуаций в лог-файле АктивногоШлюза будет ошибка о том, что сертификат, представленный сервером, к которому ваш АктивныйШлюз пытался подключиться, не является доверенным. В этих случаях вам необходимо импортировать отсутствующий сертификат в АктивныйШлюз.
Предупреждение
Добавление сертификата является потенциальной проблемой безопасности. Перед добавлением нового доверенного корневого сертификата в АктивныйШлюз убедитесь, что безопасность вашей организации не будет скомпрометирована вашими действиями.
Если в журнале АктивногоШлюза сообщается об ошибке о том, что сертификат, представленный сервером, к которому ваш АктивныйШлюз пытался подключиться, не был доверенным, не думайте, что вам нужно добавить отсутствующий сертификат. Прежде чем продолжить, необходимы дополнительные исследования.
Ошибка недействительного сертификата также может означать, что была попытка нарушить безопасность вашей организации. Поэтому вы всегда должны исследовать эту возможность, когда сообщается о такой ошибке.
Подготовка сертификатов
Прежде чем добавлять сертификат в АктивныйШлюз, его необходимо получить и поместить в файл ca.cert.
Следующая общая информация о сертификатах ЦС может помочь вам определить необходимые сертификаты:
Условия доверенного соединения SSL:
- Между сертификатами, представленными сервером (конечная точка API), и сертификатами, присутствующими в хранилище доверенных сертификатов АктивногоШлюза, должна быть создана полная цепочка сертификатов.
- Корневой сертификат цепочки должен быть включен в хранилище доверенных сертификатов АктивногоШлюза вместе с любыми другими сертификатами, НЕ представленными конечной точкой сервера/API.
Чтобы увидеть, какие сертификаты предоставляет конечная точка, вы можете использовать следующую команду:
openssl s_client -connect <API_ENDPOINT>:<PORT> -showcerts -servername <API_ENDPOINT_HOSTNAME>
Примечание:
Некоторые приложения (например, OpenShift) могут предоставлять разные сертификаты в зависимости от SNI. АктивныйШлюз установит сконфигурированное имя хоста конечной точки в SNI.
Если приведенная выше команда представляет полную цепочку сертификатов, вы должны добавить корневой сертификат в хранилище доверенных сертификатов АктивногоШлюза. Вы также можете добавить промежуточные звенья, но они не нужны, если конечная точка API их представляет.
Если приведенная выше команда не представляет полную цепочку сертификатов, то корень цепочки должен быть получен в другом месте.
Например, конечная точка запроса openssl к этому серверу возвращает только сертификат сервера, а не корневой сертификат. Вы знаете, что этот сервер представляет только сертификат сервера, а не корневой сертификат, поскольку в сообщении об ошибке говорится, что невозможно получить сертификат локального эмитента. При наличии корневого сертификата в сообщении об ошибке будет указано «Самозаверяющий сертификат в цепочке сертификатов». Чтобы создать действительное SSL-соединение с этой конечной точкой, необходимо отдельно получить корневой сертификат.
Например:
openssl s_client -connect localhost:6443
CONNECTED(00000005)
depth=0 CN = kube-apiserver
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = kube-apiserver
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:CN = apiserver
i:CN = AstromKeyRootAuth
---
Server certificate
-----BEGIN CERTIFICATE-----
MDIDYGCCAkigAwIBAgJIJ8SQ/FcmJiYwDQZJKoZIhvcNAQESBQAwFTETMBEGA1UE
AxMKa3ViZXJuZXRlczAeFw0yMTAxMjcxOTM1MDhaFw0yMjAxMjcxOTM1MDhaMBkx
FzAVBgNVBAMTDmt1YmUtYXBpc2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKSAQEA15BVGULXSXZAM6a4Y7lR6JfSBOXIAq1sCoydH2AdhzqHu0mXj+Fd
sooRQ46f7bySZvMGFfLupmaAzH5kVJOVDQ2WoHPYVzAEhDji+SUBOi99AC0tevEa
ONLdkLGzR//2u8XND0iiswsGkK3yaNyPwCVnOnA3c4O32waMoM1VI9XGuNSqqfQF
6XUx8sGHG5bNVzfHOXh5CBJZ5JReDhW/J8CbPElYJPJaQcSpTVFx5ReTQqBLeBSy
eWyCwqMj/jAnKzpPffO478If/Uc8I5vS8zi2yPhYJhKqD0m1b96hH0slXKho25Ip
gpu4cIw03mQZMK558W4d6ccww/OvMbpKQQIDAQABo4GvMIGsMA4GA1UdDwEB/wQE
AwIFoDATBgNVHSUEDDAKBgfrBgEFBQcDATSBhAYDVR0RBH0we4IPamstazhzLWNs
b25lLTAwggprdWJlcm5ldGVzghJrdWJlcm5ldGVzLmRlZmF1bHSCFmt1YmVybmV0
ZXMuZGVmYXVsdC5zdmOCAGt1YmVybmV0ZXMuZGVmYXVsdC5zdmMuY2x1c3Rlci5s
b2NhbIcECmAAAYcErBcSvDANBgkqhkiG9w0BAQsFAAOCAQEAdmOq/Sp74xiLCa14
EI/9v7jUG+GqjD3HPpj/oXIdLHg6HA4nixxcxwnWAf2RAMVXBYn7qTDU6x7W5M+t
6M0uaCe8Od8oKjOKeQ31dfMpPbLYprKmcnuBriiN5gjfghINZKaZlGlX0GkBC9Ts
THYbmWfXfvfsX2xfpc4J0esfK+BafllEimCx8blnw1uY7CiCedEANePT+J5Q+m9L
m5pu7Qz/B4JDHLIJBArhFTBM6IIF6DhoqGUXM1XXqMlTVBpxz2vhf0N/HxcTaEBa
VWu7GZbk5mCYhngmRJ8PJ3uA8yajDT2muWm/la5oOI/GeuTgR98tqjXOXmz2NjvE
Zng1CA==
-----END CERTIFICATE-----
subject=CN = kube-apiserver
issuer=CN = kubernetes
---
Acceptable client certificate CA names
CN = kubernetes
Приведенный ниже сертификат является примером корневого сертификата для вышеуказанного сертификата сервера. Убедитесь, что вы добавляете в свои хранилища доверенных сертификатов только те корневые сертификаты, которым вы доверяете.
Например:
cat ca.crt | openssl x509 -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes
Validity
Not Before: Jan 27 19:35:08 2021 GMT
Not After : Jan 25 19:35:08 2031 GMT
Subject: CN = kubernetes
Subject Public Key Info:
Вы можете видеть, что это корневой сертификат, который вам нужен, потому что субъект и эмитент идентичны, и они совпадают с эмитентом сертификата сервера, показанного выше ('kube-apiserver').
Создание хранилища доверенных сертификатов из сертификата ЦС
Создайте дополнительное хранилище доверенных сертификатов, содержащее только ваши сертификаты ЦС, которые будут объединены в АктивномШлюзе во время выполнения со встроенным хранилищем доверенных сертификатов JDK. Хранилище доверия должно быть в формате PKCS12. Форматы OpenSSL не поддерживаются, поэтому используйте команду keytool для выполнения преобразования. После преобразования вы должны поместить сертификат в каталог SSL АктивногоШлюза .
Примечание. Если вы импортируете несколько сертификатов, убедитесь, что вы указали уникальный псевдоним для каждого импортируемого сертификата. Если вы используете один и тот же псевдоним для каждого сертификата, все ранее использовавшиеся сертификаты будут перезаписаны.
Примеры для Linux создания файла PKCS12 из файла CRT или файла PEM и размещения его либо непосредственно в каталоге SSL АктивногоШлюза, либо в текущем каталоге для последующего копирования:
/opt/AstromKey/gateway/jre/bin/keytool -import -file ca.crt -alias dt_k8s_api -storetype pkcs12 -keystore /var/lib/AstromKey/gateway/ssl/mytrusted.p12
или
/opt/AstromKey/gateway/jre/bin/keytool -import -file dt_k8s_api.pem -alias myCertAuthority -storetype pkcs12 -keystore mytrusted.p12
Проверка разрешений
Для Linux проверьте, что пользователь АктивногоШлюза, для которого был установлен АктивныйШлюз (по умолчанию dtuser), имеет права на запись в каталог SSL АктивногоШлюза (по умолчанию /var/lib/AstromKey/gateway/ssl) и что у пользователя есть права на чтение для созданного хранилища доверия.
Настройка АктивногоШлюза для использования хранилища доверенных сертификатов
Чтобы настроить АктивныйШлюз для использования пользовательского файла хранилища доверенных сертификатов mytrusted.p12, убедитесь, что файл хранилища доверенных сертификатов находится в каталоге SSL АктивногоШлюза, а затем добавьте следующие записи в файл custom.properties в каталоге конфигурации АктивногоШлюза:
[collector]
trustedstore = mytrusted.p12
# the following entries are optional
trustedstore-password = changeit
trustedstore-type = PKCS12
Вы можете отобразить настроенный список псевдонимов и описания сертификатов с помощью команды keytool -list в новом хранилище доверенных сертификатов.
Например:
# /opt/AstromKey/gateway/jre/bin/keytool -list -keystore /var/lib/AstromKey/gateway/ssl/mytrusted.p12
Enter keystore password:
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
dt_k8s_api, Apr 26, 2020,
trustedCertEntry,
Certificate fingerprint (SHA-256): 08:18:9A:F2:29:31:0D:64:F0:1F:93:A1:CC:2E:A9:21:E9:DA:40:82:9B:A8:71:B7:A4:2C:6D:8C:B3:90:31:31
Зашифрованный пароль Пароль будет удален и зашифрован при перезапуске службы АктивногоШлюза.
Перезапуск службы АктивногоШлюза и проверка конфигурации сертификата
Перезапустите основную службу АктивногоШлюза, чтобы изменения вступили в силу.
Если все настроено правильно, в журнале АктивногоШлюза должна быть запись следующего содержания:
Custom certificate configuration created successfully.
Исправление проблем
АктивныйШлюз регистрирует свои действия, связанные с вышеуказанной конфигурацией. Настроенное хранилище доверенных сертификатов не будет использоваться (и конфигурация хранилища доверенных сертификатов останется неизменной), если выполняется любое из следующих условий:
- Указано системное свойство
javax.net.ssl.trustStore. Если это свойство указано, оно имеет приоритет над конфигурацией АктивногоШлюза. - Настроенное хранилище доверенных сертификатов не может быть прочитано с использованием настроенного пути, пароля и типа.
- Объединенную конфигурацию нельзя записать в файл
ssl/runtime.cacerts.