Az önálló Azure Database for MySQL-kiszolgáló legfelső szintű hitelesítésszolgáltatójának változásainak ismertetése

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Az önálló Azure Database for MySQL-kiszolgáló a standard karbantartási és biztonsági ajánlott eljárások részeként 2022 októberétől elvégzi a főtanúsítvány módosítását. Ez a cikk további részleteket tartalmaz a módosításokról, az érintett erőforrásokról és az alkalmazás adatbázis-kiszolgálóhoz való kapcsolódásának biztosításához szükséges lépésekről.

Megjegyzés:

Ez a cikk csak az Önálló Azure Database for MySQL-hez vonatkozik. Rugalmas Azure Database for MySQL-kiszolgáló esetén az SSL-en keresztüli kommunikációhoz szükséges tanúsítvány a DigiCert Global Root CA

This article contains references to the term slave, a term that Microsoft no longer uses. Ha a kifejezés el lesz távolítva a szoftverből, eltávolítjuk ebből a cikkből.

Miért van szükség főtanúsítvány-frissítésre?

Az Azure Database for MySQL-felhasználók csak az előre definiált tanúsítványt használhatják az itt található MySQL-kiszolgálójukhoz való csatlakozáshoz. A hitelesítésszolgáltató (CA) böngészőfóruma azonban nemrég közzétette a hitelesítésszolgáltató által kiadott több tanúsítványról szóló jelentéseket, amelyek nem megfelelőek.

Az iparág megfelelőségi követelményei szerint a ca-szállítók megkezdték a hitelesítésszolgáltatói tanúsítványok visszavonását a nem megfelelő hitelesítésszolgáltatók számára, megkövetelve, hogy a kiszolgálók a megfelelő hitelesítésszolgáltatók által kibocsátott tanúsítványokat használják, és a megfelelő hitelesítésszolgáltatóktól származó hitelesítésszolgáltatói tanúsítványok által aláírt tanúsítványokat használják. Mivel az Azure Database for MySQL ezen nem megfelelő tanúsítványok egyikét használta, a tanúsítványt a megfelelő verzióra kellett forgatni, hogy minimálisra csökkentsük a MySQL-kiszolgálókat fenyegető potenciális fenyegetést.

Módosítani kell az ügyfelemet a kapcsolat fenntartása érdekében?

Ha követte az alábbi Kombinált hitelesítésszolgáltatói tanúsítvány létrehozása című szakasz lépéseit, folytathatja a csatlakozást mindaddig, amíg a BaltimoreCyberTrustRoot tanúsítvány nincs eltávolítva az egyesített hitelesítésszolgáltatói tanúsítványból. A kapcsolat fenntartása érdekében javasoljuk, hogy további értesítésig őrizze meg a BaltimoreCyberTrustRoot tanúsítványt a kombinált hitelesítésszolgáltatói tanúsítványban.

Kombinált hitelesítésszolgáltatói tanúsítvány létrehozása

Ha szeretné elkerülni, hogy az alkalmazás rendelkezésre állása váratlanul visszavont tanúsítványok miatt megszakadjon, vagy egy visszavont tanúsítványt frissítsen, kövesse az alábbi lépéseket. Az ötlet egy új .pem fájl létrehozása, amely egyesíti az aktuális tanúsítványt és az újat, és az SSL-tanúsítvány érvényesítése során a rendszer az egyik engedélyezett értéket fogja használni. Tekintse meg a következő lépéseket:

1. Töltse le a BaltimoreCyberTrustRoot > DigiCertGlobalRootG2 gyökér ca-t az alábbi hivatkozásokról:

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

2. A BaltimoreCyberTrustRoot és a DigiCertGlobalRootG2 tanúsítványokkal együtt létrehoz egy összevont hitelesítésszolgáltatói tanúsítványtárolót.

   • Java (MySQL Csatlakozás or/J) felhasználók esetén hajtsa végre a következőt:

     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
     

     Ezután cserélje le az eredeti kulcstárfájlt az új létrehozott fájlra:

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

   • A .NET -felhasználók (MySQL Csatlakozás or/NET, MySQL Csatlakozás or) esetében győződjön meg arról, hogy a BaltimoreCyberTrustRoot és a DigiCertGlobalRootG2 is létezik a Windows Tanúsítványtárolóban, megbízható legfelső szintű hitelesítésszolgáltatóknál. Ha nem léteznek tanúsítványok, importálja a hiányzó tanúsítványt.

     

   • A Linuxon SSL_CERT_DIR használó .NET-felhasználók esetében győződjön meg arról, hogy a BaltimoreCyberTrustRoot és a DigiCertGlobalRootG2 is megtalálható a SSL_CERT_DIR által jelzett könyvtárban. Ha nem léteznek tanúsítványok, hozza létre a hiányzó tanúsítványfájlt.

   • Más (MySQL-ügyfél/MySQL Workbench/C/C+++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift) felhasználók esetében két ca-tanúsítványfájlt egyesíthet a következő formátumban:

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

3. Cserélje le az eredeti legfelső szintű hitelesítésszolgáltatói pem-fájlt az egyesített legfelső szintű hitelesítésszolgáltatói fájlra, és indítsa újra az alkalmazást/ügyfelet.

   A jövőben az új tanúsítvány kiszolgálóoldalon történő üzembe helyezése után a ca pem-fájlt DigiCertGlobalRootG2.crt.pem fájlra módosíthatja.

Megjegyzés:

A tanúsítvány módosításáig ne ejtse le vagy módosítsa a Baltimore-tanúsítványt . A módosítás után küldünk egy közleményt, és biztonságosan elvetjük a Baltimore-tanúsítványt.

Mi történik, ha eltávolítottuk a BaltimoreCyberTrustRoot tanúsítványt?

Csatlakozási hibákba ütközik az Azure Database for MySQL-kiszolgálóhoz való csatlakozás során. A kapcsolat fenntartásához újra konfigurálnia kell az SSL-t a BaltimoreCyberTrustRoot tanúsítvánnyal.

Gyakori kérdések

Ha nem SSL-t/TLS-t használok, frissíteni kell még a legfelső szintű hitelesítésszolgáltatót?

Ssl/TLS használata esetén nincs szükség műveletekre.

Mikor változik az önálló kiszolgálópéldányom főtanúsítványa?

A BaltimoreCyberTrustRoot-ból a DigiCertGlobalRootG2-be való migrálás 2022 októberétől fázisokban történik az Azure minden régiójában. Annak érdekében, hogy ne veszítsen kapcsolatot a kiszolgálóval, kövesse a Kombinált hitelesítésszolgáltatói tanúsítvány létrehozása című témakörben ismertetett lépéseket. A kombinált hitelesítésszolgáltatói tanúsítvány ssl-kapcsolaton keresztül teszi lehetővé az egyetlen kiszolgálópéldányhoz való kapcsolódást e két tanúsítvány bármelyikével.

Mikor távolíthatom el teljesen a BaltimoreCyberTrustRoot tanúsítványt?

Miután a migrálás sikeresen befejeződött az összes Azure-régióban, elküldünk egy kommunikációs bejegyzést, amely szerint biztonságosan módosíthatja az egyetlen CA DigiCertGlobalRootG2 tanúsítványt.

Nem adok meg hitelesítésszolgáltatói tanúsítványt, miközben SSL-en keresztül csatlakozom az önálló kiszolgálópéldányomhoz, még mindig végre kell hajtani a fent említett lépéseket ?

Ha mindkét hitelesítésszolgáltató gyökértanúsítványa a megbízható gyökértárolóban található, akkor nincs szükség további műveletekre. Ez vonatkozik azokra az ügyfélillesztőkre is, amelyek a helyi tárolót használják a legfelső szintű hitelesítésszolgáltatói tanúsítvány eléréséhez.

Ha SSL/TLS protokollt használok, újra kell indítani az adatbázis-kiszolgálót a legfelső szintű hitelesítésszolgáltató frissítéséhez?

Nem, nem kell újraindítania az adatbázis-kiszolgálót az új tanúsítvány használatának megkezdéséhez. Ez a főtanúsítvány ügyféloldali változás, és a bejövő ügyfélkapcsolatoknak az új tanúsítvány használatával kell biztosítaniuk, hogy csatlakozni tudjanak az adatbázis-kiszolgálóhoz.

Hogyan tudom, hogy SSL/TLS-t használok-e főtanúsítvány-ellenőrzéssel?

A kapcsolati sztring áttekintésével megállapíthatja, hogy a kapcsolatok ellenőrzik-e a főtanúsítványt.

• Ha a kapcsolati sztring tartalmazza sslmode=verify-ca vagysslmode=verify-identity, frissítenie kell a tanúsítványt.
• Ha a kapcsolati sztring tartalmazza sslmode=disablea tanúsítványokatsslmode=allow, sslmode=prefersslmode=requireakkor nem kell frissítenie a tanúsítványokat.
• Ha a kapcsolati sztring nem adja meg az sslmode-t, nem kell frissítenie a tanúsítványokat.

Ha olyan ügyfelet használ, amely elvonja a kapcsolati sztring, tekintse át az ügyfél dokumentációját, hogy ellenőrizze-e a tanúsítványokat.

Milyen hatással van az App Service és az Azure Database for MySQL használatára?

Az Azure Database for MySQL-hez csatlakozó Azure App Services esetében két lehetséges forgatókönyv létezik attól függően, hogy hogyan használja az SSL-t az alkalmazással.

• Ez az új tanúsítvány platformszinten lett hozzáadva az App Service-hez. Ha az alkalmazás App Service-platformján található SSL-tanúsítványokat használja, akkor nincs szükség műveletre. Ez a leggyakoribb forgatókönyv.
• Ha explicit módon bele van adva az SSL-tanúsítványfájl elérési útja a kódba, akkor le kell töltenie az új tanúsítványt, és elő kell állítania egy kombinált tanúsítványt a fent említett módon, és használnia kell a tanúsítványfájlt. Erre a forgatókönyvre jó példa, ha egyéni tárolókat használ az App Service-ben az App Service dokumentációjában megosztott módon. Ez egy nem gyakori forgatókönyv, de néhány felhasználó ezt használta.

Milyen hatással van az Azure Kubernetes Services (AKS) és az Azure Database for MySQL használatára?

Ha az Azure Kubernetes Services (AKS) használatával próbál csatlakozni az Azure Database for MySQL-hez, az hasonló a dedikált ügyfelek gazdagépkörnyezetéből való hozzáféréshez. Tekintse meg az itt leírt lépéseket.

Milyen hatással van az Azure Data Factory az Azure Database for MySQL-hez való csatlakozásra?

Az Azure Integration Runtime-ot használó összekötők esetében az összekötő a Windows Tanúsítványtárban található tanúsítványokat használja az Azure által üzemeltetett környezetben. Ezek a tanúsítványok már kompatibilisek az újonnan alkalmazott tanúsítványokkal, ezért nincs szükség műveletre.

A saját üzemeltetésű integrációs modult használó összekötők esetében, ahol explicit módon szerepel az SSL-tanúsítványfájl elérési útja a kapcsolati sztring, le kell töltenie az új tanúsítványt, és frissítenie kell a kapcsolati sztring a használatához.

Terveznem kell az adatbázis-kiszolgáló karbantartási állásidejét ehhez a változáshoz?

Nem. Mivel a módosítás csak az ügyféloldalon csatlakozik az adatbázis-kiszolgálóhoz, a módosításhoz nincs szükség karbantartási állásidőre az adatbázis-kiszolgáló számára.

Milyen gyakran frissíti a Microsoft a tanúsítványokat, vagy mi a lejárati szabályzat?

Az Azure Database for MySQL által használt tanúsítványokat megbízható hitelesítésszolgáltatók (CA) biztosítják. Ezért ezeknek a tanúsítványoknak a támogatása a hitelesítésszolgáltató által támogatott tanúsítványokhoz van kötve. A BaltimoreCyberTrustRoot tanúsítvány 2025-ben lejár, ezért a Microsoftnak a lejárat előtt tanúsítványmódosítást kell végrehajtania. Abban az esetben is, ha az előre definiált tanúsítványokban előre nem látható hibák lépnek fel, a Microsoftnak a tanúsítványváltást a 2021. február 15-én végrehajtott módosításhoz hasonlóan kell elvégeznie, hogy a szolgáltatás mindig biztonságos és megfelelő legyen.

Ha olvasási replikákat használok, ezt a frissítést csak a forráskiszolgálón vagy az olvasási replikákon kell elvégezni?

Mivel ez a frissítés egy ügyféloldali változás, ha az ügyfél adatokat olvas be a replikakiszolgálóról, akkor a módosításokat is alkalmaznia kell ezekre az ügyfelekre.

Ha data-in replikációt használok, végre kell hajtania valamilyen műveletet?

Ha data-in replikációt használ az Azure Database for MySQL-hez való csatlakozáshoz, két szempontot kell figyelembe vennie:

• Ha az adatreplikálás egy virtuális gépről (helyszíni vagy Azure-beli virtuális gépről) az Azure Database for MySQL-be történik, ellenőriznie kell, hogy SSL-t használ-e a replika létrehozásához. Futtassa a SLAVE ÁLLAPOT megjelenítése parancsot, és ellenőrizze a következő beállítást.

  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
  

  Ha azt látja, hogy a tanúsítvány a CA_file, SSL_Cert és SSL_Key van megadva, frissítenie kell a fájlt az új tanúsítvány hozzáadásával, és létre kell hoznia egy egyesített tanúsítványfájlt.

• Ha az adatreplikálás két Azure Database for MySQL-kiszolgáló között van, akkor a CALL mysql.az_replication_change_master végrehajtásával alaphelyzetbe kell állítania a replikát, és meg kell adnia az új kettős főtanúsítványt az utolsó paraméterként master_ssl_ca.

Van kiszolgálóoldali lekérdezés annak megállapításához, hogy ssl van-e használatban?

Annak ellenőrzéséhez, hogy SSL-kapcsolatot használ-e a kiszolgálóhoz való csatlakozáshoz, tekintse meg az SSL-ellenőrzést.

Szükség van műveletet, ha már szerepel a DigiCertGlobalRootG2 a tanúsítványfájlban?

Nem. Nincs szükség műveletre, ha a tanúsítványfájlban már szerepel a DigiCertGlobalRootG2.

Miért kell frissíteni a főtanúsítványomat, ha PHP-illesztőt használok az enableRedirect használatával?

A megfelelőségi követelmények teljesítése érdekében a gazdagépkiszolgáló hitelesítésszolgáltatói tanúsítványai BaltimoreCyberTrustRootról DigiCertGlobalRootG2-re módosultak. Ezzel a frissítéssel az enableRedirect php-ügyfélillesztőt használó adatbázis-kapcsolatok már nem tudnak csatlakozni a kiszolgálóhoz, mivel az ügyféleszközök nem tudnak a tanúsítványváltozásról és az új legfelső szintű hitelesítésszolgáltató adatairól. A PHP-átirányítási illesztőprogramokat használó ügyféleszközök közvetlenül a gazdakiszolgálóhoz csatlakoznak, megkerülve az átjárót. Ezen a hivatkozáson további információt az önálló Azure Database for MySQL-kiszolgáló architektúrájáról olvashat.

Mi a teendő, ha további kérdéseim vannak?

Kérdéseire választ kaphat a Microsoft Q&A közösségi szakértőitől. Ha rendelkezik támogatási tervvel, és technikai segítségre van szüksége, forduljon hozzánk.