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

Articolo
06/20/2022

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

Importante

Il server singolo del Database di Azure per MySQL è in fase di ritiro. È consigliabile eseguire l'aggiornamento al server flessibile del Database di Azure per MySQL. Per altre informazioni sulla migrazione a un server flessibile del Database di Azure per MySQL, vedere Che cosa sta succedendo al server singolo del Database di Azure per MySQL?

Database di Azure per MySQL server singolo come parte delle procedure consigliate per la manutenzione e la sicurezza standard completano 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 SOLO a Database di Azure per MySQL - 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?

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

In base ai requisiti di conformità del settore, i fornitori di autorità di certificazione hanno iniziato a revocare i certificati CA per le 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 ulteriore avviso.

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, usare i passaggi seguenti. L’idea consiste nel creare un nuovo file .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:

Scaricare BaltimoreCyberTrustRoot e DigiCertGlobalRootG2 Root CA dai collegamenti seguenti:
- https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem
- https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem
Vengono inclusi un archivio di certificati CA combinato con certificati BaltimoreCyberTrustRoot e DigiCertGlobalRootG2.
- Per gli utenti Java (MySQL Connector/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 (Connettore MySQL/NET, MySQLConnector), 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-----
```
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 dell’autorità di certificazione 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, quindi sarà possibile rilasciare il certificato Baltimore.

Cosa accade se è stato rimosso il certificato BaltimoreCyberTrustRoot?

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

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 subisce 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, viene inviato un post di comunicazione che è possibile modificare un singolo certificato DIGICertGlobalRootG2 della CA.

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

Come è possibile sapere se si usa SSL/TLS con la verifica del certificato radice?

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

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

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

Qual è l'impatto dell'uso del 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 al servizio app a livello di piattaforma. Se si usano i certificati SSL inclusi nella piattaforma del 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 è quello in cui si usano contenitori personalizzati nel servizio app come illustrato nella documentazione del servizio app. Si tratta di uno scenario non comune, ma che alcuni utenti usano.

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

Se si sta provando a connettersi a Database di Azure per MySQL usando i servizi Azure Kubernetes, l'accesso è simile a quello di un ambiente host clienti dedicato. Fare riferimento ai passaggi illustrati 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, 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 fermo per la 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 fermo per la manutenzione del server di database per questa modifica.

Con quale frequenza Microsoft aggiorna i certificati, oppure 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 ha una scadenza pianificata per il 2025, quindi Microsoft dovrà eseguire una modifica del certificato prima della scadenza. Inoltre, nel caso in cui si verifichino 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 anche nelle repliche in lettura?

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

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

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

Se la replica dei dati va da una macchina virtuale (locale o macchina virtuale di Azure) a Database di Azure per MySQL, è necessario verificare se SSL viene usato per creare la replica. Eseguire 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, è 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 del server singolo di Database di Azure per MySQL, vedere questo collegamento.

A chi rivolgersi in caso di altre domande?

In caso di domande, è possibile contattare gli esperti della community di Microsoft Q&A. Se si dispone di un piano di supporto e si ha bisogno di assistenza tecnica, contattare il supporto.

Condividi tramite