| title | description | author | ms.author | ms.service | ms.topic | ms.date |
|---|---|---|---|---|---|---|
Certificate rotation for Azure Database for MariaDB |
Learn about the upcoming changes of root certificate changes that will affect Azure Database for MariaDB |
mksuni |
sumuth |
mariadb |
conceptual |
01/18/2021 |
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.
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.
Azure database for MariaDB users can only use the predefined certificate to connect to an Azure Database for MariaDB server, which is located here. However, Certificate Authority (CA) Browser forum 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).
On February 15, 2021, the BaltimoreCyberTrustRoot root certificate was replaced with a compliant version of the same BaltimoreCyberTrustRoot root certificate 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 was not replaced with DigiCertGlobalRootG2 and that change is deferred to allow more time for customers to make the change.
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.
-
Download BaltimoreCyberTrustRoot & DigiCertGlobalRootG2 CA from links below:
-
Generate a combined CA certificate store with both BaltimoreCyberTrustRoot and DigiCertGlobalRootG2 certificates are included.
-
For Java (MariaDB Connector/J) users, execute:
keytool -importcert -alias MariaDBServerCACert -file D:\BaltimoreCyberTrustRoot.crt.pem -keystore truststore -storepass password -nopromptkeytool -importcert -alias MariaDBServerCACert2 -file D:\DigiCertGlobalRootG2.crt.pem -keystore truststore -storepass password -nopromptThen replace the original keystore file with the new generated one:
System.setProperty("javax.net.ssl.trustStore","path_to_truststore_file");System.setProperty("javax.net.ssl.trustStorePassword","password");
-
For .NET (MariaDB Connector/NET, MariaDBConnector) users, make sure BaltimoreCyberTrustRoot and DigiCertGlobalRootG2 both exist in Windows Certificate Store, Trusted Root Certification Authorities. If any certificates don't exist, import the missing certificate.
-
For .NET users on Linux using SSL_CERT_DIR, make sure BaltimoreCyberTrustRoot and DigiCertGlobalRootG2 both exist in the directory indicated by SSL_CERT_DIR. If any certificates don't exist, create the missing certificate file.
-
For other (MariaDB Client/MariaDB Workbench/C/C++/Go/Python/Ruby/PHP/NodeJS/Perl/Swift) users, you can merge two CA certificate files like this format below
-----BEGIN CERTIFICATE----- (Root CA1: BaltimoreCyberTrustRoot.crt.pem) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Root CA2: DigiCertGlobalRootG2.crt.pem) -----END CERTIFICATE----- -
-
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.
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.
You will start to connectivity errors while connecting to your Azure Database for MariaDB server. You will need to configure SSL with BaltimoreCyberTrustRoot certificate again to maintain connectivity.
No actions required if you aren't using SSL/TLS.
No, you don't need to restart the database server to start using the new certificate. Certificate update is a client-side change, and the incoming client connections need to use the new certificate to ensure that they can connect to the database server.
You can identify whether your connections verify the root certificate by reviewing your connection string.
- If your connection string includes
sslmode=verify-caorsslmode=verify-identity, you need to update the certificate. - If your connection string includes
sslmode=disable,sslmode=allow,sslmode=prefer, orsslmode=require, you don't need to update certificates. - If your connection string doesn't specify sslmode, you don't need to update certificates.
If you're using a client that abstracts the connection string away, review the client's documentation to understand whether it verifies certificates.
For Azure app services, connecting to Azure Database for MariaDB, there are two possible scenarios depending on how on you're using SSL with your application.
- This new certificate has been added to App Service at platform level. If you're using the SSL certificates included on App Service platform in your application, then no action is needed. This is the most common scenario.
- If you're explicitly including the path to SSL cert file in your code, then you would need to download the new cert and update the code to use the new cert. A good example of this scenario is when you use custom containers in App Service as shared in the App Service documentation. This is an uncommon scenario but we have seen some users using this.
If you're trying to connect to the Azure Database for MariaDB using Azure Kubernetes Services (AKS), it's similar to access from a dedicated customers host environment. Refer to the steps here.
For connector using Azure Integration Runtime, the connector uses certificates in the Windows Certificate Store in the Azure-hosted environment. These certificates are already compatible to the newly applied certificates and so no action is needed.
For connector using Self-hosted Integration Runtime where you explicitly include the path to SSL cert file in your connection string, you'll need to download the new certificate and update the connection string to use it.
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.
For servers created after February 15, 2021 (02/15/2021), you will continue to use the BaltimoreCyberTrustRoot for your applications to connect using SSL.
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 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.
10. 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.
-
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.
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
If you're using Data-in replication 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.
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.pemIf you do see the certificate is provided for the CA_file, SSL_Cert and SSL_Key, you will need to update the file by adding the new certificate and create a combined cert file.
-
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.
To verify if you're using SSL connection to connect to the server refer SSL verification.
No. There's no action needed if your certificate file already has the DigiCertGlobalRootG2.
If you have questions, get answers from community experts in Microsoft Q&A. If you have a support plan and you need technical help, contact us.