Open kensykora opened 2 years ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @Azure/azure-iot-cli-triage.
Author: | kensykora |
---|---|
Assignees: | - |
Labels: | `Service Attention`, `customer-reported`, `IoTDPS`, `IoT`, `IoT/CLI` |
Milestone: | - |
route to service team
@kensykora Thanks for bringing this to our attention - I'm taking a look now.
It looks like the issue is coming from us decoding the certificate
property in the response from generating the verification code. The newest DPS SDK we added in this release added this property to the generate-verification-code
response, but it is returned in a format that we need to decode in order to display correctly in JSON output.
I've tried a few certs I've used for testing on my own DPS without issue, so I'm guessing there's a difference in the formatting of your certificate body's encoding / formatting in the service response.
Could you provide the steps used to generate this intermediate cert to see if we can get a repro? Is the certificate body that was uploaded in a base64-encoded format? .PEM or .CER?
The intermediate cert itself was generated with OpenSSL and uploaded to Key Vault. It is the third certificate in a chain that originates from a self-signed cert. I don't know what format it was uploaded in originally, but I'm not sure if it matters because I'd assume Key Vault converts into the same format when you export it.
I automate pulling the cert from key vault to upload to DPS. Terraform is used to download the certificate. (we use the terraform data "azurerm_key_vault_certificate"
which exposes the certificate as certificate_data_base64
property) I'm not really clear on if this format is .cer or .pem. If I had to guess it's whatever the KeyVault API sends as REST for public certificate content. I don't really care as long as DPS accepts the certificate (which it does)
From the key vault base64 data, I pipe that base64 content to another terraform resource "azurerm_iothub_dps_certificate"
with its certificate_content
property.
I'd have to dig into the terraform azurerm provider source to get you any more detail than that.
Because the terraform azurerm provider doesn't have the capability to verify the cert, I use an az CLI workaround in a terraform local_exec
provisioner to complete the verification step, which is where this bug surfaced.
I can provide you the public portion of the cert if you can provide me with a secure way to send it to you. But perhaps the key vault export to DPS import scenario I described can give you the information you need on the formatting question or to reproduce it.
I'm happy to provide any specific debug output with my specific scenario as well (raw REST response from az cli perhaps, just let me know)
Describe the bug
As of 2.28 (does not occur in 2.27 or earlier) the command to generate a verification code for a DPS certificate fails with this error.
Command Name
az iot dps certificate generate-verification-code
Errors:
To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.
ETAG=$(az iot dps certificate show -o json --query etag -n intermediate-cert --dps-name my-dps -g my-rg)
az iot dps certificate generate-verification-code --n intermediate-cert --dps-name my-dps -g my-rg -e $ETAG
Expected Behavior
Verification code is returned
Environment Summary
Workaround
Option 1: Downgrade to azure-cli 2.27 or earlier.
Option 2: Use
az rest
Additional Context
The call to retrieve the certificate verification code is successful. However, the CLI tool fails to process it correctly. Here's the relevant debug output: