Merge pull request #223086 from jlian/patch-86

IoT Hub supports mutual TLS

Author: prmerger-automator[bot]

articles/iot-edge/iot-edge-certs.md

@@ -111,7 +111,7 @@ In summary, *EdgeGateway* can verify and trust *ContosoIotHub's* identity becaus
 
 ## IoT Hub verifies IoT Edge device identity
 
-How does *ContosoIotHub* verify it's communicating with *EdgeGateway*? Verification is done by checking the certificate at the IoTHub application code level. This step happens together with the *TLS handshake* (IoT Hub doesn't support mutual TLS). Authentication of the client doesn't happen at the TLS level, only at the application layer. For simplicity, we'll skip some steps in the following diagram.
+How does *ContosoIotHub* verify it's communicating with *EdgeGateway*? Since [IoT Hub supports *mutual TLS* (mTLS)](../iot-hub/iot-hub-tls-support.md#mutual-tls-support), it checks *EdgeGateway*'s certificate during [client-authenticated TLS handshake](https://wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake). For simplicity, we'll skip some steps in the following diagram.
 
 :::image type="content" source="./media/iot-edge-certs/verify-edge-identity.svg" alt-text="Sequence diagram showing certificate exchange from IoT Edge device to IoT Hub with certificate thumbprint check verification on IoT Hub.":::
 
@@ -127,7 +127,7 @@ sequenceDiagram
     ContosoIotHub->>EdgeGateway: Great, let's connect
 -->
 
-In this case, IoT Edge provides its **IoT Edge device identity certificate**. From *ContosoIotHub* perspective, it checks if the thumbprint of the provided certificate matches its record. When you provision an IoT Edge device in IoT Hub, you provide a thumbprint. The thumbprint is what IoT Hub uses to verify the certificate.
+In this case, *EdgeGateway* provides its **IoT Edge device identity certificate**. From *ContosoIotHub* perspective, it checks both that the thumbprint of the provided certificate matches its record and *EdgeGateway* has the private key paired with the certificate it presented. When you provision an IoT Edge device in IoT Hub, you provide a thumbprint. The thumbprint is what IoT Hub uses to verify the certificate.
 
 > [!TIP]
 > IoT Hub requires two thumprints when registering and IoT Edge device. For best practice, prepare two different device identity certificates with different expiration dates. This way, if one certificate expires, the other is still valid and gives you time to rotate the expired certificate. However, it's also possible to use only one certificate for registration by putting the same thumbprint for both fields.
@@ -264,7 +264,7 @@ To secure Edge CA in production:
 * Put the EdgeCA private key in a trusted platform module (TPM), preferably in a fashion where the private key is ephemerally generated and never leaves the TPM.
 * Use a Public Key Infrastructure (PKI) to which Edge CA rolls up. This provides the ability to disable or refuse renewal of compromised certificates. The PKI can be managed by customer IT if they have the know how (lower cost) or through a commercial PKI provider.
 
-### Self-signed root CA complexity
+### Self-signed root CA specificity
 
 The [*edgeHub* module](iot-edge-runtime.md#iot-edge-hub) is an important component that makes up IoT Edge by handling all incoming traffic. In this example, it uses a certificate issued by Edge CA, which is in turn issued by a self-signed root CA. Because the root CA isn't trusted by the OS, the only way *TempSensor* would trust it is to install the CA certificate onto the device. This is also known as the *trust bundle* scenario, where you need to distribute the root to clients that need to trust the chain. The trust bundle scenario can be troublesome because you need access the device and install the certificate. Installing the certificate requires planning. It can be done with scripts, added during manufacturing, or pre-installed in the OS image.