Vysvětlení změn v změně kořenové certifikační autority pro jednoúčelový server Azure Database for MySQL
PLATÍ PRO: Jednoúčelový server Azure Database for MySQL
Důležité
Jednoúčelový server Azure Database for MySQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for MySQL. Další informace o migraci na flexibilní server Azure Database for MySQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for MySQL?
Jednoúčelový server Azure Database for MySQL v rámci standardní údržby a osvědčených postupů zabezpečení dokončí změnu kořenového certifikátu od října 2022. Tento článek obsahuje další podrobnosti o změnách, ovlivněných prostředcích a krocích potřebných k zajištění toho, aby vaše aplikace udržovala připojení k databázovému serveru.
Poznámka:
Tento článek se týká pouze jednoúčelového serveru Azure Database for MySQL. Pro flexibilní server Azure Database for MySQL je certifikát potřebný ke komunikaci přes PROTOKOL SSL– globální kořenová certifikační autorita DigiCert.
Tento článek obsahuje odkazy na termín slave (podřízený) , což je termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.
Proč se vyžaduje aktualizace kořenového certifikátu?
Uživatelé Služby Azure Database for MySQL můžou k připojení k serveru MySQL, který se nachází , použít jenom předdefinovaný certifikát. Fórum prohlížeče certifikační autority (CA) však nedávno publikovalo zprávy o více certifikátech vydaných dodavateli certifikační autority, které nedodržují předpisy.
V souladu s požadavky na dodržování předpisů začali dodavatelé certifikační autority odvolat certifikáty certifikační autority, které nedodržují předpisy, což vyžaduje, aby servery používaly certifikáty vydané certifikačními autoritami a podepsané certifikáty certifikační autority od certifikačních autorit vyhovujících certifikačním autoritám. Vzhledem k tomu, že Služba Azure Database for MySQL používala jeden z těchto nekompatibilních certifikátů, museli jsme certifikát otočit na vyhovující verzi, abychom minimalizovali potenciální hrozbu pro vaše servery MySQL.
Musím v klientovi udělat nějaké změny, aby se zachovalo připojení?
Pokud jste postupovali podle kroků uvedených v části Vytvoření kombinovaného certifikátu certifikační autority níže, můžete se i nadále připojovat, dokud se certifikát BaltimoreCyberTrustRoot neodebere z kombinovaného certifikátu certifikační autority. Pokud chcete zachovat připojení, doporučujeme zachovat BaltimoreCyberTrustRoot v kombinovaném certifikátu certifikační autority až do dalšího oznámení.
Vytvoření kombinovaného certifikátu certifikační autority
Pokud chcete zabránit přerušení dostupnosti vaší aplikace v důsledku neočekávaného odvolání certifikátů nebo aktualizace certifikátu, který byl odvolán, postupujte následovně. Cílem je vytvořit nový soubor .pem , který kombinuje aktuální certifikát a nový a během ověřování certifikátu SSL se použije jedna z povolených hodnot. Projděte si následující kroky:
Stáhněte si Kořenový ca BaltimoreCyberTrustRoot &DigiCertGlobalRootG2 z následujících odkazů:
Vygenerujte kombinované úložiště certifikátů certifikační autority s certifikáty BaltimoreCyberTrustRoot i DigiCertGlobalRootG2.
Pro uživatele Javy (konektor MySQL/J) spusťte:
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
Potom nahraďte původní soubor úložiště klíčů novým vygenerovaným souborem:
- System.setProperty("javax.net.ssl.trustStore";"path_to_truststore_file");
- System.setProperty("javax.net.ssl.trustStorePassword","password");
Pro uživatele rozhraní .NET (Konektor MySQL/ NET, MySQLConnector) se ujistěte, že v úložišti certifikátů Windows existují obě důvěryhodné kořenové certifikační autority BaltimoreCyberTrustRoot a DigiCertGlobalRootG2 . Pokud nějaké certifikáty neexistují, naimportujte chybějící certifikát.
Pro uživatele .NET v Linuxu používajících SSL_CERT_DIR se ujistěte, že v adresáři označeném SSL_CERT_DIR existují oba uživatelé .NET a DigiCertGlobalRootG2. Pokud nějaké certifikáty neexistují, vytvořte chybějící soubor certifikátu.
Pro ostatní uživatele aplikace (MySQL Client/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift) můžete sloučit dva soubory certifikátů certifikační autority do následujícího formátu:
-----BEGIN CERTIFICATE----- (Root CA1: BaltimoreCyberTrustRoot.crt.pem) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root CA2: DigiCertGlobalRootG2.crt.pem) -----END CERTIFICATE-----
Nahraďte původní soubor pem kořenové certifikační autority sloučeným kořenovým souborem CA a restartujte aplikaci nebo klienta.
V budoucnu můžete po nasazení nového certifikátu na straně serveru změnit soubor pem certifikační autority na DigiCertGlobalRootG2.crt.pem.
Poznámka:
Certifikát Baltimore nepřesouvejte ani neměňte, dokud nedojde ke změně certifikátu. Po dokončení změny pošleme komunikaci a pak bude bezpečné vyhodit certifikát Baltimore.
Co když jsme odebrali certifikát BaltimoreCyberTrustRoot?
Při připojování k serveru Azure Database for MySQL začnete narazit na chyby připojení. Abyste zachovali připojení, musíte znovu nakonfigurovat ssl s certifikátem BaltimoreCyberTrustRoot .
Nejčastější dotazy
Pokud nepoužívám PROTOKOL SSL/TLS, musím pořád aktualizovat kořenovou certifikační autoritu?
Pokud nepoužíváte PROTOKOL SSL/TLS, nevyžadují se žádné akce.
Kdy dojde ke změně kořenového certifikátu instance jednoho serveru?
Migrace z BaltimoreCyberTrustRoot na DigiCertGlobalRootG2 se provede ve všech oblastech Azure od října 2022 ve fázích. Pokud chcete mít jistotu, že nepřijdete o připojení k serveru, postupujte podle kroků uvedených v části Vytvoření kombinovaného certifikátu certifikační autority. Kombinovaný certifikát certifikační autority umožní připojení přes PROTOKOL SSL k instanci jednoho serveru s některým z těchto dvou certifikátů.
Kdy můžu úplně odebrat certifikát BaltimoreCyberTrustRoot?
Po úspěšném dokončení migrace napříč všemi oblastmi Azure pošleme příspěvek o komunikaci, který můžete bezpečně změnit jeden certifikát CA DigiCertGlobalRootG2 .
Při připojování k instanci jednoho serveru přes SSL nezadám žádný certifikát certifikační autority, musím přesto provést výše uvedené kroky ?
Pokud máte kořenový certifikát certifikační autority v důvěryhodném kořenovém úložišti, nemusíte provádět žádné další akce. To platí také pro klientské ovladače, které používají místní úložiště pro přístup k kořenovému certifikátu certifikační autority.
Pokud používám protokol SSL/TLS, musím restartovat databázový server, aby se aktualizovala kořenová certifikační autorita?
Ne, abyste mohli začít používat nový certifikát, nemusíte restartovat databázový server. Tento kořenový certifikát je změna na straně klienta a příchozí klientská připojení musí používat nový certifikát, aby se zajistilo, že se můžou připojit k databázovému serveru.
Návody vědět, jestli používám SSL/TLS s ověřením kořenového certifikátu?
Pokud chcete zjistit, jestli připojení ověřují kořenový certifikát, zkontrolujte připojovací řetězec.
- Pokud váš připojovací řetězec obsahuje
sslmode=verify-ca
nebosslmode=verify-identity
, musíte certifikát aktualizovat. - Pokud vaše připojovací řetězec zahrnuje
sslmode=disable
,sslmode=allow
,sslmode=prefer
nebosslmode=require
, nemusíte aktualizovat certifikáty. - Pokud váš připojovací řetězec neurčuje sslmode, nemusíte aktualizovat certifikáty.
Pokud používáte klienta, který abstrahuje připojovací řetězec pryč, projděte si dokumentaci klienta a zjistěte, jestli ověřuje certifikáty.
Jaký je dopad používání služby App Service se službou Azure Database for MySQL?
Pro aplikační služby Azure, které se připojují ke službě Azure Database for MySQL, existují dva možné scénáře v závislosti na tom, jak s aplikací používáte SSL.
- Tento nový certifikát byl přidán do služby App Service na úrovni platformy. Pokud ve vaší aplikaci používáte certifikáty SSL zahrnuté na platformě služby App Service, není potřeba žádná akce. To je nejčastější scénář.
- Pokud do kódu explicitně zahrnete cestu k souboru certifikátu SSL, budete muset stáhnout nový certifikát a vytvořit kombinovaný certifikát, jak je uvedeno výše, a použít soubor certifikátu. Dobrým příkladem tohoto scénáře je použití vlastních kontejnerů ve službě App Service jako sdílené v dokumentaci ke službě App Service. Jedná se o neobvyklý scénář, ale někteří uživatelé to používají.
Jaký je dopad používání služeb Azure Kubernetes Services (AKS) se službou Azure Database for MySQL?
Pokud se pokoušíte připojit ke službě Azure Database for MySQL pomocí služby Azure Kubernetes Services (AKS), je to podobné přístupu z hostitelského prostředí vyhrazených zákazníků. Postup najdete tady.
Jaký je dopad připojení ke službě Azure Database for MySQL pomocí služby Azure Data Factory?
V případě konektoru využívajícího Prostředí Azure Integration Runtime používá konektor certifikáty ve službě Windows Certificate Store v prostředí hostované v Azure. Tyto certifikáty jsou již kompatibilní s nově použitými certifikáty, a proto není nutná žádná akce.
Pro konektor s využitím místního prostředí Integration Runtime, kde explicitně zahrnete cestu k souboru certifikátu SSL ve vašem připojovací řetězec, musíte stáhnout nový certifikát a aktualizovat připojovací řetězec, aby ho používal.
Potřebuji pro tuto změnu naplánovat výpadek údržby databázového serveru?
Ne. Vzhledem k tomu, že změna je pouze na straně klienta pro připojení k databázovému serveru, pro tuto změnu není potřeba žádný výpadek údržby.
Jak často Microsoft aktualizuje své certifikáty nebo jaké jsou zásady vypršení platnosti?
Tyto certifikáty používané službou Azure Database for MySQL poskytují důvěryhodné certifikační autority (CA). Podpora těchto certifikátů je proto svázaná s podporou těchto certifikátů certifikační autoritou. Platnost certifikátu BaltimoreCyberTrustRoot je naplánovaná na vypršení platnosti v roce 2025, takže Microsoft musí provést změnu certifikátu před vypršením platnosti. V případě, že v těchto předdefinovaných certifikátech existují nepředvídatelné chyby, společnost Microsoft bude muset provést obměnu certifikátů co nejdříve podobně jako při změně provedené 15. února 2021, aby se zajistilo, že služba bude vždy zabezpečená a vyhovující.
Pokud používám repliky pro čtení, musím tuto aktualizaci provést jenom na zdrojovém serveru nebo replikách pro čtení?
Vzhledem k tomu, že tato aktualizace je změna na straně klienta, pokud klient používá ke čtení dat ze serveru repliky, musíte změny použít i pro tyto klienty.
Pokud používám replikaci data, musím provést nějakou akci?
Pokud k připojení ke službě Azure Database for MySQL používáte replikaci dat, je potřeba vzít v úvahu dvě věci:
Pokud replikace dat pochází z virtuálního počítače (místního nebo virtuálního počítače Azure) do služby Azure Database for MySQL, musíte zkontrolovat, jestli se k vytvoření repliky používá SSL. Spusťte PŘÍKAZ SHOW SLAVE STATUS a zkontrolujte následující nastavení.
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
Pokud zjistíte, že certifikát je k dispozici pro CA_file, SSL_Cert a SSL_Key, musíte soubor aktualizovat přidáním nového certifikátu a vytvořením kombinovaného souboru certifikátu.
Pokud je replikace dat mezi dvěma servery Azure Database for MySQL, musíte repliku resetovat spuštěním mysql.az_replication_change_master CALL a poskytnout nový duální kořenový certifikát jako poslední parametr master_ssl_ca.
Existuje dotaz na straně serveru, který určuje, jestli se používá SSL?
Pokud chcete ověřit, jestli pro připojení k serveru používáte připojení SSL, projděte si ověření SSL.
Je potřeba provést nějakou akci, pokud už mám v souboru certifikátu DigiCertGlobalRootG2?
Ne. Pokud už soubor certifikátu obsahuje DigiCertGlobalRootG2, není potřeba nic dělat.
Proč potřebuji aktualizovat kořenový certifikát, pokud používám ovladač PHP s enableRedirect?
Kvůli řešení požadavků na dodržování předpisů se certifikáty certifikační autority hostitelského serveru změnily z BaltimoreCyberTrustRoot na DigiCertGlobalRootG2. Při této aktualizaci se připojení k databázi pomocí ovladače klienta PHP s enableRedirect již nemůžou připojit k serveru, protože klientská zařízení neví o změně certifikátu a podrobnostech o nové kořenové certifikační autoritě. Klientská zařízení, která používají ovladače přesměrování PHP, se připojují přímo k hostitelskému serveru a obejdou bránu. Další informace o architektuře jednoúčelového serveru Azure Database for MySQL najdete na tomto odkazu .
Co když mám další otázky?
Pokud máte dotazy, získejte odpovědi od odborníků z komunity v Microsoft Q&A. Pokud máte plán podpory a potřebujete technickou pomoc, kontaktujte nás.