Tek MySQL için Azure Veritabanı sunucu için Kök CA değişikliğindeki değişiklikleri anlama
ŞUNLAR IÇIN GEÇERLIDIR:
MySQL için Azure Veritabanı - Tek Sunucu
Önemli
MySQL için Azure Veritabanı tek sunucu kullanımdan kaldırma yolundadır. Esnek MySQL için Azure Veritabanı sunucuya yükseltmenizi kesinlikle öneririz. MySQL için Azure Veritabanı esnek sunucuya geçiş hakkında daha fazla bilgi için bkz. MySQL için Azure Veritabanı Tek Sunucu'ya neler oluyor?
Standart bakım ve güvenlik en iyi yöntemlerinin bir parçası olarak tek sunucu MySQL için Azure Veritabanı Kök sertifika değişikliği Ekim 2022'den itibaren tamamlanacaktır. Bu makalede değişiklikler, etkilenen kaynaklar ve uygulamanızın veritabanı sunucunuzla bağlantıyı sürdürmesini sağlamak için gereken adımlar hakkında daha fazla bilgi verilmektedir.
Dekont
Bu makale MySQL için Azure Veritabanı - YALNIZCA Tek Sunucu için geçerlidir. MySQL için Azure Veritabanı - Esnek Sunucu için SSL üzerinden iletişim kurmak için gereken sertifika DigiCert Genel Kök CA'dır
Bu makalede, Microsoft'un artık kullanmadığı köle terimi geçmektedir. Terim yazılımdan kaldırıldığında, bu makaleden kaldıracağız.
Kök sertifika güncelleştirmesi neden gereklidir?
MySQL için Azure Veritabanı kullanıcılar yalnızca burada bulunan MySQL sunucularına bağlanmak için önceden tanımlanmış sertifikayı kullanabilir. Ancak, Sertifika Yetkilisi (CA) Tarayıcı forumu yakın zamanda CA satıcıları tarafından uyumsuz olarak verilen birden çok sertifikanın raporlarını yayımladı.
Sektörün uyumluluk gereksinimlerine göre, CA satıcıları uyumlu olmayan CA'lar için CA sertifikalarını iptal etmeye başladı, sunucuların uyumlu CA'lar tarafından verilen ve bu uyumlu CA'lardan CA sertifikaları tarafından imzalanan sertifikaları kullanmasını gerektirerek. MySQL için Azure Veritabanı bu uyumlu olmayan sertifikalardan birini kullandığından, MySQL sunucularınız için olası tehdidi en aza indirmek için sertifikayı uyumlu sürüme döndürmemiz gerekiyordu.
Bağlantıyı sürdürmek için istemcimde herhangi bir değişiklik yapmam gerekiyor mu?
Aşağıdaki Birleşik CA sertifikası oluşturma bölümünde belirtilen adımları izlediyseniz BaltimoreCyberTrustRoot sertifikası birleşik CA sertifikasından kaldırılmadığı sürece bağlanmaya devam edebilirsiniz. Bağlantıyı korumak için BaltimoreCyberTrustRoot'u bir sonraki bildirime kadar birleşik CA sertifikanızda tutmanızı öneririz.
Birleşik CA sertifikası oluşturma
Sertifikaların beklenmedik bir şekilde iptal edilerek uygulamanızın kullanılabilirliğini kesintiye uğramasını önlemek veya iptal edilmiş bir sertifikayı güncelleştirmek için aşağıdaki adımları kullanın. Fikir, geçerli sertifikayı ve yeni sertifikayı birleştiren yeni bir .pem dosyası oluşturmaktır ve SSL sertifikası doğrulaması sırasında izin verilen değerlerden biri kullanılacaktır. Aşağıdaki adımlara bakın:
BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 Kök CA'sını aşağıdaki bağlantılardan indirin:
Hem BaltimoreCyberTrustRoot hem de DigiCertGlobalRootG2 sertifikaları dahil olmak üzere birleşik bir CA sertifika deposu oluşturun.
Java (MySQL Bağlan or/J) kullanıcıları için şunu yürütebilirsiniz:
keytool -importcert -alias MySQLServerCACert -file D:\BaltimoreCyberTrustRoot.crt.pem -keystore truststore -storepass password -nopromptkeytool -importcert -alias MySQLServerCACert2 -file D:\DigiCertGlobalRootG2.crt.pem -keystore truststore -storepass password -nopromptArdından özgün keystore dosyasını yeni oluşturulan dosyayla değiştirin:
- System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");
- System.setProperty("javax.net.ssl.trustStorePassword","password");
.NET (MySQL Bağlan or/NET, MySQL Bağlan or) kullanıcıları için BaltimoreCyberTrustRoot ve DigiCertGlobalRootG2'nin Windows Sertifika Deposu, Güvenilen Kök Sertifika Yetkilileri'nde mevcut olduğundan emin olun. Herhangi bir sertifika yoksa, eksik sertifikayı içeri aktarın.
SSL_CERT_DIR kullanan Linux üzerindeki .NET kullanıcıları için BaltimoreCyberTrustRoot ve DigiCertGlobalRootG2'nin her ikisinin de SSL_CERT_DIR tarafından belirtilen dizinde bulunduğundan emin olun. Herhangi bir sertifika yoksa, eksik sertifika dosyasını oluşturun.
Diğer (MySQL İstemcisi/MySQL Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift) kullanıcıları için iki CA sertifika dosyasını aşağıdaki biçimde birleştirebilirsiniz:
-----BEGIN CERTIFICATE----- (Root CA1: BaltimoreCyberTrustRoot.crt.pem) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root CA2: DigiCertGlobalRootG2.crt.pem) -----END CERTIFICATE-----
Özgün kök CA pem dosyasını birleştirilmiş kök CA dosyasıyla değiştirin ve uygulamanızı/istemcinizi yeniden başlatın.
Gelecekte, yeni sertifika sunucu tarafında dağıtıldıktan sonra CA pem dosyanızı DigiCertGlobalRootG2.crt.pem olarak değiştirebilirsiniz.
Dekont
Lütfen sertifika değişikliği yapılana kadar Baltimore sertifikasını bırakmayın veya değiştirmeyin. Değişiklik yapıldıktan sonra bir iletişim göndereceğiz ve baltimore sertifikasını bırakmak güvenli olacaktır.
BaltimoreCyberTrustRoot sertifikasını kaldırırsak ne olur?
MySQL için Azure Veritabanı sunucunuza bağlanırken bağlantı hatalarıyla karşılaşmaya başlayacaksınız. Bağlantıyı sürdürmek için BaltimoreCyberTrustRoot sertifikasıyla SSL'yi yeniden yapılandırmanız gerekir.
Sık sorulan sorular
SSL/TLS kullanmıyorsam kök CA'yı güncelleştirmem gerekiyor mu?
SSL/TLS kullanmıyorsanız hiçbir eylem gerekmez.
Tek sunucu örneğim ne zaman kök sertifika değişikliğine uğrayacak?
BaltimoreCyberTrustRoot'tan DigiCertGlobalRootG2'ye geçiş, Ekim 2022'den itibaren aşamalar halinde Azure'ın tüm bölgelerinde gerçekleştirilecektir. Sunucunuzla bağlantıyı kaybetmediğinizden emin olmak için Birleşik CA sertifikası oluşturma bölümünde belirtilen adımları izleyin. Birleştirilmiş CA sertifikası, bu iki sertifikadan biriyle tek sunucu örneğine SSL üzerinden bağlantı sağlar.
BaltimoreCyberTrustRoot sertifikasını ne zaman tamamen kaldırabilirim?
Tüm Azure bölgelerinde geçiş başarıyla tamamlandıktan sonra, tek CA DigiCertGlobalRootG2 sertifikasını değiştirmenin güvenli olduğunu belirten bir iletişim gönderisi göndeririz.
SSL üzerinden tek sunucu örneğime bağlanırken ca sertifikası belirtmiyorum, yine de yukarıda belirtilen adımları gerçekleştirmem gerekiyor mu?
Güvenilen kök deponuzda her iki CA kök sertifikasına da sahipseniz başka bir işlem yapmanız gerekmez. Bu, kök CA sertifikasına erişmek için yerel depo kullanan istemci sürücüleriniz için de geçerlidir.
SSL/TLS kullanıyorsam kök CA'yı güncelleştirmek için veritabanı sunucumu yeniden başlatmam gerekiyor mu?
Hayır, yeni sertifikayı kullanmaya başlamak için veritabanı sunucusunu yeniden başlatmanız gerekmez. Bu kök sertifika, istemci tarafı bir değişikliktir ve gelen istemci bağlantılarının veritabanı sunucusuna bağlanabilmesi için yeni sertifikayı kullanması gerekir.
Kök sertifika doğrulamasıyla SSL/TLS kullanıp kullanmadığımı Nasıl yaparım? biliyor musunuz?
bağlantı dizesi gözden geçirerek bağlantılarınızın kök sertifikayı doğrulayıp doğrulamadığını belirleyebilirsiniz.
- bağlantı dizesi veya
sslmode=verify-identityiçeriyorsasslmode=verify-casertifikayı güncelleştirmeniz gerekir. - bağlantı dizesi , ,
sslmode=allowsslmode=preferveyasslmode=requireiçeriyorsasslmode=disablesertifikaları güncelleştirmeniz gerekmez. - bağlantı dizesi sslmode belirtmiyorsa sertifikaları güncelleştirmeniz gerekmez.
bağlantı dizesi soyutlayan bir istemci kullanıyorsanız, sertifikaları doğrulayıp doğrulamadığını anlamak için istemcinin belgelerini gözden geçirin.
App Service'i MySQL için Azure Veritabanı ile kullanmanın etkisi nedir?
MySQL için Azure Veritabanı bağlanan Azure uygulama hizmetleri için, uygulamanızla SSL'yi nasıl kullandığınıza bağlı olarak iki olası senaryo vardır.
- Bu yeni sertifika, platform düzeyinde App Service'e eklendi. Uygulamanızda App Service platformuna dahil edilen SSL sertifikalarını kullanıyorsanız herhangi bir işlem yapmanız gerekmez. Bu en yaygın senaryodur.
- Kodunuzda SSL sertifika dosyasının yolunu açıkça dahil ediyorsanız, yeni sertifikayı indirmeniz ve yukarıda belirtildiği gibi birleştirilmiş bir sertifika oluşturmanız ve sertifika dosyasını kullanmanız gerekir. App Service belgelerinde paylaşılan şekilde App Service'te özel kapsayıcılar kullanmanız bu senaryoya iyi bir örnektir. Bu yaygın olmayan bir senaryodur ancak bazı kullanıcıların bunu kullandığını gördük.
Azure Kubernetes Services'ı (AKS) MySQL için Azure Veritabanı kullanmanın etkisi nedir?
Azure Kubernetes Services (AKS) kullanarak MySQL için Azure Veritabanı bağlanmaya çalışıyorsanız, ayrılmış bir müşteri konak ortamından erişime benzer. Buradaki adımlara bakın.
MySQL için Azure Veritabanı bağlanmak için Azure Data Factory kullanmanın etkisi nedir?
Azure Integration Runtime kullanan bir bağlayıcı için bağlayıcı, Azure tarafından barındırılan ortamdaki Windows Sertifika Deposu'ndaki sertifikaları kullanır. Bu sertifikalar zaten yeni uygulanan sertifikalarla uyumludur ve bu nedenle hiçbir eylem gerekmez.
bağlantı dizesi SSL sertifika dosyasının yolunu açıkça eklediğiniz Şirket İçinde Barındırılan Tümleştirme Çalışma Zamanı'nı kullanan bir bağlayıcı için yeni sertifikayı indirmeniz ve kullanmak için bağlantı dizesi güncelleştirmeniz gerekir.
Bu değişiklik için veritabanı sunucusu bakım kapalı kalma süresini planlamam gerekiyor mu?
Hayır. Değişiklik yalnızca veritabanı sunucusuna bağlanmak için istemci tarafında olduğundan, bu değişiklik için veritabanı sunucusu için bakım kapalı kalma süresi gerekmez.
Microsoft sertifikalarını ne sıklıkta güncelleştirir veya süre sonu ilkesi nedir?
MySQL için Azure Veritabanı tarafından kullanılan bu sertifikalar güvenilen Sertifika Yetkilileri (CA) tarafından sağlanır. Bu nedenle, bu sertifikaların desteği CA tarafından bu sertifikaların desteğine bağlıdır. BaltimoreCyberTrustRoot sertifikasının süresi 2025'te dolacak şekilde zamanlanmıştır, bu nedenle Microsoft'un süresi dolmadan önce bir sertifika değişikliği gerçekleştirmesi gerekir. Ayrıca bu önceden tanımlanmış sertifikalarda öngörülemeyen hatalar varsa, Hizmetin her zaman güvenli ve uyumlu olduğundan emin olmak için Microsoft'un 15 Şubat 2021'de gerçekleştirilen değişikliğe en erken şekilde sertifika döndürmesi gerekir.
Okuma amaçlı çoğaltmalar kullanıyorsam bu güncelleştirmeyi yalnızca kaynak sunucuda mı yoksa okuma amaçlı çoğaltmalarda mı gerçekleştirmem gerekiyor?
Bu güncelleştirme bir istemci tarafı değişikliği olduğundan, istemci çoğaltma sunucusundan verileri okurken kullandıysa, bu istemciler için de değişiklikleri uygulamanız gerekir.
Veri ekleme çoğaltması kullanıyorsam herhangi bir eylem gerçekleştirmem gerekiyor mu?
MySQL için Azure Veritabanı bağlanmak için Data-in çoğaltması kullanıyorsanız göz önünde bulundurmanız gereken iki şey vardır:
Veri çoğaltma bir sanal makineden (şirket içi veya Azure sanal makinesi) MySQL için Azure Veritabanı ise, çoğaltmayı oluşturmak için SSL kullanılıp kullanılmadığını denetlemeniz gerekir. SHOW SLAVE STATUS komutunu çalıştırın ve aşağıdaki ayarı denetleyin.
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.pemSertifikanın CA_file, SSL_Cert ve SSL_Key için sağlandığını görürseniz, yeni sertifikayı ekleyerek dosyayı güncelleştirmeniz ve birleştirilmiş bir sertifika dosyası oluşturmanız gerekir.
Veri çoğaltma iki MySQL için Azure Veritabanı sunucusu arasındaysa, CALL mysql.az_replication_change_master yürüterek çoğaltmayı sıfırlamanız ve son parametre master_ssl_ca olarak yeni çift kök sertifikayı sağlamanız gerekir.
SSL'nin kullanılıp kullanılmadığını belirlemek için bir sunucu tarafı sorgusu var mı?
Sunucuya bağlanmak için SSL bağlantısı kullanıp kullanmadığınızı doğrulamak için SSL doğrulamasına bakın.
Sertifika dosyamda zaten DigiCertGlobalRootG2 varsa bir eylem gerekiyor mu?
Hayır. Sertifika dosyanızda zaten DigiCertGlobalRootG2 varsa herhangi bir eylem gerekmez.
ENABLERedirect ile PHP sürücüsü kullanıyorsam neden kök sertifikamı güncelleştirmem gerekiyor?
Uyumluluk gereksinimlerini karşılamak için konak sunucusunun CA sertifikaları BaltimoreCyberTrustRoot olan DigiCertGlobalRootG2 olarak değiştirildi. Bu güncelleştirmeyle, enableRedirect ile PHP İstemci sürücüsünü kullanan veritabanı bağlantıları artık sunucuya bağlanamıyor, istemci cihazlar sertifika değişikliği ve yeni kök CA ayrıntılarının farkında değil. PHP yeniden yönlendirme sürücülerini kullanan istemci cihazları, ağ geçidini atlayarak doğrudan konak sunucusuna bağlanır. Tek MySQL için Azure Veritabanı sunucunun mimarisi hakkında daha fazla bilgi için bu bağlantıya bakın.
Başka sorularım varsa ne olur?
Sorular için Microsoft Soru-Cevap'taki topluluk uzmanlarından yanıt alın. Destek planınız varsa ve teknik yardıma ihtiyacınız varsa bizimle iletişime geçin.