Descripción de los cambios en la CA raíz para servidor único de Azure Database for PostgreSQL

Se aplica a: Azure Database for PostgreSQL: servidor único

Importante

El servicio de servidor único de Azure Database for PostgreSQL está en proceso de retirada. Se recomienda encarecidamente actualizar a Azure Database for PostgreSQL: servidor flexible. Para más información sobre la migración al servidor flexible de Azure Database for PostgreSQL, consulte ¿Qué sucede con el servicio de servidor único de Azure Database for PostgreSQL?.

Azure Database for PostgreSQL con servidor único planea el cambio de certificado raíz a partir de diciembre de 2022 (12/2022) como parte del mantenimiento estándar y los procedimientos recomendados de seguridad. En este artículo se proporcionan más detalles sobre los cambios, los recursos afectados y los pasos necesarios para asegurarse de que la aplicación mantenga la conectividad con el servidor de bases de datos.

¿Por qué se requiere la actualización del certificado raíz?

Históricamente, los usuarios de Azure Database for PostgreSQL solo pueden usar el certificado predefinido para conectarse a un servidor de PostgreSQL que se encuentra aquí. Sin embargo, Certificate Authority (CA) Browser Forum recientemente publicó informes relativos a que varios certificados emitidos por proveedores de CA no son compatibles.

Según los requisitos de cumplimiento normativo del sector, los proveedores de CA comenzaron a revocar los certificados de CA de las CA no compatibles, lo que requiere que los servidores usen certificados emitidos por CA compatibles y firmados por certificados de CA de esas CA compatibles. Como Azure Database for PostgreSQL ha utilizado uno de estos certificados no compatibles, necesitábamos rotar el certificado a la versión compatible a fin de minimizar la posible amenaza para los servidores PostgreSQL.

El nuevo certificado se ha implementado y en vigor a partir de diciembre de 2022 (12/2022).

¿Qué cambio se realizó a partir de diciembre de 2022 (12/2022)?

A partir de diciembre de 2022, el certificado raíz BaltimoreCyberTrustRoot se reemplazó por una versión compatible conocida como certificado raíz DigiCertGlobalRootG2. Si las aplicaciones aprovechan verify-ca o verify-full como valor del parámetro sslmodeen la conectividad del cliente de base de datos, deben seguir las instrucciones para agregar nuevos certificados al almacén de certificados para mantener la conectividad.

¿Tengo que hacer algún cambio en mi cliente para mantener la conectividad?

No se requieren cambios en el código ni en la aplicación en el lado cliente. Si ha seguido nuestra recomendación de actualización del certificado, que se indica a continuación, todavía podrá seguir conectándose siempre y cuando no se quite el certificado BaltimoreCyberTrustRoot del certificado de entidad de certificación combinado. Se recomienda no quitar BaltimoreCyberTrustRoot del certificado de CA combinado hasta nuevo aviso para mantener la conectividad.

¿Necesito hacer cambios en los certificado de cliente?

De forma predeterminada, PostgreSQL no realiza ninguna comprobación del certificado de servidor. Esto significa que teóricamente es posible suplantar la identidad del servidor (por ejemplo, modificando un registro DNS o tomando el control de la dirección IP del servidor) sin que el cliente sepa. Para evitar cualquier posibilidad de suplantación de identidad, se debe usar la comprobación del certificado SSL en el cliente. Esta comprobación se puede establecer a través del valor del modo ssl de cadena de conexión cliente de la aplicación: verify-ca o verify-full. Si se eligen estos valores de modo ssl, debe seguir las instrucciones de la sección siguiente.

Recomendación de actualización de certificados de cliente

• Descargue la CA raíz de BaltimoreCyberTrustRoot y DigiCertGlobalRootG2 de los vínculos siguientes:

  • https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
  • https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem

• Opcionalmente, para evitar interrupciones futuras, también se recomienda agregar las siguientes raíces al almacén de confianza:

  • DigiCert Global Root G3 (huella digital: 7e04de896a3e666d00e687d33ffad93be83d349e)
  • Microsoft RSA Root Certificate Authority 2017 (huella digital: 73a5e64a3bff8316ff0edccc618a906e4eae4d74)
  • Microsoft ECC Root Certificate Authority 2017 (huella digital: 999a64c37ff47d9fab95f14769891460eec4c3c5)

• Genere un almacén de certificados de CA combinado que incluya los certificados tanto de BaltimoreCyberTrustRoot como de DigiCertGlobalRootG2.

  • Para los usuarios de Java (PostgreSQL JDBC) que usan DefaultJavaSSLFactory, se debe ejecute:

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

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

    A continuación, reemplace el archivo de almacén de claves original por el nuevo generado:

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

  • En el caso de un usuario de .NET (Npgsql) en Windows, debe asegurarse de que Baltimore CyberTrustRoot y DigiCertGlobalRootG2 existan en el almacén de certificados de Windows, entidades de certificación raíz de confianza. Si no existe alguno de los certificados, importe el certificado que falta.

    

  • En el caso de un usuario de .NET (Npgsql) en Linux con SSL_CERT_DIR, debe asegurarse de que BaltimoreCyberTrustRoot y DigiCertGlobalRootG2 existan en el directorio indicado por SSL_CERT_DIR. Si no existe alguno de los certificados, cree el archivo de certificado que falta.

  • Para otros usuarios de cliente de PostgreSQL, se pueden fusionar dos archivos de certificado de CA con el formato siguiente.

    
    -----BEGIN CERTIFICATE-----
    (Root CA1: BaltimoreCyberTrustRoot.crt.pem)
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    (Root CA2: DigiCertGlobalRootG2.crt.pem)
    -----END CERTIFICATE-----

• Reemplace el archivo PEM de la CA raíz original por el archivo de CA raíz combinado y reinicie la aplicación o el cliente.

• En el futuro, después de que se implemente el nuevo certificado en el servidor, puede cambiar el archivo PEM de la CA a DigiCertGlobalRootG2.crt.pem.

Nota

No elimine ni modifique el certificado de Baltimore hasta que se realice el cambio de certificado. Una vez realizado el cambio se va a enviar una comunicación, después de lo cual es seguro eliminar el certificado de Baltimore.

¿Qué ocurre si se quita el certificado BaltimoreCyberTrustRoot?

Podrían comenzar a recibir errores de conectividad al conectarse al servidor de Azure Database for PostgreSQL. Tiene que configurar de nuevo SSL con el certificado BaltimoreCyberTrustRoot para mantener la conectividad.

Preguntas más frecuentes

1. Si no utilizo SSL/TLS, ¿aún tengo que actualizar la CA raíz?

No se requiere ninguna acción si no se usa SSL/TLS.

2. Si uso SSL/TLS, ¿es necesario reiniciar el servidor de base de datos para actualizar la CA raíz?

No, no es necesario reiniciar el servidor de base de datos para empezar a usar el nuevo certificado. Se trata de un cambio en el lado cliente y las conexiones de cliente entrantes deben usar el nuevo certificado para asegurarse de que puedan conectarse al servidor de bases de datos.

3. ¿Cómo saber si utilizo SSL/TLS con la comprobación del certificado raíz?

Para saber si las conexiones comprueban el certificado raíz, puede revisar la cadena de conexión.

• Si la cadena de conexión incluye sslmode=verify-ca o sslmode=verify-full, tiene que actualizar el certificado.
• Si la cadena de conexión incluye sslmode=disable, sslmode=allow, sslmode=prefer o sslmode=require, no tiene que actualizar los certificados.
• Si la cadena de conexión no especifica sslmode, no tiene que actualizar los certificados.

Si usa un cliente que abstrae la cadena de conexión, revise la documentación del cliente para saber si comprueba los certificados. Para entender sslmode de PostgreSQL, consulte las descripciones del modo SSL en la documentación de PostgreSQL.

4. ¿Qué consecuencia tendrá si se usa App Service con Azure Database for PostgreSQL?

En el caso de los servicios de aplicaciones de Azure que se conectan a Azure Database for PostgreSQL, podemos tener dos escenarios posibles y depende de cómo se use SSL con la aplicación.

• Este nuevo certificado se ha agregado a App Service en el nivel de la plataforma. Si usa en la aplicación los certificados SSL incluidos en la plataforma de App Service, no es necesario realizar ninguna acción.
• Si va a incluir explícitamente la ruta de acceso al archivo de certificado SSL en el código, debería descargar el nuevo certificado y actualizar el código para usar el nuevo certificado. Un buen ejemplo de este escenario es cuando se usan contenedores personalizados de App Service como compartidos en la documentación de App Service.

5. ¿Qué consecuencia tendrá si se usa Azure Kubernetes Service (AKS) con Azure Database for PostgreSQL?

Si está intentando conectarse a Azure Database for PostgreSQL con Azure Kubernetes Services (AKS), es similar a acceder desde un entorno de host de clientes dedicados. Consulte los pasos aquí.

6. ¿Qué consecuencia tendrá si se usa Azure Data Factory para conectarse con Azure Database for PostgreSQL?

Para el conector que usa Azure Integration Runtime, el conector aprovecha los certificados del almacén de certificados de Windows en el entorno hospedado en Azure. Estos certificados ya son compatibles con los certificados recién aplicados y, por lo tanto, no es necesaria ninguna acción.

Para el conector que usa el entorno de ejecución de integración autohospedado donde se incluye explícitamente la ruta de acceso al archivo de certificado SSL en la cadena de conexión, debe descargar el nuevo certificado y actualizar la cadena de conexión para utilizarlo.

7. ¿Es necesario planear un tiempo de inactividad de mantenimiento del servidor de base de datos para este cambio?

No. Dado que el cambio aquí solo está en el lado del cliente para conectarse al servidor de base de datos, este cambio no requiere ningún tiempo de inactividad de mantenimiento para el servidor de base de datos.

8. Si creo un servidor después del 30 de noviembre de 2022, ¿me afectará este cambio?

En el caso de los servidores creados después del 30 de noviembre de 2022, seguirá usando BaltimoreCyberTrustRoot junto con nuevos certificados raíz DigiCertGlobalRootG2 en el almacén de certificados SSL del cliente de base de datos para que las aplicaciones se conecten mediante SSL.

9. ¿Con qué frecuencia actualiza Microsoft sus certificados o cuál es la directiva de expiración?

Los certificados utilizados por Azure Database for PostgreSQL provienen de entidades de certificación (CA) de confianza. Por lo tanto, la compatibilidad de estos certificados está ligada a la compatibilidad de estos certificados por parte de la entidad de certificación. El certificado BaltimoreCyberTrustRoot está programado para que expire en 2025, por lo que Microsoft debe realizar un cambio de certificado antes de la expiración. Además, en caso de que se produzcan errores imprevistos en estos certificados predefinidos, Microsoft debe realizar la rotación de certificados lo más pronto posible, de forma parecida al cambio realizado el 15 de febrero de 2021, para asegurarse de que el servicio siempre sea seguro y compatible.

10. Si utilizo réplicas de lectura, ¿tengo que realizar esta actualización solo en el servidor principal o en las réplicas de lectura?

Puesto que esta actualización es un cambio en el lado cliente, si el cliente leía los datos del servidor réplica, debe aplicar también los cambios para esos clientes.

11. ¿Tenemos que consultar en el lado servidor para comprobar si se está utilizando SSL?

Para comprobar si está usando la conexión SSL para conectarse al servidor, consulte Comprobación de la conexión SSL.

12. ¿Hay alguna acción necesaria si ya tengo DigiCertGlobalRootG2 en el archivo de certificado?

No. No es necesario realizar ninguna acción si el archivo de certificado ya contiene DigiCertGlobalRootG2.

13. ¿Cómo puedo comprobar el certificado enviado por el servidor?

Hay muchas herramientas que puede usar. Por ejemplo, DigiCert tiene una herramienta útil que muestra la cadena de certificados de cualquier nombre de servidor. (Esta herramienta funciona con un servidor accesible públicamente; no se puede conectar al servidor contenido en una red virtual [VNET]). Otra herramienta que puede usar es OpenSSL en la línea de comandos; puede usar la sintaxis siguiente para comprobar los certificados:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

14. ¿Qué hago si tengo más preguntas?

Si tiene alguna pregunta, obtenga respuestas de expertos de la comunidad en Microsoft Q&A. Si tiene un plan de soporte técnico y necesita ayuda técnica, cree una solicitud de soporte técnico:

• En Tipo de problema, seleccione Técnico.
• En Suscripción, seleccione la suscripción.
• En Servicio, seleccione Mis servicios y, después, seleccione Azure Database for PostgreSQL – Servidor único.
• Para Tipo de problema, seleccione Seguridad.
• En Subtipo de problema, seleccione Cifrado de Azure y Cifrado doble de infraestructura.