Merge pull request #230078 from code-sidd/mariadb_notification

Mariadb CA root changes

Author: v-regandowner

articles/mariadb/concepts-certificate-rotation.md

@@ -10,29 +10,24 @@ ms.date: 06/24/2022
 
 # Understanding the changes in the Root CA change for Azure Database for MariaDB
 
-Azure Database for MariaDB successfully completed the root certificate change on **February 15, 2021 (02/15/2021)** as part of standard maintenance and security best practices. This article gives you more details about the changes, the resources affected, and the steps needed to ensure that your application maintains connectivity to your database server.
+Azure database for MariaDB as part of standard maintenance and security best practices will complete the root certificate change starting March 2023. This article gives you more details about the changes, the resources affected, and the steps needed to ensure that your application maintains connectivity to your database server.
 
 > [!NOTE]
 > This article contains references to the term *slave*, a term that Microsoft no longer uses. When the term is removed from the software, we'll remove it from this article.
 >
 
 ## Why root certificate update is required?
 
-Azure database for MariaDB users can only use the predefined certificate to connect to an Azure Database for MariaDB server, which is located [here](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem). However, [Certificate Authority (CA) Browser forum](https://cabforum.org/) recently published reports of multiple certificates issued by CA vendors to be non-compliant.
+Azure Database for MariaDB users can only use the predefined certificate to connect to their MariaDB server, which is located [here](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem). However, [Certificate Authority (CA) Browser forum](https://cabforum.org/) recently published reports of multiple certificates issued by CA vendors to be non-compliant.
 
 As per the industry's compliance requirements, CA vendors began revoking CA certificates for non-compliant CAs, requiring servers to use certificates issued by compliant CAs, and signed by CA certificates from those compliant CAs. Since Azure Database for MariaDB used one of these non-compliant certificates, we needed to rotate the certificate to the compliant version to minimize the potential threat to your MySQL servers.
 
-The new certificate is rolled out and in effect starting February 15, 2021 (02/15/2021).
-
-## What change was performed on February 15, 2021 (02/15/2021)?
-
-On February 15, 2021, the [BaltimoreCyberTrustRoot root certificate](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) was replaced with a **compliant version** of the same [BaltimoreCyberTrustRoot root certificate](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) to ensure existing customers do not need to change anything and there is no impact to their connections to the server. During this change, the [BaltimoreCyberTrustRoot root certificate](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) was **not replaced** with [DigiCertGlobalRootG2](https://cacerts.digicert.com/DigiCertGlobalRootG2.crt.pem) and that change is deferred to allow more time for customers to make the change.
 
 ## Do I need to make any changes on my client to maintain connectivity?
 
-There is no change required on client side. if you followed our previous recommendation below, you will still be able to continue to connect as long as **BaltimoreCyberTrustRoot certificate is not removed** from the combined CA certificate. **We recommend to not remove the BaltimoreCyberTrustRoot from your combined CA certificate until further notice to maintain connectivity.**
+If you followed steps mentioned under [Create a combined CA certificate](#create-a-combined-ca-certificate) below, you can continue to connect as long as **BaltimoreCyberTrustRoot certificate is not removed** from the combined CA certificate. **To maintain connectivity, we recommend that you retain the BaltimoreCyberTrustRoot in your combined CA certificate until further notice.**
 
-### Previous recommendation
+### Create a combined CA certificate
 
 - Download **BaltimoreCyberTrustRoot** & **DigiCertGlobalRootG2** CA from links below:
 
@@ -76,11 +71,9 @@ There is no change required on client side. if you followed our previous recomme
 - Replace the original root CA pem file with the combined root CA file and restart your application/client.
 - In future, after the new certificate deployed on the server side, you can change your CA pem file to DigiCertGlobalRootG2.crt.pem.
 
-## Why was BaltimoreCyberTrustRoot certificate not replaced to DigiCertGlobalRootG2 during this change on February 15, 2021?
-
-We evaluated the customer readiness for this change and realized many customers were looking for additional lead time to manage this change. In the interest of providing more lead time to customers for readiness, we have decided to defer the certificate change to DigiCertGlobalRootG2 for at least a year providing sufficient lead time to the customers and end users.
+#### If I'm not using SSL/TLS, do I still need to update the root CA?
 
-Our recommendations to users is, use the aforementioned steps to create a combined certificate and connect to your server but do not remove BaltimoreCyberTrustRoot certificate until we send a communication to remove it.
+No actions are required if you aren't using SSL/TLS.
 
 ## What if we removed the BaltimoreCyberTrustRoot certificate?
 
@@ -127,21 +120,17 @@ For connector using Self-hosted Integration Runtime where you explicitly include
 
 No. Since the change here's only on the client side to connect to the database server, there's no maintenance downtime needed for the database server for this change.
 
-### 8. If I create a new server after February 15, 2021 (02/15/2021), will I be impacted?
-
-For servers created after February 15, 2021 (02/15/2021), you will continue to use the [BaltimoreCyberTrustRoot](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) for your applications to connect using SSL.
-
-### 9. How often does Microsoft update their certificates or what is the expiry policy?
+### 8. How often does Microsoft update their certificates or what is the expiry policy?
 
-These certificates used by Azure Database for MariaDB are provided by trusted Certificate Authorities (CA). So the support of these certificates is tied to the support of these certificates by CA. The [BaltimoreCyberTrustRoot](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) certificate is scheduled to expire in 2025 so Microsoft will need to perform a certificate change before the expiry. Also in case if there are unforeseen bugs in these predefined certificates, Microsoft will need to make the certificate rotation at the earliest similar to the change performed on February 15, 2021 to ensure the service is secure and compliant at all times.
+These certificates used by Azure Database for MariaDB are provided by trusted Certificate Authorities (CA). So the support of these certificates is tied to the support of these certificates by CA. The [BaltimoreCyberTrustRoot](https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem) certificate is scheduled to expire in 2025 so Microsoft will need to perform a certificate change before the expiry. 
 
-### 10. If I'm using read replicas, do I need to perform this update only on source server or the read replicas?
+### 9. If I'm using read replicas, do I need to perform this update only on source server or the read replicas?
 
 Since this update is a client-side change, if the client used to read data from the replica server, you'll need to apply the changes for those clients as well.
 
-### 11. If I'm using Data-in replication, do I need to perform any action?
+### 10. If I'm using Data-in replication, do I need to perform any action?
 
-- If the data-replication is from a virtual machine (on-prem or Azure virtual machine) to Azure Database for MySQL, you need to check if SSL is being used to create the replica. Run **SHOW SLAVE STATUS** and check the following setting.
+- If the data-replication is from a virtual machine (on-premises or Azure virtual machine) to Azure Database for MySQL, you need to check if SSL is being used to create the replica. Run **SHOW SLAVE STATUS** and check the following setting.
 
     ```azurecli-interactive
     Master_SSL_Allowed            : Yes
@@ -154,7 +143,7 @@ Since this update is a client-side change, if the client used to read data from
 
 If you're using [Data-in replication](concepts-data-in-replication.md) to connect to Azure Database for MySQL, there are two things to consider:
 
-- If the data-replication is from a virtual machine (on-prem or Azure virtual machine) to Azure Database for MySQL, you need to check if SSL is being used to create the replica. Run **SHOW SLAVE STATUS** and check the following setting.
+- If the data-replication is from a virtual machine (on-premises or Azure virtual machine) to Azure Database for MySQL, you need to check if SSL is being used to create the replica. Run **SHOW SLAVE STATUS** and check the following setting.
 
   ```azurecli-interactive
   Master_SSL_Allowed            : Yes
@@ -169,14 +158,14 @@ If you're using [Data-in replication](concepts-data-in-replication.md) to connec
 
 - If the data-replication is between two Azure Database for MySQL, then you'll need to reset the replica by executing **CALL mysql.az_replication_change_master** and provide the new dual root certificate as last parameter [master_ssl_ca](howto-data-in-replication.md#link-the-source-and-replica-servers-to-start-data-in-replication).
 
-### 12. Do we have server-side query to verify if SSL is being used?
+### 11. Do we have server-side query to verify if SSL is being used?
 
 To verify if you're using SSL connection to connect to the server refer [SSL verification](howto-configure-ssl.md#verify-the-ssl-connection).
 
-### 13. Is there an action needed if I already have the DigiCertGlobalRootG2 in my certificate file?
+### 12. Is there an action needed if I already have the DigiCertGlobalRootG2 in my certificate file?
 
 No. There's no action needed if your certificate file already has the **DigiCertGlobalRootG2**.
 
-### 14. What if I have further questions?
+### 13. What if I have further questions?
 
 If you have questions, get answers from community experts in [Microsoft Q&A](mailto:[email protected]). If you have a support plan and you need technical help, [contact us](mailto:[email protected]).