Compreendendo as alterações na alteração da autoridade de certificação raiz para o banco de dados do Azure para servidor único MySQL

APLICA-SE A: Banco de Dados do Azure para MySQL - Servidor Único

Importante

O servidor único do Banco de Dados do Azure para MySQL está no caminho de desativação. É altamente recomendável que você atualize para o Banco de Dados do Azure para o servidor flexível MySQL. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para servidor flexível MySQL, consulte O que está acontecendo com o Banco de Dados do Azure para Servidor Único MySQL?

O Banco de Dados do Azure para servidor único MySQL, como parte das práticas recomendadas de manutenção e segurança padrão, concluirá a alteração do certificado raiz a partir de outubro de 2022. Este artigo fornece mais detalhes sobre as alterações, os recursos afetados e as etapas necessárias para garantir que seu aplicativo mantenha a conectividade com o servidor de banco de dados.

Nota

Este artigo aplica-se ao Banco de Dados do Azure para MySQL - Servidor Único APENAS. Para o Banco de Dados do Azure para MySQL - Servidor Flexível, o certificado necessário para se comunicar por SSL é DigiCert Global Root CA

Este artigo poderá conter referências ao termo slave (secundário), um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.

Por que é necessária uma atualização de certificado raiz?

Os usuários do Banco de Dados do Azure para MySQL só podem usar o certificado predefinido para se conectar ao servidor MySQL, que está localizado aqui. No entanto, o fórum Navegador da Autoridade de Certificação (CA) publicou recentemente relatórios de vários certificados emitidos por fornecedores de CA como não compatíveis.

De acordo com os requisitos de conformidade do setor, os fornecedores de CA começaram a revogar certificados de CA para CAs não compatíveis, exigindo que os servidores usassem certificados emitidos por CAs compatíveis e assinados por certificados de CA dessas CAs compatíveis. Como o Banco de Dados do Azure para MySQL usou um desses certificados não compatíveis, precisávamos girar o certificado para a versão compatível para minimizar a ameaça potencial aos seus servidores MySQL.

Preciso fazer alguma alteração no meu cliente para manter a conectividade?

Se você seguiu as etapas mencionadas em Criar um certificado de autoridade de certificação combinado abaixo, poderá continuar a se conectar desde que o certificado BaltimoreCyberTrustRoot não seja removido do certificado de autoridade de certificação combinado. Para manter a conectividade, recomendamos que você mantenha o BaltimoreCyberTrustRoot em seu certificado de CA combinado até novo aviso.

Criar um certificado de autoridade de certificação combinado

Para evitar a interrupção da disponibilidade do seu aplicativo como resultado de certificados sendo revogados inesperadamente, ou para atualizar um certificado que foi revogado, use as etapas a seguir. A ideia é criar um novo arquivo .pem, que combine o certificado atual e o novo e, durante a validação do certificado SSL, um dos valores permitidos será usado. Consulte as seguintes etapas:

1. Baixar BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Root CA a partir dos seguintes links:

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

2. Gere um armazenamento de certificados de CA combinado com os certificados BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 incluídos.

   • Para usuários Java (MySQL Connector/J), execute:

     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
     

     Em seguida, substitua o arquivo keystore original pelo novo gerado:

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

   • Para usuários .NET (MySQL Connector/NET, MySQLConnector), certifique-se de que BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 existem no Windows Certificate Store, Trusted Root Certification Authorities. Se não existirem certificados, importe o certificado em falta.

     

   • Para usuários .NET no Linux usando SSL_CERT_DIR, certifique-se de que BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 existam no diretório indicado por SSL_CERT_DIR. Se nenhum certificado existir, crie o arquivo de certificado ausente.

   • Para outros usuários (MySQL Client/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift), você pode mesclar dois arquivos de certificado de CA no seguinte formato:

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

3. Substitua o arquivo pem da autoridade de certificação raiz original pelo arquivo de autoridade de certificação raiz combinada e reinicie o aplicativo/cliente.

   No futuro, depois que o novo certificado for implantado no lado do servidor, você poderá alterar seu arquivo pem da CA para DigiCertGlobalRootG2.crt.pem.

Nota

Por favor, não deixe cair ou altere o certificado de Baltimore até que a alteração do certificado seja feita. Enviaremos uma comunicação após a alteração ser feita e, em seguida, será seguro deixar cair o certificado de Baltimore.

E se removermos o certificado BaltimoreCyberTrustRoot?

Você começará a encontrar erros de conectividade ao se conectar ao seu Banco de Dados do Azure para servidor MySQL. Você precisará configurar o SSL com o certificado BaltimoreCyberTrustRoot novamente para manter a conectividade.

Perguntas mais frequentes

Se eu não estiver usando SSL/TLS, ainda preciso atualizar a autoridade de certificação raiz?

Nenhuma ação será necessária se você não estiver usando SSL/TLS.

Quando minha instância de servidor único sofrerá alteração de certificado raiz?

A migração de BaltimoreCyberTrustRoot para DigiCertGlobalRootG2 será realizada em todas as regiões do Azure a partir de outubro de 2022 em fases. Para garantir que você não perca a conectividade com o servidor, siga as etapas mencionadas em Criar um certificado de autoridade de certificação combinado. O certificado de autoridade de certificação combinado permitirá a conectividade por SSL com sua instância de servidor único com qualquer um desses dois certificados.

Quando posso remover completamente o certificado BaltimoreCyberTrustRoot?

Quando a migração for concluída com êxito em todas as regiões do Azure, enviaremos uma postagem de comunicação informando que você está seguro para alterar um único certificado CA DigiCertGlobalRootG2 .

Eu não especifico nenhum certificado de CA ao me conectar à minha instância de servidor único por SSL, ainda preciso executar as etapas mencionadas acima?

Se você tiver o certificado raiz da autoridade de certificação em seu armazenamento raiz confiável, nenhuma ação adicional será necessária. Isso também se aplica aos drivers de cliente que usam o armazenamento local para acessar o certificado de autoridade de certificação raiz.

Se eu estiver usando SSL/TLS, preciso reiniciar meu servidor de banco de dados para atualizar a autoridade de certificação raiz?

Não, não é necessário reiniciar o servidor de banco de dados para começar a usar o novo certificado. Esse certificado raiz é uma alteração do lado do cliente e as conexões de cliente de entrada precisam usar o novo certificado para garantir que possam se conectar ao servidor de banco de dados.

Como sei se estou usando SSL/TLS com verificação de certificado raiz?

Você pode identificar se suas conexões verificam o certificado raiz examinando sua cadeia de conexão.

• Se a cadeia de conexão incluir sslmode=verify-ca ou sslmode=verify-identity, você precisará atualizar o certificado.
• Se a cadeia de conexão incluir sslmode=disable, , , ou , sslmode=allowsslmode=prefersslmode=requirevocê não precisará atualizar certificados.
• Se sua cadeia de conexão não especificar sslmode, você não precisará atualizar certificados.

Se você estiver usando um cliente que abstrai a cadeia de conexão, revise a documentação do cliente para entender se ele verifica certificados.

Qual é o impacto de usar o Serviço de Aplicativo com o Banco de Dados do Azure para MySQL?

Para serviços de aplicativo do Azure que se conectam ao Banco de Dados do Azure para MySQL, há dois cenários possíveis, dependendo de como você está usando SSL com seu aplicativo.

• Esse novo certificado foi adicionado ao Serviço de Aplicativo no nível da plataforma. Se você estiver usando os certificados SSL incluídos na plataforma do Serviço de Aplicativo em seu aplicativo, nenhuma ação será necessária. Este é o cenário mais comum.
• Se você estiver incluindo explicitamente o caminho para o arquivo de certificado SSL em seu código, precisará baixar o novo certificado e produzir um certificado combinado, conforme mencionado acima, e usar o arquivo de certificado. Um bom exemplo desse cenário é quando você usa contêineres personalizados no Serviço de Aplicativo conforme compartilhado na documentação do Serviço de Aplicativo. Este é um cenário incomum, mas temos visto alguns usuários usando isso.

Qual é o impacto de usar o Azure Kubernetes Services (AKS) com o Banco de Dados do Azure para MySQL?

Se você estiver tentando se conectar ao Banco de Dados do Azure para MySQL usando o Azure Kubernetes Services (AKS), é semelhante ao acesso de um ambiente de host de clientes dedicado. Consulte as etapas aqui.

Qual é o impacto de usar o Azure Data Factory para se conectar ao Banco de Dados do Azure para MySQL?

Para um conector usando o Tempo de Execução de Integração do Azure, o conector usa certificados no Repositório de Certificados do Windows no ambiente hospedado pelo Azure. Esses certificados já são compatíveis com os certificados recém-aplicados e, portanto, nenhuma ação é necessária.

Para um conector usando o Self-hosted Integration Runtime, onde você inclui explicitamente o caminho para o arquivo de certificado SSL em sua cadeia de conexão, você precisará baixar o novo certificado e atualizar a cadeia de conexão para usá-lo.

Preciso planejar um tempo de inatividade de manutenção do servidor de banco de dados para essa alteração?

Não Como a alteração está apenas no lado do cliente para se conectar ao servidor de banco de dados, não há tempo de inatividade de manutenção necessário para o servidor de banco de dados para essa alteração.

Com que frequência a Microsoft atualiza seus certificados ou qual é a política de expiração?

Esses certificados usados pelo Banco de Dados do Azure para MySQL são fornecidos por Autoridades de Certificação (CA) confiáveis. Portanto, o suporte desses certificados está vinculado ao suporte desses certificados pela CA. O certificado BaltimoreCyberTrustRoot está programado para expirar em 2025, portanto, a Microsoft precisará executar uma alteração de certificado antes do vencimento. Além disso, caso haja bugs imprevistos nesses certificados predefinidos, a Microsoft precisará fazer a rotação de certificados o mais cedo possível semelhante à alteração realizada em 15 de fevereiro de 2021 para garantir que o serviço seja seguro e compatível em todos os momentos.

Se eu estiver usando réplicas de leitura, preciso executar essa atualização somente no servidor de origem ou nas réplicas de leitura?

Como essa atualização é uma alteração do lado do cliente, se o cliente costumava ler dados do servidor de réplica, você precisará aplicar as alterações para esses clientes também.

Se eu estiver usando a replicação de dados, preciso executar alguma ação?

Se você estiver usando a replicação de dados para se conectar ao Banco de Dados do Azure para MySQL, há duas coisas a considerar:

• Se a replicação de dados for de uma máquina virtual (local ou máquina virtual do Azure) para o Banco de Dados do Azure para MySQL, você precisará verificar se o SSL está sendo usado para criar a réplica. Execute SHOW SLAVE STATUS e verifique a seguinte configuração.

  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
  

  Se você vir que o certificado é fornecido para o CA_file, SSL_Cert e SSL_Key, precisará atualizar o arquivo adicionando o novo certificado e criar um arquivo de certificado combinado.

• Se a replicação de dados estiver entre dois servidores do Banco de Dados do Azure para MySQL, você precisará redefinir a réplica executando CALL mysql.az_replication_change_master e fornecer o novo certificado de raiz dupla como o último parâmetro master_ssl_ca.

Existe uma consulta do lado do servidor para determinar se o SSL está sendo usado?

Para verificar se você está usando a conexão SSL para se conectar ao servidor, consulte Verificação SSL.

Existe uma ação necessária se eu já tiver o DigiCertGlobalRootG2 no meu arquivo de certificado?

Não Não há nenhuma ação necessária se o seu arquivo de certificado já tiver o DigiCertGlobalRootG2.

Por que eu preciso atualizar meu certificado raiz se estou usando o driver PHP com enableRedirect ?

Para atender aos requisitos de conformidade, os certificados de CA do servidor host foram alterados de BaltimoreCyberTrustRoot para DigiCertGlobalRootG2. Com essa atualização, as conexões de banco de dados usando o driver do cliente PHP com enableRedirect não podem mais se conectar ao servidor, pois os dispositivos cliente não estão cientes da alteração do certificado e dos novos detalhes da autoridade de certificação raiz. Os dispositivos cliente que usam drivers de redirecionamento PHP se conectam diretamente ao servidor host, ignorando o gateway. Consulte este link para obter mais informações sobre a arquitetura do Banco de Dados do Azure para o servidor único MySQL.

E se eu tiver mais perguntas?

Para perguntas, obtenha respostas de especialistas da comunidade em Microsoft Q&&A. Se você tem um plano de suporte e precisa de ajuda técnica, entre em contato conosco.