Descripción de los cambios en la CA raíz para Azure Database for MariaDB

Importante

Azure Database for MariaDB está en proceso de retirada. Se recomienda encarecidamente migrar a Azure Database for MySQL. Para más información sobre la migración a Azure Database for MySQL, consulte ¿Qué ocurre con Azure Database for MariaDB?.

Azure Database for MariaDB como parte de los procedimientos recomendados de mantenimiento y seguridad estándar completarán el cambio de certificado raíz a partir de marzo de 2023. 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 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 MariaDB solo pueden usar el certificado predefinido para conectarse a su servidor mariaDB, 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 MariaDB usó uno de estos certificados no compatibles, tuvimos que 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

• Descargue BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 ca desde los vínculos siguientes:

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

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

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

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

    keytool -importcert -alias MariaDBServerCACert2  -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 MariaDB/NET, MariaDBConnector), asegúrese de BaltimoreCyberTrustRoot y DigiCertGlobalRootG2 existen 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 (MariaDB Client/MariaDB Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift), puede combinar dos archivos de certificado de CA como en 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.

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.

¿Qué ocurre si se quita el certificado BaltimoreCyberTrustRoot?

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

Preguntas más frecuentes

1. Si no uso SSL/TLS, ¿todavía necesito actualizar la CA raíz?

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

2. Si uso SSL/TLS, ¿necesito reiniciar mi servidor de bases 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. La actualización del certificado es un cambio en el lado cliente y las conexiones de cliente entrantes deben usar el nuevo certificado para asegurarse de que pueden 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-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.

4. ¿Cuál es el impacto si se usa App Service con Azure Database for MariaDB?

En el caso de los servicios de aplicaciones de Azure que se conectan a Azure Database for MariaDB, hay 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. Se trata del escenario más habitual.
• Si incluye explícitamente la ruta de acceso al archivo de certificado SSL en el código, deberá 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 en 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.

5. ¿Cuál es el impacto si se usa Azure Kubernetes Services (AKS) con Azure Database for MariaDB?

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

6. ¿Cuál es el impacto si se usa Azure Data Factory para conectarse a Azure Database for MariaDB?

Para el 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.

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. ¿Con qué frecuencia Actualiza Microsoft sus certificados o cuál es la directiva de expiración?

Los certificados utilizados por Azure Database for MariaDB 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.

9. Si uso réplicas de lectura, ¿necesito 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.

10. Si uso la replicación de datos de entrada, ¿es necesario realizar alguna acción?

• Si la replicación de datos es de una máquina virtual (local o de Azure) a 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 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 es de una máquina virtual (local o de Azure) a 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 el certificado se proporciona para CA_file, SSL_Cert y SSL_Key, deberá actualizar el archivo mediante la adición del nuevo certificado y crear un archivo de certificado combinado.

• Si la replicación de datos se realiza entre dos instancias 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.

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. ¿Qué ocurre 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.