1
votes

I'm playing with Azure IOT Hub/Edge and Python on a Linux client device. I have modified the iothub_client_sample_x509.py sample program from the SDK to use arbitrary X509 certificates (actually created with OpenSSL) to connect to IoT Hub. The device certificates are part of a CA structure with two layers of certificate chain on top (i.e. a two-tier CA).

Connection establishment works fine as long as I register the device on IoT Hub as 'X.509 Self-Signed' with the SHA1 fingerprint of the device cert as the primary/secondary fingerprint. When I try, however, to connect in 'X.509 CA-Signed' mode, I fail with 'Connection Not Accepted: 0x5: Not Authorized' (in the latter case, I registered the device on IoT Hub as 'X.509 CA-Signed'). The chain (CA) certificate files were uploaded under 'Certificates' in IoT Hub with status 'Verified'.

In both cases, I use a connection string like this: "HostName=<host name with full DNS name>;DeviceId=<device ID>;x509=true".

Is this the correct connection string for the 'X.509 CA-Signed' case? Do I need to transmit the certificate chain (in addition to the device cert) when I connect? How would I do that? The Common Name in the device certificates reads 'CN = <device ID>.westeurope.cloudapp.azure.com', and not 'CN = <device ID>.azure-devices.net'. Could that be a problem?

Please note that I cannot easily set up C#/.NET on the client devices for testing, so I'd like to stick with Python (or maybe C) for now. Is there any chance to activate some more granular logging to understand why connection establishment fails with '0x5: Not Authorized'? Anything else I may have missed?

Thanks for any help, Michael

Update 2018-05-16: Hi Michael, thanks for your comments. Indeed, I have been able to make connection establishment work in 'X.509 CA-Signed' mode by setting up the certificates with the MS PowerShell scripts (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-security-x509-create-certificates). Correcting the CN to the device name only did not fix the problem with my original PKI setup, though. Guess I will have to analyze every little difference in the PKI setups.

Two obvious differences in the PKI setups are:

  1. My setup uses a two-tier PKI (one root CA and one intermediate/signing CA) rather than one CA only. The certificates of both are stored in IoTHub (verified).

  2. Root CA and Signing CA have 384 bit keys (ECC - secp384r1 curve) rather than 256 bit (prime256v1 curve). Both CA certs could be stored and verified without any problems in IOTHub.

Are any of these differences known to cause problems?

Thanks, Michael

2

2 Answers

1
votes

Setting the CN to the device name was only one part of the solution. In addition, I had to correct a subtle error in my root CA certificate. It contained:

    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE, pathlen:0

'pathlen:0' means that this CA would not allow any subsequent, intermediate CA below itself. And - remember my PKI setup - there is an intermediate CA that would eventually issue the device certificates. Setting pathlen to 1 in the root CA certificate fixed the problem. Apparently, IoTHub performs a very thorough validation of the certificate chain.

Ironically, simply deleting the root CA certificate in the Certificates section of IoTHub also fixes the problem. Although the certificate chain is no more complete then (the signer of the intermediate CA is missing), IoTHub approves the certificate chain during connection establishment. Maybe this is because the intermediate CA certificate is in state 'verified' in IoTHub.

0
votes

Even though you have not provided the detailed steps about how to generate the x509 certificate for the device, i encountered the similar issue long time ago.Please try to change the Common Name(CN) as the device name that created in Azure Portal(IoTHub->IoT Devices). If the error still can not be solved, please feel free and let me know.