Compartir vía

Protección de la conectividad con TLS en Azure Database for PostgreSQL

Azure Database for PostgreSQL aplica la conexión de las aplicaciones cliente a una instancia de servidor flexible de Azure Database for PostgreSQL mediante la seguridad de la capa de transporte (TLS). TLS es un protocolo estándar del sector que garantiza conexiones de red cifradas entre el servidor de bases de datos y las aplicaciones cliente. TLS es un protocolo actualizado de Capa de sockets seguros (SSL). Los términos SSL y TLS se siguen usando indistintamente.

Importante

A partir del 11 de noviembre de 2025, las regiones de Azure de la lista siguiente están programadas para una rotación de certificados TLS/SSL que use nuevos certificados de CA intermedia.

  • Centro-oeste de EE. UU.
  • Este de Asia
  • UK South

A partir del 19 de enero de 2026, esta rotación está planeada para ampliarse a todas las regiones restantes de Azure, incluido Azure Government y todas las demás regiones.

Para obtener información sobre cómo solucionar problemas, consulte Problemas de anclaje de certificados.

Cadenas de certificados

Una cadena de certificados es una lista ordenada de certificados que incluye un certificado TLS/SSL y certificados de entidad de certificación. Permiten al receptor comprobar que el remitente y todas las entidades de certificación son de confianza. La cadena o ruta de acceso comienza con el certificado de TLS/SSL. Cada certificado de la cadena está firmado por la entidad identificada por el siguiente certificado de la cadena.

La cadena finaliza con un certificado de entidad de certificación raíz. Este certificado siempre está firmado por la propia entidad de certificación. Las firmas de todos los certificados de la cadena deben comprobarse hasta el certificado de entidad de certificación raíz.

Cualquier certificado que se encuentra entre el certificado TLS/SSL y el certificado de entidad de certificación raíz de la cadena se denomina certificado intermedio.

Versiones de TLS

Varias entidades gubernamentales en todo el mundo mantienen directrices para TLS con respecto a la seguridad de red. En los Estados Unidos, estas organizaciones incluyen el Departamento de salud y servicios humanos y el National Institute of Standards and Technology. El nivel de seguridad que proporciona TLS se ve más afectado por la versión del protocolo TLS y los conjuntos de cifrado admitidos.

Un conjunto de cifrado es un grupo de algoritmos que incluyen un cifrado, un algoritmo de intercambio de claves y un algoritmo hash. Se usan juntos para establecer una conexión TLS segura. La mayoría de los clientes y servidores TLS admiten varias alternativas. Tienen que negociar cuando establecen una conexión segura para seleccionar una versión común de TLS y un conjunto de cifrado.

Azure Database for PostgreSQL admite TLS versión 1.2 y versiones posteriores. En RFC 8996, el Grupo de tareas de ingeniería de Internet (IETF) indica explícitamente que no se deben usar TLS 1.0 ni TLS 1.1. Ambos protocolos quedaron en desuso a finales de 2019.

Se denegarán de manera predeterminada todas las conexiones entrantes que usen versiones anteriores del protocolo TLS, como TLS 1.0 y TLS 1.1.

El IETF publicó la especificación TLS 1.3 en el RFC 8446 de agosto de 2018, y TLS 1.3 ahora es la versión de TLS más común y recomendada en uso. TLS 1.3 es más rápido y seguro que TLS 1.2.

Nota:

Los certificados SSL y TLS certifican que la conexión está protegida con protocolos de cifrado de última generación. Al cifrar la conexión en la red, se evita el acceso no autorizado a los datos mientras están en tránsito. Se recomienda encarecidamente usar las versiones más recientes de TLS para cifrar las conexiones a una instancia de servidor flexible de Azure Database for PostgreSQL.

Aunque no se recomienda, si es necesario, puede deshabilitar TLS\SSL para las conexiones a la instancia de servidor flexible de Azure Database for PostgreSQL. Puede actualizar el parámetro de servidor de require_secure_transport a OFF. También puede establecer la versión del TLS estableciendo los parámetros de servidor ssl_min_protocol_version y ssl_max_protocol_version.

La autenticación de certificados se realiza mediante certificados de cliente SSL para la autenticación. En este escenario, el servidor PostgreSQL compara el atributo de nombre común (CN) del certificado de cliente presentado con el usuario de base de datos solicitado.

En este momento, Azure Database for PostgreSQL no admite:

Nota:

Microsoft realizó cambios de entidad de certificación raíz para varios servicios de Azure, incluido Azure Database for PostgreSQL. Para obtener más información, consulte Cambios en los certificados TLS de Azure y la sección Configuración de SSL en el cliente.

Para determinar el estado actual de la conexión TLS/SSL, puede cargar la extensión sslinfo y, después, llamar a la función ssl_is_used() para determinar si se usa SSL. La función devuelve t si la conexión usa SSL. En caso contrario, devuelve f. También puede recopilar toda la información sobre el uso ssl de la instancia de servidor flexible de Azure Database for PostgreSQL mediante el proceso, el cliente y la aplicación mediante la consulta siguiente:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Para realizar pruebas, también puede usar el comando openssl directamente:

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

Este comando muestra información de protocolo de bajo nivel, como la versión de TLS y el cifrado. Debe usar la opción -starttls postgres. De lo contrario, este comando informa de que no hay ningún SSL en uso. El uso de este comando requiere al menos OpenSSL 1.1.1.

Para aplicar la versión más reciente y segura de TLS para la protección de la conectividad desde el cliente hacia una instancia de servidor flexible de Azure Database for PostgreSQL, establezca ssl_min_protocol_version en 1.3. Esa configuración requiere que los clientes que se conecten a la instancia de servidor flexible de Azure Database for PostgreSQL usen esta versión del protocolo solo para comunicarse de forma segura. Es posible que los clientes más antiguos no puedan comunicarse con el servidor porque no admiten esta versión.

Configuración de SSL en el cliente

De forma predeterminada, PostgreSQL no realiza ninguna comprobación del certificado de servidor. Por este motivo, es posible suplantar la identidad (spoofing) del servidor (por ejemplo, modificando un registro DNS o tomando el control de la dirección IP del servidor) sin que el cliente lo sepa. Todas las opciones SSL tienen sobrecarga en forma de cifrado e intercambio de claves, por lo que se produce una compensación entre el rendimiento y la seguridad.

Para evitar cualquier la suplantación de identidad, se debe usar la comprobación de certificados SSL en el cliente.

Hay muchos parámetros de conexión para configurar el cliente para SSL. Estos son algunos de los importantes:

  • ssl: conexión mediante SSL. Esta propiedad no necesita un valor asociado. Su mera presencia especifica una conexión SSL. Para la compatibilidad con versiones futuras, se prefiere el valor true. En este modo, cuando establece una conexión SSL, el controlador cliente valida la identidad del servidor para prevenir ataques de intermediario. Comprueba que el certificado de servidor esté firmado por una entidad de confianza y que el host al que se conecta es el mismo que el nombre de host del certificado.

  • sslmode: si necesita cifrado y quiere que se produzca un error en la conexión si no se puede cifrar, establezca sslmode=require. Este ajuste garantiza que el servidor esté configurado para aceptar conexiones SSL para esta dirección IP o host y que el servidor reconozca el certificado de cliente. Si el servidor no acepta conexiones SSL o el certificado de cliente no se reconoce, se produce un error en la conexión. En la tabla siguiente, se detallan los valores de esta configuración:

    SSL Mode Explanation
    disable No se usa cifrado.
    allow El cifrado se usa si la configuración del servidor la requiere o la aplica.
    prefer Se usa cifrado si la configuración del servidor lo permite.
    require Se usa cifrado. Esto garantiza que el servidor esté configurado para aceptar conexiones SSL para esta dirección IP de host y que el servidor reconozca el certificado de cliente.
    verify-ca Se usa cifrado. Compruebe la firma del certificado de servidor en comparación con el certificado almacenado en el cliente.
    verify-full Se usa cifrado. Compruebe la firma del certificado de servidor y el nombre de host en comparación con el certificado almacenado en el cliente.

El modo predeterminado sslmode usado es diferente entre los clientes basados en libpq (como psql) y JDBC. Los clientes basados en libpq tienen prefer como valor predeterminado. Los clientes JDBC tienen verify-full como valor predeterminado.

  • sslcert, sslkey y sslrootcert: estos parámetros pueden invalidar la ubicación predeterminada del certificado de cliente, la clave de cliente de PKCS-8 y el certificado raíz. El valor predeterminado es /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8y /defaultdir/root.crt, respectivamente, donde defaultdir está ${user.home}/.postgresql/ en sistemas Linux y %appdata%/postgresql/ en Windows.

Las entidades de certificación (CA) son las instituciones responsables de emitir certificados. Una entidad de certificación de confianza es una entidad autorizada para verificar que alguien es quien dice ser. Para que este modelo funcione, todos los participantes deben aceptar un conjunto de CA de confianza. Todos los sistemas operativos y la mayoría de los exploradores web se envían con un conjunto de CA de confianza.

El uso de las opciones de configuración verify-ca y verify-fullsslmode también se puede conocer como asignación de certificados. En este caso, los certificados de entidad de certificación raíz en el servidor de PostgreSQL tienen que coincidir con la firma del certificado e, incluso, el nombre de host con el certificado en el cliente.

Es posible que tenga que actualizar periódicamente los certificados almacenados por el cliente cuando las CA cambien o expiren en los certificados de servidor de PostgreSQL. Para determinar si va a asignar CA, consulte Asignación de certificados y servicios de Azure.

Para más información sobre la configuración de SSL\TLS en el cliente, consulte la documentación de PostgreSQL.

Para los clientes que usan las opciones de configuración verify-ca y verify-fullsslmode (es decir, la asignación de certificados), deben implementar tres certificados de entidad de certificación raíz en los almacenes de certificados de cliente:

Descarga de certificados de CA raíz y actualización de clientes de aplicaciones en escenarios de asignación de certificados

Para actualizar las aplicaciones cliente en escenarios de asignación de certificados, puede descargar los certificados:

Para importar certificados a almacenes de certificados de cliente, es posible que tenga que convertir archivos de certificado .crt al formato .pem después de descargar los archivos de certificado de los URI anteriores. Puede usar la utilidad de OpenSSL para realizar estas conversiones de archivos:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

La información sobre la actualización de almacenes de certificados de aplicaciones cliente con nuevos certificados de entidad de certificación raíz se documenta en Actualización de certificados TLS de cliente para clientes de aplicaciones.

Importante

Algunas de las bibliotecas cliente de Postgres, al usar la configuración sslmode=verify-full, pueden experimentar errores de conexión con certificados de entidad de certificación raíz que estén firmados entre sí con certificados intermedios. El resultado son rutas de acceso de confianza alternativas. En este caso, se recomienda especificar explícitamente el parámetro sslrootcert. O bien, establezca la variable de entorno PGSSLROOTCERT en una ruta de acceso local en la que se coloque el CA raíz Microsoft RSA Root CA 2017, desde el valor predeterminado de %APPDATA%\postgresql\root.crt.

  1. Se experimenta una pérdida de conexión desde la aplicación cliente a la instancia de servidor flexible de Azure Database for PostgreSQL; se ha abierto un ticket de soporte técnico.
  2. Si su certificado intermedio ha sido cambiado, es posible que tenga que actualizar el almacén de certificados de su cliente con el nuevo certificado intermedio.
  3. cómo comprobar si está anclando su certificado intermedio: consulte Anclaje de certificados y servicios de Azure.

Réplicas de lectura con escenarios de asignación de certificados

Con la migración de CA raíz a Microsoft RSA Root CA 2017, es factible que las réplicas recién creadas estén en un certificado de CA raíz más reciente que el del servidor principal que se creó anteriormente. Para los clientes que usan los valores de configuración verify-ca y verify-fullsslmode (es decir, asignación de certificados), es imperativo que la conectividad interrumpida acepte tres certificados de entidad de certificación raíz:

En este momento, Azure Database for PostgreSQL no admite la autenticación basada en certificados.

Prueba de certificados de cliente mediante la conexión con psql en escenarios de asignación de certificados

Puede usar la línea de comandos psql desde el cliente para probar la conectividad con el servidor en escenarios de asignación de certificados:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Para obtener más información sobre los parámetros de certificado y SSL, consulte la documentación de psql.

Prueba de la conectividad TLS/SSL

Antes de intentar acceder al servidor habilitado para SSL desde una aplicación cliente, asegúrese de que puede acceder a él a través de psql. Si estableció una conexión SSL, debería ver una salida similar al ejemplo siguiente:

psql (14.5)SSL connection (protocolo: TLSv1.2, cifrado: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compresión: desactivada)Escriba "ayuda" para obtener ayuda.

También puede cargar la extensión sslinfo y, luego, llamar a la función ssl_is_used() para determinar si se usa SSL. La función devuelve t si la conexión usa SSL. En caso contrario, devuelve f.

Conjuntos de cifrado

Un conjunto de cifrado es un conjunto de algoritmos criptográficos. Los protocolos TLS/SSL usan algoritmos de un conjunto de cifrado para crear claves y cifrar información.

Un conjunto de cifrado se muestra como una cadena larga de información aparentemente aleatoria, pero cada segmento de esa cadena contiene información esencial. Por lo general, esta cadena de datos incluye varios componentes clave:

  • Protocolo (es decir, TLS 1.2 o TLS 1.3)
  • Algoritmo de intercambio de claves o contrato
  • Algoritmo de firma digital (autenticación)
  • Algoritmo de cifrado masivo
  • Algoritmo de código de autenticación de mensajes (MAC)

Diferentes versiones de TLS/SSL admiten diferentes conjuntos de cifrado. Los conjuntos de cifrado TLS 1.2 no se pueden negociar con conexiones TLS 1.3 y viceversa.

En este momento, Azure Database for PostgreSQL admite muchos conjuntos de cifrado con la versión del protocolo TLS 1.2 que se encuentra en la categoría HIGH:!aNULL .

Troubleshoot

Use las instrucciones de esta sección solución de problemas para identificar y resolver rápidamente problemas comunes de TLS/SSL. Empiece reproduciendo el problema y recopilando datos de diagnóstico (mensajes de error del lado del cliente, salida psql, salida de OpenSSL s_client y registros de servidor), luego compruebe los parámetros del servidor (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), la cadena de certificados y la configuración sslmode/sslrootcert del cliente para identificar desajustes en las versiones de protocolo, conjuntos de cifrado o certificados que faltan o rotan.

Errores de conectividad TLS/SSL

  1. El primer paso para solucionar problemas de compatibilidad de versiones del protocolo TLS/SSL es identificar los mensajes de error que usted o los usuarios ven cuando intentan acceder a la instancia de servidor flexible de Azure Database for PostgreSQL en cifrado TLS desde el cliente. Dependiendo de la aplicación y la plataforma, los mensajes de error pueden ser diferentes. En muchos casos, apuntan al problema subyacente.
  2. Para asegurarse de la compatibilidad de versiones del protocolo TLS/SSL, compruebe la configuración TLS/SSL del servidor de bases de datos y el cliente de la aplicación para comprobar que admiten versiones compatibles y conjuntos de cifrado.
  3. Analice las discrepancias o brechas entre el servidor de bases de datos y las versiones TLS/SSL del cliente y los conjuntos de cifrado. Intente resolverlos habilitando o deshabilitando determinadas opciones, actualizando o degradando software, o cambiando certificados o claves. Por ejemplo, es posible que tenga que habilitar o deshabilitar versiones específicas de TLS/SSL en el servidor o el cliente, en función de los requisitos de seguridad y compatibilidad. Por ejemplo, es posible que tenga que deshabilitar TLS 1.0 y TLS 1.1, que se consideran no seguros y en desuso, y habilitar TLS 1.2 y TLS 1.3, que son más seguros y modernos.
  4. El certificado más reciente emitido con Microsoft RSA Root CA 2017 tiene un nivel intermedio en la cadena firmado por Digicert Global Root G2 CA. Algunas de las bibliotecas cliente de Postgres, al usar sslmode=verify-full o sslmode=verify-ca configuración, pueden experimentar errores de conexión con certificados de entidad de certificación raíz firmados con certificados intermedios. El resultado son rutas de acceso de confianza alternativas.

Para solucionar estos problemas, agregue los tres certificados necesarios al almacén de certificados de cliente o especifique explícitamente el parámetro sslrootcert. O bien, establezca la variable de entorno PGSSLROOTCERT en la ruta de acceso local en la que se coloque el CA raíz Microsoft RSA Root CA 2017, desde el valor predeterminado de %APPDATA%\postgresql\root.crt.

Problemas de anclaje de certificados

Nota:

Si no usa las configuraciones sslmode=verify-full o sslmode=verify-ca en la cadena de conexión de la aplicación del cliente, las rotaciones de certificados no le afectan. Por lo tanto, no es necesario seguir los pasos descritos en esta sección.

  1. Compruebe si usa la asignación de certificados en la aplicación.
  2. Genera tu lista de certificados que se encuentran en el almacén raíz de confianza
    1. Por ejemplo, puede obtener una lista de certificados de confianza en el Almacén de claves de Java mediante programación.
    2. Por ejemplo, puede comprobar el almacén de claves java de cacerts para ver si ya contiene certificados necesarios.
  3. Está utilizando la asignación de certificados si tiene certificados intermedios individuales o certificados de servidor PostgreSQL individuales.
  4. Para quitar el anclaje de certificados, quite todos los certificados del almacén raíz de confianza y agregue los nuevos certificados.
    1. Puede descargar los certificados actualizados del repositorio oficial de Microsoft: detalles de la entidad de certificación de Azure.
      1. Cadena actual:
        1. DigiCert Global Root G2
        2. Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      2. Nueva cadena:
        1. DigiCert Global Root G2
        2. Raíz de RSA G2 de Microsoft TLS
        3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

Si tiene problemas incluso después de seguir estos pasos, póngase en contacto con el soporte técnico de Microsoft. Incluya en el título ICA Rotation 2026.

Contenido relacionado

  • Last updated on