Baltimore root cert migration has ended

kgremban · kgremban · commit ae81ceff487d · 2024-11-21T13:13:15.000-08:00
diff --git a/articles/iot-dps/tls-support.md b/articles/iot-dps/tls-support.md
@@ -91,7 +91,20 @@ These cipher suites are currently still supported by DPS but will be depreciated
 
 When DPS enrollments are configured for X.509 authentication, mutual TLS (mTLS) is supported by DPS.
 
-## Certificate pinning
+## Server TLS certificate
+
+During a TLS handshake, DPS presents RSA-keyed server certificates to connecting clients. All DPS instances in the global Azure cloud use the TLS certificate issued by the DigiCert Global Root G2. The [device SDKs](./iot-hub-devguide-sdks.md) include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to DPS and IoT Hub.
+
+We also recommend adding the Microsoft RSA Root Certificate Authority 2017 certificates to your devices to prevent disruptions in case the DigiCert Global Root G2 is retired unexpectedly. Although root CA migrations are rare, for resilience in the modern security landscape you should prepare your IoT scenario for the unlikely event that a root CA is compromised or an emergency root CA migration is necessary.
+
+We strongly recommend that all devices trust the following root CAs:
+
+* DigiCert Global G2 root CA
+* Microsoft RSA root CA 2017
+
+For links to download these certificates, see [Azure Certificate Authority details](../security/fundamentals/azure-CA-details.md).
+
+### Certificate pinning
 
 [Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (aka leaf certificates) and intermediate certificates associated with DPS endpoints is strongly discouraged as Microsoft frequently rolls these certificates with little or no notice. If you must, only pin the root certificates as described in this [Azure IoT blog post](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
 
diff --git a/articles/iot-hub/create-connect-device.md b/articles/iot-hub/create-connect-device.md
@@ -22,6 +22,31 @@ Create a device identity for your device to connect to Azure IoT Hub. This artic
 
 * If your IoT hub is managed with role-based access control (RBAC), then you need **Read/Write/Delete Device/Module** permissions for the steps in this article. Those permissions are included in [IoT Hub Registry Contributor](../role-based-access-control/built-in-roles/internet-of-things.md#iot-hub-registry-contributor) role.
 
+## Prepare certificates
+
+Devices use two different types of certificates to connect to IoT Hub. When preparing your device, make sure you have all the proper certificates created and added to the device before connecting.
+
+* Public root certificates: All devices need a copy of the public root certificates that IoT Hub, IoT Central, and Device Provisioning Service use to authorize connections.
+* Authentication certificates: X.509 certificates are the recommended method for authenticating a device identity.
+
+### Required public root certificates
+
+Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. The device SDKs include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to the IoT hub.
+
+For more information about IoT Hub's recommended certificate practices, see [TLS support](./iot-hub-tls-support.md).
+
+### Authentication certificates
+
+If you use X.509 certificate authentication for your devices, make sure your certificates are ready before registering a device:
+
+* For CA-signed certificates, the tutorial [Create and upload certificates for testing](./tutorial-x509-test-certs.md) provides a good introduction for how to create CA-signed certificates and upload them to IoT Hub. After completing that tutorial, you're ready to register a device with **X.509 CA signed** authentication.
+
+* For self-signed certificates, you need two device certificates (a primary and a secondary certificate) on the device and thumbprints for both to upload to IoT Hub. One way to retrieve the thumbprint from a certificate is with the following OpenSSL command:
+
+  ```bash
+  openssl x509 -in <certificate filename>.pem -text -fingerprint
+  ```
+
 ## Register a device
 
 In this section, you create a device identity in the [identity registry in your IoT hub](./iot-hub-devguide-identity-registry.md). A device can't connect to a hub unless it has a device identity.
@@ -42,18 +67,6 @@ When you register a device, you choose its authentication method. IoT Hub suppor
 
   If your device has a CA-signed X.509 certificate, then you upload a root or intermediate certificate authority (CA) certificate in the signing chain to IoT Hub before you register the device. The device has an X.509 certificate with the verified X.509 CA in its certificate chain of trust. When the device connects, it presents its full certificate chain and the IoT hub can validate it because it knows the X.509 CA. Multiple devices can authenticate against the same verified X.509 CA. For more information, see [Authenticate identities with X.509 certificates](./authenticate-authorize-x509.md).
 
-### Prepare certificates
-
-If you're using either of the X.509 certificate authentication methods, make sure your certificates are ready before registering a device:
-
-* For CA-signed certificates, the tutorial [Create and upload certificates for testing](./tutorial-x509-test-certs.md) provides a good introduction for how to create CA-signed certificates and upload them to IoT Hub. After completing that tutorial, you're ready to register a device with **X.509 CA signed** authentication.
-
-* For self-signed certificates, you need two device certificates (a primary and a secondary certificate) on the device and thumbprints for both to upload to IoT Hub. One way to retrieve the thumbprint from a certificate is with the following OpenSSL command:
-
-  ```bash
-  openssl x509 -in <certificate filename>.pem -text -fingerprint
-  ```
-
 ### Add a device
 
 Create a device identity in your IoT hub.
diff --git a/articles/iot-hub/iot-hub-tls-support.md b/articles/iot-hub/iot-hub-tls-support.md
@@ -17,16 +17,21 @@ TLS 1.0 and 1.1 are considered legacy and are planned for deprecation. For more
 
 ## IoT Hub's server TLS certificate
 
-During a TLS handshake, IoT Hub presents RSA-keyed server certificates to connecting clients.In the past, the certificates were all rooted from the Baltimore Cybertrust Root CA. Because the Baltimore root is at end-of-life, we are in the process of migrating to a new root called DigiCert Global G2. This migration impacts all devices currently connecting to IoT Hub. For more information, see [IoT TLS certificate update](https://aka.ms/iot-ca-updates).
+During a TLS handshake, IoT Hub presents RSA-keyed server certificates to connecting clients. All IoT hubs in the global Azure cloud use the TLS certificate issued by the DigiCert Global Root G2. The [device SDKs](./iot-hub-devguide-sdks.md) include the DigiCert Global Root G2 TLS certificate they currently need to establish a secure connection to the IoT hub.
 
-Although root CA migrations are rare, for resilience in the modern security landscape you should prepare your IoT scenario for the unlikely event that a root CA is compromised or an emergency root CA migration is necessary. We strongly recommend that all devices trust the following three root CAs:
+We also recommend adding the Microsoft RSA Root Certificate Authority 2017 certificates to your devices to prevent disruptions in case the DigiCert Global Root G2 is retired unexpectedly. Although root CA migrations are rare, for resilience in the modern security landscape you should prepare your IoT scenario for the unlikely event that a root CA is compromised or an emergency root CA migration is necessary.
+
+We strongly recommend that all devices trust the following root CAs:
 
-* Baltimore CyberTrust root CA
 * DigiCert Global G2 root CA
 * Microsoft RSA root CA 2017
 
 For links to download these certificates, see [Azure Certificate Authority details](../security/fundamentals/azure-CA-details.md).
 
+### Certificate pinning
+
+[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (aka leaf certificates) and intermediate certificates associated with IoT Hub endpoints is strongly discouraged as Microsoft frequently rolls these certificates with little or no notice. If you must, only pin the root certificates as described in this [Azure IoT blog post](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
+
 ### Elliptic Curve Cryptography (ECC) server TLS certificate (preview)
 
 IoT Hub ECC server TLS certificate is available for public preview. While offering similar security to RSA certificates, ECC certificate validation (with ECC-only cipher suites) uses up to 40% less compute, memory, and bandwidth. These savings are important for IoT devices because of their smaller profiles and memory, and to support use cases in network bandwidth limited environments.
@@ -143,17 +148,12 @@ After a successful TLS handshake, IoT Hub can authenticate a device using a symm
 
 ## Mutual TLS support
 
-Mutual TLS authentication ensures that the client _authenticates_ the server (IoT Hub) certificate and the server (IoT Hub) _authenticates_ the [X.509 client certificate or X.509 thumbprint](tutorial-x509-test-certs.md#create-a-client-certificate-for-a-device). _Authorization_ is performed by IoT Hub after _authentication_ is complete.
+Mutual TLS authentication ensures that the client *authenticates* the server (IoT Hub) certificate and the server (IoT Hub) *authenticates* the [X.509 client certificate or X.509 thumbprint](tutorial-x509-test-certs.md#create-a-client-certificate-for-a-device). *Authorization* is performed by IoT Hub after *authentication* is complete.
 
-For AMQP and MQTT protocols, IoT Hub requests a client certificate in the initial TLS handshake. If one is provided, IoT Hub _authenticates_ the client certificate and the client _authenticates_ the IoT Hub certificate. This process is called mutual TLS authentication. When IoT Hub receives an MQTT connect packet or an AMQP link opens, IoT Hub performs _authorization_ for the requesting client and determines if the client requires X.509 authentication. If mutual TLS authentication was completed and the client is authorized to connect as the device, it is allowed. However, if the client requires X.509 authentication and client authentication was not completed during the TLS handshake, then IoT Hub rejects the connection.
+For AMQP and MQTT protocols, IoT Hub requests a client certificate in the initial TLS handshake. If one is provided, IoT Hub *authenticates* the client certificate and the client *authenticates* the IoT Hub certificate. This process is called mutual TLS authentication. When IoT Hub receives an MQTT connect packet or an AMQP link opens, IoT Hub performs *authorization* for the requesting client and determines if the client requires X.509 authentication. If mutual TLS authentication was completed and the client is authorized to connect as the device, it is allowed. However, if the client requires X.509 authentication and client authentication was not completed during the TLS handshake, then IoT Hub rejects the connection.
 
 For HTTP protocol, when the client makes its first request, IoT Hub checks if the client requires X.509 authentication and if client authentication was complete then IoT Hub performs authorization. If client authentication was not complete, then IoT Hub rejects the connection
 
-
-## Certificate pinning
-
-[Certificate pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) and filtering of the TLS server certificates (aka leaf certificates) and intermediate certificates associated with IoT Hub endpoints is strongly discouraged as Microsoft frequently rolls these certificates with little or no notice. If you must, only pin the root certificates as described in this [Azure IoT blog post](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
-
 ## TLS maximum fragment length negotiation (preview)
 
 IoT Hub also supports TLS maximum fragment length negotiation, which is sometimes known as TLS frame size negotiation. This feature is in public preview. 
diff --git a/articles/iot-hub/migrate-tls-certificate.md b/articles/iot-hub/migrate-tls-certificate.md
@@ -7,7 +7,7 @@ author: kgremban
 ms.author: kgremban
 ms.service: azure-iot-hub
 ms.topic: how-to
-ms.date: 01/16/2024
+ms.date: 11/21/2024
 ---
 
 # Migrate IoT Hub resources to a new TLS certificate root
@@ -23,19 +23,7 @@ You should start planning now for the effects of migrating your IoT hubs to the
 
 ## Timeline
 
-The IoT Hub migration is complete except for hubs that have already been approved for an extension. If your IoT hub is found to be using the Baltimore certificate without an agreement in place with the product team, your hub will be migrated without any further notice.
-
-After all IoT hubs have migrated, DPS will perform its migration between January 15 and September 30, 2024.
-
-For each IoT hub with an extension agreement in place, you can expect the following:
-
-* **One to two weeks before migration**: The subscription owners of each IoT hub receive an email notification informing them of their migration date. This notification doesn't apply to hubs that are manually migrated.
-* **Day of the migration**: The IoT hub switches its TLS certificate to the DigiCert Global Root G2, which results in no downtime for the IoT hub. IoT Hub doesn't force device reconnections.
-* **Following the migration**: The subscription owners receive a notification confirming that the IoT hub was migrated. Devices attempt to reconnect based on their individual retry logic, at which point they request and receive the new server certificate from IoT Hub and reconnect only if they trust the Digicert Global Root G2.
-
-### Request an extension
-
-As of August 2023 the extension request process is closed for IoT Hub and IoT Central. If your IoT hub is found to be using the Baltimore certificate without an extension agreement in place with the product team, your hub will be migrated without any further notice.
+As of September 30, 2024, the migration is complete for all IoT Hub, IoT Central, and Device Provisioning Service resources.
 
 ## Required steps
 
@@ -53,30 +41,6 @@ To prepare for the migration, take the following steps:
 
 For more information about how to test whether your devices are ready for the TLS certificate migration, see the blog post [Azure IoT TLS: Critical changes are almost here](https://techcommunity.microsoft.com/t5/internet-of-things-blog/azure-iot-tls-critical-changes-are-almost-here-and-why-you/ba-p/2393169).
 
-## Check the migration status of an IoT hub
-
-To know whether an IoT hub has been migrated or not, check the active certificate root for the hub.
-
-# [Azure portal](#tab/portal)
-
-1. In the [Azure portal](https://portal.azure.com), navigate to your IoT hub.
-
-1. Select **Export template** in the **Automation** section of the navigation menu.
-
-1. Wait for the template to generate, then navigate to the **resources.properties.features** property in the JSON template. If **RootCertificateV2** is listed as a feature, then your hub has been migrated to DigiCert Global G2.
-
-# [Azure CLI](#tab/cli)
-
-Use the [az iot hub certificate root-authority show](/cli/azure/iot/hub/certificate/root-authority#az-iot-hub-certificate-root-authority-show) command to view the current certificate root-authority for your IoT hub.
-
-```azurecli-interactive
-az iot hub certificate root-authority show --hub-name <iothub_name>
-```
-
-In the Azure CLI, the existing Baltimore CyberTrust Root certificate is referred to as `v1`, and the new DigiCert Global Root G2 certificate is referred to as `v2`. If the certificate root is listed as **v2**, then the IoT hub has been successfully migrated.
-
----
-
 ## Frequently asked questions
 
 ### My devices uses SAS/X.509/TPM authentication. Will this migration affect my devices?
diff --git a/articles/iot/iot-mqtt-connect-to-iot-hub.md b/articles/iot/iot-mqtt-connect-to-iot-hub.md
@@ -197,7 +197,7 @@ To learn more, see [Tutorial - Use MQTT to develop an IoT device client](./tutor
 
 To use the MQTT protocol directly, your client *must* connect over TLS/SSL. Attempts to skip this step fail with connection errors.
 
-In order to establish a TLS connection, you may need to download and reference the DigiCert root certificate that Azure uses. Between February 15 and October 15, 2023, Azure IoT Hub is migrating its TLS root certificate from the DigiCert Baltimore Root Certificate to the DigiCert Global Root G2. During the migration period, you should have both certificates on your devices to ensure connectivity. For more information about the migration, see [Migrate IoT resources to a new TLS certificate root](../iot-hub/migrate-tls-certificate.md) For more information about these certificates, see [Digicert's website](https://www.digicert.com/digicert-root-certificates.htm).
+In order to establish a TLS connection, you may need to download and reference the DigiCert Global Root G2 root certificate that Azure uses. For more information about this certificate, see [Digicert's website](https://www.digicert.com/digicert-root-certificates.htm).
 
 The following example demonstrates how to implement this configuration, by using the Python version of the [Paho MQTT library](https://pypi.python.org/pypi/paho-mqtt) by the Eclipse Foundation.
 
