Skip to content

Commit a6e2134

Browse files
committed
Fix broken links
1 parent 816c3a0 commit a6e2134

File tree

4 files changed

+4
-4
lines changed

4 files changed

+4
-4
lines changed

articles/iot-dps/how-to-roll-certificates.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ When a device is initially provisioned through auto-provisioning, it boots-up, a
4949

5050
Once a new leaf certificate has been rolled to the device, it can no longer connect to the IoT hub because it’s using a new certificate to connect. The IoT hub only recognizes the device with the old certificate. The result of the device's connection attempt will be an "unauthorized" connection error. To resolve this error, you must update the enrollment entry for the device to account for the device's new leaf certificate. Then the provisioning service can update the IoT Hub device registry information as needed when the device is reprovisioned.
5151

52-
One possible exception to this connection failure would be a scenario where you've created an [Enrollment Group](concepts-service.md#enrollment-group) for your device in the provisioning service. In this case, if you aren't rolling the root or intermediate certificates in the device's certificate chain of trust, then the device will be recognized if the new certificate is part of the chain of trust defined in the enrollment group. If this scenario arises as a reaction to a security breach, you should at least disallow the specific device certificates in the group that are considered to be breached. For more information, see [Disallow specific devices in an enrollment group](./how-to-revoke-device-access-portal.md#disallow-specific-devices-in-an-enrollment-group).
52+
One possible exception to this connection failure would be a scenario where you've created an [Enrollment Group](concepts-service.md#enrollment-group) for your device in the provisioning service. In this case, if you aren't rolling the root or intermediate certificates in the device's certificate chain of trust, then the device will be recognized if the new certificate is part of the chain of trust defined in the enrollment group. If this scenario arises as a reaction to a security breach, you should at least disallow the specific device certificates in the group that are considered to be breached. For more information, see [Disallow specific devices in an enrollment group](./how-to-revoke-device-access-portal.md#disallow-specific-devices-from-an-x509-enrollment-group)
5353

5454
How you handle updating the enrollment entry will depend on whether you're using individual enrollments, or group enrollments. Also the recommended procedures differ depending on whether you're rolling certificates because of a security breach, or certificate expiration. The following sections describe how to handle these updates.
5555

articles/iot-dps/how-to-unprovision-devices.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ With enrollment groups, there are two scenarios to consider:
6868
- If you have the device (end-entity) certificate, you can create a disabled X.509 individual enrollment.
6969
- If you don't have the device certificate, you can create a disabled symmetric key individual enrollment based on the device ID in the registration record for that device.
7070

71-
To learn more, see [Disallow specific devices in an enrollment group](how-to-revoke-device-access-portal.md#disallow-specific-devices-in-an-enrollment-group).
71+
To learn more, see [Disallow specific devices in an enrollment group](./how-to-revoke-device-access-portal.md#disallow-specific-devices-from-an-x509-enrollment-group).
7272

7373
The presence of a disabled individual enrollment for a device revokes access to the provisioning service for that device while still permitting access for other devices that have the enrollment group's signing certificate in their chain. Do not delete the disabled individual enrollment for the device. Doing so will allow the device to re-enroll through the enrollment group.
7474

File renamed without changes.

includes/iot-dps-individual-enrollment-x509.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -29,8 +29,8 @@ ms.author: kgremban
2929

3030
| Field | Description |
3131
| :---- | :---------- |
32-
| **Target IoT hubs** |Select one or more of your linked IoT hubs, or add a new link to an IoT hub. To learn more about linking IoT hubs to your DPS instance, see [How to link and manage IoT hubs](how-to-manage-linked-iot-hubs.md).|
33-
| **Allocation policy** | If you selected more than one linked IoT hub, select how you want to assign devices to the different hubs. To learn more about allocation policies, see [How to use allocation policies](how-to-use-allocation-policies.md).<br><br>If you selected only one linked IoT hub, we recommend using the **Evenly weighted distribution** policy.|
32+
| **Target IoT hubs** |Select one or more of your linked IoT hubs, or add a new link to an IoT hub. To learn more about linking IoT hubs to your DPS instance, see [How to link and manage IoT hubs](../articles/iot-dps/how-to-manage-linked-iot-hubs.md).|
33+
| **Allocation policy** | If you selected more than one linked IoT hub, select how you want to assign devices to the different hubs. To learn more about allocation policies, see [How to use allocation policies](../articles/iot-dps/how-to-use-allocation-policies.md).<br><br>If you selected only one linked IoT hub, we recommend using the **Evenly weighted distribution** policy.|
3434

3535
1. Select **Next: Device settings**
3636

0 commit comments

Comments
 (0)