Descripción de los cambios en la entidad de certificación raíz para un único servidor de Azure Database for MySQL

SE APLICA A: Azure Database for MySQL: Servidor único

Importante

El servidor único de Azure Database for MySQL está en la ruta de retirada. Se recomienda encarecidamente actualizar al servidor flexible de Azure Database for MySQL. Para más información sobre la migración al servidor flexible de Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MySQL con servidor único?

Servidor único de Azure Database for MySQL, como parte de los procedimientos recomendados de mantenimiento y seguridad estándar, completará el cambio de certificado raíz a partir de octubre de 2022. 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.

Nota

Este artículo SOLO se aplica a Azure Database for MySQL: servidor único. En el caso de Azure Database for MySQL: servidor flexible, el certificado necesario para comunicarse a través de SSL es la entidad de certificación raíz global DigiCert.

Este artículo contiene referencias al término esclavo, un término que Microsoft ya no usa. Cuando se elimine el término del software, se eliminará también de este artículo.

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

Los usuarios de Azure Database for MySQL solo pueden utilizar el certificado predefinido para conectarse a su servidor MySQL, 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.

De acuerdo con 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 MySQL 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 MySQL.

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

Si ha seguido los pasos mencionados en Creación de un certificado de CA combinado a continuación, podrá seguir conectándose siempre y cuando no se quite el certificado BaltimoreCyberTrustRoot del certificado de CA combinado. Para mantener la conectividad, se recomienda conservar BaltimoreCyberTrustRoot del certificado de CA combinado hasta nuevo aviso.

Creación de un certificado de CA combinado

Para evitar que se interrumpa la disponibilidad de la aplicación como resultado de la revocación inesperada de certificados, o para actualizar un certificado que se ha revocado, siga los pasos que se indican a continuación. La idea es crear un nuevo archivo .pem, que combine el certificado actual y el nuevo y, durante la validación del certificado SSL, se usará uno de los valores permitidos. Consulte los pasos siguientes:

1. Descargue la entidad de certificación 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

2. Genere un almacén de certificados de CA combinado que incluya los certificados BaltimoreCyberTrustRoot y DigiCertGlobalRootG2.

   • Para los usuarios de Java (Conector de MySQL/J), ejecute lo siguiente:

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

     keytool -importcert -alias MySQLServerCACert2 -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");

   • Para los usuarios de .NET (Conector de MySQL/NET, MySQLConnector), asegúrese de que BaltimoreCyberTrustRoot y DigiCertGlobalRootG2 existan en el almacén de certificados de Windows, en las entidades de certificación raíz de confianza. Si no existe alguno de los certificados, importe el certificado que falta.

     

   • En el caso de los usuarios de .NET 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 (MySQL Client/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift), puede combinar dos archivos de certificado de CA en de la forma siguiente:

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

3. 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 lado servidor, puede cambiar el archivo PEM de CA a DigiCertGlobalRootG2.crt.pem.

Nota

No elimine ni modifique el certificado de Baltimore hasta que se realice el cambio de certificado. Enviaremos una comunicación después de realizar el cambio y, después, será seguro eliminar el certificado de Baltimore.

¿Qué ocurre si se quita el certificado BaltimoreCyberTrustRoot?

Comenzarán a producirse errores de conectividad al conectarse al servidor de Azure Database for MySQL. Tendrá que volver a configurar SSL con el certificado BaltimoreCyberTrustRoot para mantener la conectividad.

Preguntas más frecuentes

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.

¿Cuándo se someterá a un cambio de certificado raíz mi instancia de servidor único?

La migración desde BaltimoreCyberTrustRoot a DigiCertGlobalRootG2 se llevará a cabo en todas las regiones de Azure a partir de octubre de 2022 por fases. Para asegurarse de que no pierde la conectividad con el servidor, siga los pasos mencionados en Creación de un certificado de CA combinado. El certificado de CA combinado permitirá la conectividad a través de SSL a la instancia de servidor único con cualquiera de estos dos certificados.

¿Cuándo se puede quitar el certificado BaltimoreCyberTrustRoot del todo?

Una vez que la migración se haya completado correctamente en todas las regiones de Azure, enviaremos una publicación de comunicación indicando que es seguro cambiar el certificado de CA DigiCertGlobalRootG2 único.

No especifico ningún certificado de CA al conectarme a mi instancia de servidor único a través de SSL, ¿todavía necesito realizar los pasos mencionados anteriormente?

Si tiene el certificado raíz de la CA en el almacén raíz de confianza, no se requieren más acciones. Esto también se aplica a los controladores de cliente que usan el almacén local para acceder al certificado de CA raíz.

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. Este certificado raíz es un cambio en el lado cliente y las conexiones de cliente entrantes deben usarlo para poder conectarse al servidor de bases de datos.

¿Cómo puedo saber si estoy usando 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-identity, 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.

¿Qué consecuencia tendrá el uso de App Service con Azure Database for MySQL?

En el caso de los servicios de aplicaciones de Azure que se conectan a Azure Database for MySQL, hay dos escenarios posibles en función 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. Se trata del escenario más habitual.
• Si va a incluir explícitamente la ruta de acceso al archivo de certificado SSL en el código, tendrá que descargar el nuevo certificado y generar un certificado combinado, tal y como se ha mencionado anteriormente, y utilizar el archivo de 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. Se trata de un escenario poco común, pero hemos visto algunos usuarios que los utilizan.

¿Qué consecuencia tendrá el uso de Azure Kubernetes Service (AKS) con Azure Database for MySQL?

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

¿Qué consecuencias tendrá el uso de Azure Data Factory para conectarse a Azure Database for MySQL?

Para un conector que usa Azure Integration Runtime, el conector usa 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, deberá descargar el nuevo certificado y actualizar la cadena de conexión para utilizarlo.

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

No. Dado que el cambio solo se da en el lado 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.

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

Estos certificados utilizados por Azure Database for MySQL 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 deberá 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 tendrá que realizar la rotación de certificados lo antes posible, de forma parecida al cambio realizado el 15 de febrero de 2021, para asegurarse de que el servicio sea seguro y compatible en todo momento.

Si utilizo réplicas de lectura, ¿tengo que realizar esta actualización solo en el servidor de origen 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, deberá aplicar también los cambios para esos clientes.

Si estoy usando la replicación de datos de entrada, ¿es necesario llevar a cabo alguna acción?

Si usa la replicación de datos de entrada para conectarse a Azure Database for MySQL, hay dos aspectos que deben tenerse en cuenta:

• Si la replicación de datos se realiza desde una máquina virtual (local o de Azure) en Azure Database for MySQL, debe comprobar si se usa SSL para crear la réplica. Ejecute SHOW SLAVE STATUS (MOSTRAR ESTADO DEL ELEMENTO SECUNDARIO) y compruebe la siguiente configuración.

  Master_SSL_Allowed            : Yes
  Master_SSL_CA_File            : ~\azure_mysqlservice.pem
  Master_SSL_CA_Path            :
  Master_SSL_Cert               : ~\azure_mysqlclient_cert.pem
  Master_SSL_Cipher             :
  Master_SSL_Key                : ~\azure_mysqlclient_key.pem
  

  Si observa que se proporciona el certificado para CA_file, SSL_Cert y SSL_Key, deberá actualizar el archivo agregando el nuevo certificado y crear un archivo de certificado combinado.

• Si la replicación de datos se realiza entre dos servidores de Azure Database for MySQL, deberá restablecer la réplica ejecutando CALL mysql.az_replication_change_master y proporcionar el nuevo certificado raíz dual como último parámetro master_ssl_ca.

¿Hay una consulta del lado servidor para determinar si se usa SSL?

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

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

¿Por qué necesito actualizar mi certificado raíz si utilizo el controlador PHP con enableRedirect?

Para satisfacer los requisitos de cumplimiento, los certificados de CA del servidor host se cambiaron de BaltimoreCyberTrustRoot a DigiCertGlobalRootG2. Con esta actualización, las conexiones de base de datos que usan el controlador de cliente PHP con enableRedirect ya no se pueden conectarse al servidor, ya que los dispositivos cliente no conocen el cambio del certificado ni los nuevos detalles de la CA raíz. Los dispositivos cliente que usan controladores de redireccionamiento PHP se conectan directamente al servidor host, pasando la puerta de enlace. Consulte este vínculo para obtener más información sobre la arquitectura del servidor único de Azure Database for MySQL.

¿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, póngase en contacto con nosotros.