Обновление сертификатов клиента приложения

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

Это важно

Начиная с 11 ноября 2025 г. в регионах Azure из следующего списка запланирована смена TLS/SSL-сертификатов с использованием новых промежуточных сертификатов ЦС.

центрально-западная часть США
East Asia
UK South

Начиная с 19 января 2026 г., эта смена планируется распространить на все остальные регионы Azure, включая Azure для государственных организаций и все остальные регионы.

Сведения об устранении неполадок см. в разделе "Проблемы с закреплением сертификатов".

Импорт сертификатов корневого ЦС в Хранилище ключей Java на клиенте для сценариев закрепления сертификатов

Пользовательские приложения Java используют хранилище ключей по умолчанию, которое cacertsсодержит сертификаты доверенного центра сертификации (ЦС). Он также часто называется хранилищем доверия Java. Файл сертификатов с именем cacerts находится в каталоге свойств безопасности java.home\lib\security, где java.home — каталог среды выполнения ( jre каталог в пакете SDK или каталог верхнего уровня среды выполнения Java™ 2). Для обновления корневых сертификатов ЦС клиента для сценариев пиннинга клиентских сертификатов с использованием PostgreSQL можно использовать следующие указания.

Проверьте cacerts хранилище ключей Java, чтобы узнать, содержит ли он уже необходимые сертификаты. Вы можете перечислить сертификаты в хранилище ключей Java с помощью следующей команды:
```
  keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt
```
Если необходимые сертификаты отсутствуют в хранилище ключей Java на клиенте, как можно проверить в выходных данных, следует продолжить следующие инструкции:
Создайте резервную копию пользовательского хранилища ключей.
Скачайте сертификаты и сохраните их локально, где можно ссылаться на них.

Создание объединенного хранилища сертификатов ЦС со всеми необходимыми сертификатами корневого ЦС включаются. В приведенном ниже примере показано использование DefaultJavaSSLFactory для пользователей JDBC PostgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file D:\ DigiCertGlobalRootG2.crt.pem   -keystore truststore -storepass password -noprompt

    keytool -importcert -alias PostgreSQLServerCACert2  -file "D:\ Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt

    keytool -importcert -alias PostgreSQLServerCACert  -file D:\ DigiCertGlobalRootCA.crt.pem   -keystore truststore -storepass password -noprompt

Замените исходный файл хранилища ключей новым созданным:

System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
System.setProperty("javax.net.ssl.trustStorePassword","password");

Замените исходный pem-файл корневого ЦС объединенным корневым ЦС и перезапустите приложение или клиент.

Дополнительные сведения о настройке сертификатов клиента с помощью драйвера JDBC PostgreSQL см. в этой документации.

Замечание

Чтобы импортировать сертификаты в хранилища сертификатов клиента, может потребоваться преобразовать файлы CRT сертификата в pem-формат. Служебная программа OpenSSL позволяет выполнять эти преобразования файлов.

Получение списка доверенных сертификатов в Хранилище ключей Java программным способом

По умолчанию Java сохраняет доверенные сертификаты в специальном файле с именем cacerts , который находится в папке установки Java на клиенте. Пример ниже сначала считывает cacerts и загружает его в объект KeyStore :

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

Пароль по умолчанию cacerts используется changeit , но должен отличаться в реальном клиенте, так как администраторы рекомендуют изменять пароль сразу после установки Java. После загрузки объекта KeyStore можно использовать класс PKIXParameters для чтения сертификатов.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Обновление сертификатов корневого ЦС при использовании клиентов в службах приложений Azure для сценариев закрепления сертификатов

Для служб приложений Azure, подключаясь к гибкому экземпляру сервера Базы данных Azure для PostgreSQL, можно использовать два возможных сценария обновления сертификатов клиента, и это зависит от того, как вы используете SSL с приложением, развернутым в Службах приложений Azure.

Новые сертификаты добавляются в службу приложений на уровне платформы до того, как изменения коснутся вашего экземпляра гибкого сервера базы данных Azure для PostgreSQL. Если вы используете SSL-сертификаты, включенные на платформу службы приложений в приложении, никаких действий не требуется. Дополнительные сведения см. в разделе "Добавление TLS/SSL-сертификатов" в Службе приложений Azure и управление ими в документации по службе приложений Azure.
Если вы явно включаете путь к ФАЙЛу SSL-сертификата в коде, вам потребуется скачать новый сертификат и обновить код для его использования. Хорошим примером этого сценария является использование пользовательских контейнеров в Службе приложений, как описано в руководстве. Настройка контейнера бокового контейнера для пользовательского контейнера в Службе приложений Azure в документации по службе приложений Azure.

Обновление сертификатов корневого ЦС при использовании клиентов в службе Azure Kubernetes (AKS) для сценариев закрепления сертификатов

Если вы пытаетесь подключиться к базе данных Azure для PostgreSQL с помощью приложений, размещенных в Службах Azure Kubernetes (AKS) и закреплении сертификатов, это похоже на доступ из выделенной среды узла клиента. Ознакомьтесь с инструкциями здесь.

Обновление сертификатов корневого ЦС для пользователей .NET (Npgsql) в Windows для сценариев закрепления сертификатов

Для пользователей .NET (Npgsql) в Windows, подключающихся к экземплярам гибкого сервера базы данных Azure для PostgreSQL, убедитесь, что все три корневых центра сертификации: Microsoft RSA Root Certificate Authority 2017, DigiCert Global Root G2 и Digicert Global Root CA, существуют в хранилище сертификатов Windows, доверенные корневые центры сертификации. Если какие-либо сертификаты не существуют, импортируйте отсутствующий сертификат.

Обновление сертификатов корневого ЦС для других клиентов для сценариев закрепления сертификатов

Для других пользователей клиента PostgreSQL можно объединить два файла сертификата ЦС с помощью следующего формата:

-----BEGIN CERTIFICATE-----
(Root CA1: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Безопасность в Базе данных Azure для PostgreSQL

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-11-01