Noções básicas sobre as alterações na alteração da AC raiz para o servidor único do Banco de Dados do Azure para MySQL

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

Importante

O Banco de Dados do Azure para servidor único 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 servidor único do Banco de Dados do Azure para MySQL, como parte das melhores práticas 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 o aplicativo mantenha a conectividade com o servidor do banco de dados.

Observação

Este artigo se aplica SOMENTE ao Banco de Dados do Azure para MySQL – Servidor Único. Para o Banco de Dados do Azure para MySQL – Servidor Flexível, o certificado necessário para se comunicar por SSL é a AC raiz global DigiCert

Este artigo contém referências ao termo servidor subordinado, um termo que a Microsoft não usa mais. Quando o termo for removido do software, também o removeremos deste artigo.

Por que a atualização do certificado raiz é necessária?

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 Certificate Authority (CA) Browser publicou recentemente relatórios de vários certificados emitidos por fornecedores de autoridade de certificação como sem conformidade.

De acordo com os requisitos de conformidade do setor, os fornecedores de AC começaram a revogar certificados de AC para ACs sem conformidade, exigindo que os servidores usem certificados emitidos por ACs em conformidade e assinados por certificados de AC dessas ACs em conformidade. Como o Banco de Dados do Azure para MySQL usava um desses certificados não compatíveis, precisávamos alternar o certificado para a versão em conformidade para minimizar a possível ameaça aos servidores MySQL.

É preciso fazer alterações no cliente para manter a conectividade?

Se você seguiu as etapas mencionadas em Criar um certificado de AC combinado abaixo, ainda poderá se conectar, desde que o certificado BaltimoreCyberTrustRoot não seja removido do certificado de Autoridade de Certificação combinado. Para manter a conectividade, é recomendável não remover o BaltimoreCyberTrustRoot do certificado de Autoridade de Certificação combinada, até indicação em contrário.

Criar um certificado de AC combinado

Para evitar que a disponibilidade do aplicativo seja interrompida como resultado da revogação inesperada dos certificados ou para atualizar um certificado que foi revogado, siga as próximas etapas. A ideia é criar um 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. Baixe o AC raiz BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 pelos seguintes links:

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

2. Gere um repositório de certificados de AC combinada com os certificados BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 incluídos.

   • Para usuários do 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
     

     Depois, substitua o arquivo de repositório de chaves original pelo novo gerado:

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

   • Para usuários do .NET (MySQL Connector/NET, MySQLConnector), verifique se BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 existem no repositório de certificados do Windows e nas Autoridades de Certificação Raiz Confiáveis. Se algum certificado não existir, importe o certificado ausente.

     

   • Para usuários do .NET no Linux usando SSL_CERT_DIR, verifique se BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 existem no diretório indicado por SSL_CERT_DIR. Se algum certificado não existir, crie o arquivo do 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 AC 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 AC raiz original pelo arquivo de AC raiz combinada e reinicie o aplicativo/cliente.

   Futuramente, após o novo certificado ser implantado no lado do servidor, você poderá alterar o arquivo pem da AC para DigiCertGlobalRootG2.crt.pem.

Observação

Não remova nem altere o certificado Baltimore até que a alteração de certificado seja feita. Enviaremos uma comunicação depois que a alteração for feita e, em seguida, será seguro remover o certificado Baltimore.

O que acontece se removermos o certificado BaltimoreCyberTrustRoot?

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

Perguntas frequentes

Se eu não estou usando SSL/TLS, preciso atualizar a AC raiz mesmo assim?

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

Quando minha instância de servidor único será submetida a uma 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 AC combinado. O certificado de AC combinado permitirá a conectividade via SSL para a instância de servidor único com um desses dois certificados.

Quando posso remover o certificado BaltimoreCyberTrustRoot completamente?

Depois que 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 digiCertGlobalRootG2 da AC.

Não especifiquei um certificado de AC durante a conexão com minha instância de servidor único por SSL, ainda preciso executar as etapas mencionadas acima?

Se você tiver o certificado raiz da AC no repositório raiz confiável, nenhuma outra ação será necessária. Isso também se aplica aos drivers cliente que usam o repositório local para acessar o certificado de autoridade de certificação raiz.

Se eu estou usando SSL/TLS, preciso reiniciar meu servidor de banco de dados para atualizar a AC raiz?

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

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

Você pode identificar se suas conexões verificam o certificado raiz ao revisar a 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, sslmode=allow, sslmode=prefer ou sslmode=require, você não precisará atualizar os certificados.
• Se a cadeia de conexão não especificar sslmode, você não precisará atualizar os certificados.

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

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

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

• Este novo certificado foi adicionado ao Serviço de Aplicativo no nível da plataforma. Se estiver usando os certificados SSL incluídos na plataforma do Serviço de Aplicativo no aplicativo, nenhuma ação será necessária. Esse é o cenário mais comum.
• Se estiver incluindo explicitamente o caminho para o arquivo de certificado SSL no código, você precisará baixar o novo certificado e produzir um certificado combinado, como 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. Esse não é um cenário comum, mas já vimos isso com alguns usuários.

Qual o impacto do uso do AKS (Serviço de Kubernetes do Azure) com o Banco de Dados do Azure para MySQL?

Se estiver tentando se conectar ao Banco de Dados do Azure para MySQL usando os AKS (Serviço de Kubernetes do Azure), o acesso será feito de forma semelhante a partir de um ambiente de host de clientes dedicado. Consulte as etapas aqui.

Qual o impacto do uso do Azure Data Factory para conexão ao Banco de Dados do Azure para MySQL?

Para um conector que usa o Azure Integration Runtime, o conector usa os certificados no Repositório de Certificados do Windows no ambiente hospedado do Azure. Esses certificados já são compatíveis com os certificados aplicados recentemente, então nenhuma ação é necessária.

Para um conector que usa o runtime de integração auto-hospedada em que você inclui explicitamente o caminho para o arquivo de certificado SSL na cadeia de conexão, será preciso 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 é feita apenas no lado do cliente para se conectar ao servidor de banco de dados, não é necessário um tempo de inatividade de manutenção para o servidor de banco de dados para essa alteração.

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

Esses certificados usados pelo Banco de Dados do Azure para MySQL são fornecidos por ACs (autoridades de certificação) confiáveis. Portanto, o suporte desses certificados está vinculado ao suporte desses certificados pela AC. O certificado BaltimoreCyberTrustRoot está agendado para expirar em 2025, portanto, a Microsoft precisará realizar uma alteração de certificado antes da expiração. Em caso de bugs imprevistos nesses certificados predefinidos, a Microsoft precisará fazer a rotação do certificado o mais cedo possível, semelhante à alteração realizada em 15 de fevereiro de 2021, para garantir que o serviço esteja seguro e em conformidade em todos os momentos.

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

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

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

Se estiver usando a replicação de entrada de dados para se conectar ao Banco de Dados do Azure para MySQL, há duas coisas que devem ser consideradas:

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

  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 o certificado for fornecido para CA_file, SSL_Cert e SSL_Key, você 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 raiz duplo como o último parâmetro master_ssl_ca.

Há 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, confira Verificação de SSL.

Precisarei fazer alguma coisa se eu já tiver o DigiCertGlobalRootG2 no meu arquivo de certificado?

Não. Não é preciso fazer nada se o arquivo de certificado já tiver o DigiCertGlobalRootG2.

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

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

E se eu tiver outras dúvidas?

Em caso de dúvidas, fale com os especialistas da comunidade no Microsoft Q&A. Se tiver um plano de suporte e precisar de ajuda técnica, entre em contato conosco.