-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identity provisioning fails to add subject DN to CSR using EST and x509 authentication when using identity certificate #6579
Comments
Attempting to reproduce the situation described. Will update with findings after testing DPS with EST and x509. |
From speaking internally, DPS only checks CN for provisioning, so it generally does not matter that we drop the other DN fields for the identity cert. This also appears to be a known issue that we are tracking internally to fix. In the meantime, if you don't require EST you can follow this: https://docs.microsoft.com/en-us/azure/iot-edge/how-to-provision-devices-at-scale-linux-x509?view=iotedge-2020-11&tabs=individual-enrollment%2Cubuntu. |
Thank you for your response @nyanzebra. The problem described above does not lie within DPS (or the device connection group), this works fine. It is a technical limitation of the current configuration of the EST Server (DigiCert IoT Device Manager), that the organization unit must be included in the subject of the CSR otherwise it will not be signed. This limitation is because we're using X509 authentication to the EST Server (with the manufacturing/birth certificate) to obtain an operational certificate. Another field than the common name (in the subject DN) is then used by IoT Device Manager to match both certificates to the same device. |
@varunpuranik, should I mark this as bug? Also, do we have any alternative EST configurations that we can suggest? |
Is it possible to configure it to remove this constraint? |
@jlian We're in contact with the provider and still waiting for a response. Currently, we are not able to remove this constraint and we're required to adjust the subject in the EST request. This results in a workaround which can not be used in production. Do you have an estimate about the timeline when a fix could be included in a LTS release? |
We've triaged the bug and are looking into a fix, but not too sure that it'll make the next release (1.4.2) which needs to go out in time to take the latest .NET security patch and dependency updates. My guess would be that it'll take about a month for this fix to be released as part of 1.4.3. Do you need it sooner? |
Hi @jlian , I'm working on the same project as @cookieofcode . |
We've picked up the work and are currently forecasting late Oct to release this in 1.4.3. |
Still targeting late Oct to release in 1.4.3. |
I am facing similar issue, when I trying to provision a device using EST server (libest from cisco) installed outside the machine where azure iot identity service (aziotctl 1.4.1 ) runs. When debugging the network traffic, I could see that the aziotctl sends the device cert request(CSR) but est-server was not able to validate the request. does it mean that the csr created by aziotctl is invalid? |
Hey folks, the change is merged (thanks @onalante-msft). Ideally, we could have you try it before we take it for the release:
@cookieofcode, @pebneter, and @MZDN do you think you could give it a try this week? |
H @jlian, thanks for the update! |
Hi @jlian, |
@MZDN I think your issue is a bit different compared to the original, which is about the missing Subject DN fields such as the OU. AFAIK, the original issue affects IoT Edge using DigiCert IoT Manger EST provider. Since you're trying this with libest, I believe the issue is different. Could you please open a separate issue and fill out the bug report, so that we could properly diagnose? In it, please also include if you're following steps from https://learn.microsoft.com/en-us/azure/iot-edge/tutorial-configure-est-server (which uses libest) and if there are deviations. |
Hi @jlian, |
Hi @jlian. Thank you for the patch. I've tried the patch with the following versions:
And the following configuration:
Unfortunately, the intercepted call to the EST endpoint does not contain another field in the subject than the common name (the organizational unit is still missing). In the mean time, we found a solution with the EST provider to omit the organizational unit in the certificate signing request. Regardless of this, it should be possible to configure an alternative subject in the certificate signing request. |
@cookieofcode that's weird, I wonder what's the difference between your setup vs Azure/iot-identity-service#455 (comment)? @onalante-msft any ideas? |
@cookieofcode Have you re-run |
This issue is being marked as stale because it has been open for 30 days with no activity. |
IoT Edge 1.4.8 is released and includes this fix (which is part of identity service 1.4.2) |
Expected Behavior
The configured Distinguished Name (DN) in the "subject" configuration should be added to the Certificate Signing Request (CSR) using Enrollment over Secure Transport (EST) when using X509 (client) authentication with an identity certificate.
Current Behavior
Only the common name of the subject is included in the CSR of the identity certificate. Other fields such as "organization_unit" (OU) are ommited. The subject configuration is included for the EST bootstrap identity ("bootstrap_identity"), but not for the EST device identity ("identity").
Intercepted EST network traffic (aziot-certd) for "identity_cert":
Intercepted network traffic for "bootstrap_identity"
The EST server is configured to only accept CSR that contains an "organization_unit". This results in the error:
{"errors":[{"code":"invalid_input","message":"Please provide value for subject.organization_unit"}]}
. This field is a constraint for an operational certificate by the PKI / EST server provider "DigiCert IoT Manger" (referenced in the documentation, see https://docs.microsoft.com/en-us/azure/iot-edge/tutorial-configure-est-server?view=iotedge-2020-11#est-server)Steps to Reproduce
Provide a detailed set of steps to reproduce the bug.
Context (Environment)
Configuration:
Output of
iotedge check
Click here
Device Information
Runtime Versions
iotedge version
]: 1.3.0docker version
]: 20.10.17+azure-1Logs
aziot-edged logs
Additional Information
Please provide any additional information that may be helpful in understanding the issue.
The text was updated successfully, but these errors were encountered: