Informazioni sulle modifiche apportate alla CA radice per Database di Azure per MySQL server singolo

SI APPLICA A: Database di Azure per MySQL - Server singolo

Importante

Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?

Database di Azure per MySQL server singolo come parte delle procedure consigliate per la manutenzione standard e la sicurezza completeranno la modifica del certificato radice a partire da ottobre 2022. Questo articolo offre altri dettagli sulle modifiche, sulle risorse interessate e sui passaggi necessari per garantire che l'applicazione mantenga la connettività al server di database.

Nota

Questo articolo si applica a Database di Azure per MySQL - SOLO server singolo. Per Database di Azure per MySQL - Server flessibile, il certificato necessario per comunicare tramite SSL è DigiCert Global Root CA

Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.

Perché è necessario un aggiornamento del certificato radice?

Database di Azure per MySQL gli utenti possono usare solo il certificato predefinito per connettersi al server MySQL, disponibile qui. Tuttavia, il forum del browser autorità di certificazione (CA) ha recentemente pubblicato report di più certificati rilasciati dai fornitori della CA per essere non conformi.

In base ai requisiti di conformità del settore, i fornitori di ca hanno iniziato a revocare i certificati CA per ca non conformi, richiedendo ai server di usare i certificati rilasciati da ca conformi e firmati da certificati CA da tali ca conformi. Poiché Database di Azure per MySQL usato uno di questi certificati non conformi, è necessario ruotare il certificato alla versione conforme per ridurre al minimo la potenziale minaccia per i server MySQL.

È necessario apportare modifiche al client per mantenere la connettività?

Se sono stati seguiti i passaggi indicati in Creare un certificato CA combinato riportato di seguito, è possibile continuare a connettersi purché il certificato BaltimoreCyberTrustRoot non venga rimosso dal certificato CA combinato . Per mantenere la connettività, è consigliabile conservare il baltimoreCyberTrustRoot nel certificato ca combinato fino a quando non si noterà di più.

Creare un certificato ca combinato

Per evitare interruzioni della disponibilità dell'applicazione a causa di certificati revocati in modo imprevisto o per aggiornare un certificato revocato, seguire questa procedura. L'idea consiste nel creare un nuovo file con estensione pem , che combina il certificato corrente e quello nuovo e durante la convalida del certificato SSL, verrà usato uno dei valori consentiti. Fare riferimento alla procedura seguente:

1. Scaricare BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Root CA dai collegamenti seguenti:

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

2. Vengono inclusi un archivio certificati CA combinato con certificati BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 .

   • Per gli utenti java (MySQL Connessione or/J), eseguire:

     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
     

     Sostituire quindi il file dell'archivio chiavi originale con quello nuovo generato:

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

   • Per gli utenti di .NET (MySQL Connessione or/NET, MySQL Connessione or), assicurarsi che BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 esistano entrambi nell'archivio certificati di Windows, nelle autorità di certificazione radice attendibili. Se non esistono certificati, importare il certificato mancante.

     

   • Per gli utenti .NET in Linux che usano SSL_CERT_DIR, assicurarsi che BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 esistano entrambi nella directory indicata da SSL_CERT_DIR. Se non esistono certificati, creare il file di certificato mancante.

   • Per altri utenti (MySQL Client/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift), è possibile unire due file di certificato CA nel formato seguente:

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

3. Sostituire il file pem ca radice originale con il file CA radice combinato e riavviare l'applicazione/client.

   In futuro, dopo la distribuzione del nuovo certificato sul lato server, è possibile modificare il file PEM della CA in DigiCertGlobalRootG2.crt.pem.

Nota

Non rilasciare o modificare il certificato Baltimore fino a quando non viene apportata la modifica del certificato. Si invierà una comunicazione dopo il completamento della modifica e quindi sarà possibile rilasciare il certificato Baltimore.

Cosa accade se è stato rimosso il certificato BaltimoreCyberTrustRoot?

Si inizierà a riscontrare errori di connettività durante la connessione al server Database di Azure per MySQL. È necessario configurare di nuovo SSL con il certificato BaltimoreCyberTrustRoot per mantenere la connettività.

Domande frequenti

Se non si usa SSL/TLS, è comunque necessario aggiornare la CA radice?

Non sono necessarie azioni se non si usa SSL/TLS.

Quando l'istanza del server singolo subirà modifiche al certificato radice?

La migrazione da BaltimoreCyberTrustRoot a DigiCertGlobalRootG2 verrà eseguita in tutte le aree di Azure a partire da ottobre 2022 in fasi. Per assicurarsi di non perdere la connettività al server, seguire i passaggi indicati in Creare un certificato CA combinato. Il certificato CA combinato consentirà la connettività tramite SSL all'istanza del server singolo con uno di questi due certificati.

Quando è possibile rimuovere completamente il certificato BaltimoreCyberTrustRoot?

Una volta completata la migrazione in tutte le aree di Azure, verrà inviato un post di comunicazione che è possibile modificare un singolo certificato DIGICertGlobalRootG2 della CA.

Non si specifica alcun certificato ca durante la connessione all'istanza del server singolo tramite SSL, è comunque necessario eseguire i passaggi indicati in precedenza?

Se entrambi i certificati radice della CA sono presenti nell'archivio radice attendibile, non sono necessarie altre azioni. Questo vale anche per i driver client che usano l'archivio locale per l'accesso al certificato CA radice.

Se si usa SSL/TLS, è necessario riavviare il server di database per aggiornare la CA radice?

No, non è necessario riavviare il server di database per iniziare a usare il nuovo certificato. Questo certificato radice è una modifica lato client e le connessioni client in ingresso devono usare il nuovo certificato per assicurarsi che possano connettersi al server di database.

Ricerca per categorie sapere se si usa SSL/TLS con la verifica del certificato radice?

È possibile identificare se le connessioni verificano il certificato radice esaminando il stringa di connessione.

• Se il stringa di connessione include sslmode=verify-ca o sslmode=verify-identity, è necessario aggiornare il certificato.
• Se il stringa di connessione include sslmode=disable, sslmode=allowsslmode=prefer, o sslmode=require, non è necessario aggiornare i certificati.
• Se il stringa di connessione non specifica sslmode, non è necessario aggiornare i certificati.

Se si usa un client che astrae il stringa di connessione, esaminare la documentazione del client per capire se verifica i certificati.

Qual è l'impatto dell'uso di servizio app con Database di Azure per MySQL?

Per i servizi app di Azure che si connettono a Database di Azure per MySQL, esistono due possibili scenari a seconda di come si usa SSL con l'applicazione.

• Questo nuovo certificato è stato aggiunto a servizio app a livello di piattaforma. Se si usano i certificati SSL inclusi nella piattaforma servizio app nell'applicazione, non è necessaria alcuna azione. Questo è lo scenario più comune.
• Se si include in modo esplicito il percorso del file di certificato SSL nel codice, è necessario scaricare il nuovo certificato e produrre un certificato combinato come indicato in precedenza e usare il file del certificato. Un buon esempio di questo scenario è quando si usano contenitori personalizzati in servizio app condivisi nella documentazione di servizio app. Si tratta di uno scenario non comune, ma alcuni utenti lo usano.

Qual è l'impatto dell'uso di servizio Azure Kubernetes (AKS) con Database di Azure per MySQL?

Se si sta provando a connettersi al Database di Azure per MySQL usando servizio Azure Kubernetes il servizio Azure Kubernetes, è simile all'accesso da un ambiente host clienti dedicato. Fare riferimento ai passaggi qui.

Qual è l'impatto dell'uso di Azure Data Factory per connettersi a Database di Azure per MySQL?

Per un connettore che usa Azure Integration Runtime, il connettore usa i certificati nell'archivio certificati di Windows nell'ambiente ospitato in Azure. Questi certificati sono già compatibili con i certificati appena applicati e pertanto non è necessaria alcuna azione.

Per un connettore che usa il runtime di integrazione self-hosted in cui si include in modo esplicito il percorso del file di certificato SSL nel stringa di connessione, è necessario scaricare il nuovo certificato e aggiornare il stringa di connessione per usarlo.

È necessario pianificare un tempo di inattività di manutenzione del server di database per questa modifica?

No. Poiché la modifica si trova solo sul lato client per connettersi al server di database, non sono necessari tempi di inattività di manutenzione per il server di database per questa modifica.

Con quale frequenza Microsoft aggiorna i certificati o qual è il criterio di scadenza?

Questi certificati usati da Database di Azure per MySQL vengono forniti da autorità di certificazione (CA) attendibili. Il supporto di questi certificati è quindi associato al supporto di questi certificati da parte della CA. Il certificato BaltimoreCyberTrustRoot è pianificato per scadere nel 2025, quindi Microsoft dovrà eseguire una modifica del certificato prima della scadenza. Inoltre, se sono presenti bug imprevisti in questi certificati predefiniti, Microsoft dovrà effettuare la rotazione dei certificati al più presto simile alla modifica eseguita il 15 febbraio 2021 per garantire che il servizio sia sempre sicuro e conforme.

Se si usano repliche in lettura, è necessario eseguire questo aggiornamento solo nel server di origine o nelle repliche in lettura?

Poiché questo aggiornamento è una modifica lato client, se il client usato per leggere i dati dal server di replica, sarà necessario applicare anche le modifiche per tali client.

Se si usa la replica dei dati in ingresso, è necessario eseguire un'azione?

Se si usa la replica dei dati in ingresso per connettersi a Database di Azure per MySQL, è necessario considerare due aspetti:

• Se la replica dei dati proviene da una macchina virtuale (locale o macchina virtuale di Azure) a Database di Azure per MySQL, è necessario verificare se viene usato SSL per creare la replica. Eseguire SHOW SLAVE STATUS (MOSTRA STATO SLAVE) e controllare l'impostazione seguente.

  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 viene visualizzato che il certificato viene fornito per il CA_file, SSL_Cert e SSL_Key, è necessario aggiornare il file aggiungendo il nuovo certificato e creare un file di certificato combinato.

• Se la replica dei dati è compresa tra due server Database di Azure per MySQL, sarà necessario reimpostare la replica eseguendo CALL mysql.az_replication_change_master e specificare il nuovo certificato radice duale come ultimo parametro master_ssl_ca.

Esiste una query sul lato server per determinare se è in uso SSL?

Per verificare se si usa la connessione SSL per connettersi al server, fare riferimento alla verifica SSL.

È necessaria un'azione se nel file del certificato è già presente DigiCertGlobalRootG2?

No. Non è necessaria alcuna azione se il file del certificato include già DigiCertGlobalRootG2.

Perché è necessario aggiornare il certificato radice se si usa il driver PHP con enableRedirect ?

Per soddisfare i requisiti di conformità, i certificati CA del server host sono stati modificati da BaltimoreCyberTrustRoot a DigiCertGlobalRootG2. Con questo aggiornamento, le connessioni di database che usano il driver client PHP con enableRedirect non possono più connettersi al server, perché i dispositivi client non sono a conoscenza della modifica del certificato e dei nuovi dettagli della CA radice. I dispositivi client che usano driver di reindirizzamento PHP si connettono direttamente al server host, ignorando il gateway. Per altre informazioni sull'architettura di Database di Azure per MySQL server singolo, vedere questo collegamento.

Cosa succede se ho altre domande?

Per domande, ottenere risposte dagli esperti della community in Microsoft Q&A. Se hai un piano di supporto e hai bisogno di assistenza tecnica, contattaci.