Skip to content
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

GetFileUploadSasUriAsync throws NullReferenceException when using CA signed certificates to authenticate the device #1527

Closed
Perun85 opened this issue Aug 19, 2020 · 10 comments
Assignees
Labels
bug Something isn't working. fix-checked-in Fix checked into main or preview, but not yet released. IoTSDK Tracks all IoT SDK issues across the board

Comments

@Perun85
Copy link

Perun85 commented Aug 19, 2020

  • OS, version, SKU and CPU architecture used: Windows 10 Enterprise 2016 LTSB
  • Application's .NET Target Framework : netcoreapp3.0; netcoreapp3.1
  • Device: Laptop
  • SDK version used: 1.27.0; 1.29.1-preview-002

When CA signed certificates are used to authenticate the device, method GetFileUploadSasUriAsync throws NullReferenceException.

StackTrace

at Microsoft.Azure.Devices.Client.IotHubConnectionString.Microsoft.Azure.Devices.Client.IAuthorizationProvider.GetPasswordAsync() at Microsoft.Azure.Devices.Client.Transport.HttpClientHelper.<ExecuteAsync>d__21.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Azure.Devices.Client.Transport.HttpClientHelper.<PostAsync>d__172.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult() at Microsoft.Azure.Devices.Client.Transport.HttpTransportHandler.<GetFileUploadSasUri>d__15.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.ConfiguredTaskAwaitable1.ConfiguredTaskAwaiter.GetResult()
at Microsoft.Azure.Devices.Client.InternalClient.d__77.MoveNext()
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter1.GetResult()

@Perun85 Perun85 added the bug Something isn't working. label Aug 19, 2020
@github-actions github-actions bot added the IoTSDK Tracks all IoT SDK issues across the board label Aug 19, 2020
@abhipsaMisra
Copy link
Member

Do you have the corresponding CA certs uploaded to your hub instance?

@azabbasi azabbasi self-assigned this Aug 19, 2020
@Perun85
Copy link
Author

Perun85 commented Aug 19, 2020

Yes, I do. I am able to connect to IoTHub and perform other operations except retrieving SAS URI for file upload.

@azabbasi
Copy link
Contributor

We can repo this issue in the SDK. Working on a fix now.

@azabbasi
Copy link
Contributor

We have checked in the fix for this issue, we will be releasing a new version of the Device SDK soon.
Is there a specific reason you are using the preview version? (ex: Device streaming APIs) if not, we recommend using the GA version of the SDK as it will get the updates sooner than the preview SDK.

@Perun85
Copy link
Author

Perun85 commented Aug 25, 2020

Thank you for the info.
Yes, there is. We have features that are based on device streaming API.
I will build client from latest master just to confirm that we can SAS URI API with our flow.

@Perun85
Copy link
Author

Perun85 commented Aug 25, 2020

I have just tested it with version built from current master, and it works.

There is one more thing. Client internally uses HTTPS to obtain the token, even though primary connection uses AMQP. Would it possible that entire communication is done over primary protocol?
I ask this because we have complex CA hierarchy. AMQP and MQTT protocols do not require from us to register all intermediate certificates (We have around 1000 of them and number is growing and IoTHub has limit of 20 certificates in total). On other hand HTTPS requires entire certificate chain.

@azabbasi
Copy link
Contributor

Thanks for letting us know, We will bring these changes to the preview and release a new version shortly.

Yes, the only available protocol for the file upload APIs on the IoTHub service is HTTP, so regardless of the protocol you indicate when you are instantiating the DeviceClient, we will open an HTTP client.

One option would be for you to use SAS token credentials but since you are using certificates and those are generally preferred over SAS tokens, I am not sure that is the path you want to explore right?

The certificate limit is imposed by the service and Andrei ( @ailn ) might be able to provide guidance on what is recommended here.

@azabbasi azabbasi added the fix-checked-in Fix checked into main or preview, but not yet released. label Aug 25, 2020
@azabbasi
Copy link
Contributor

@Perun85
Copy link
Author

Perun85 commented Sep 22, 2020

Thank you for the info.

@az-iot-builder-01
Copy link
Contributor

@abhipsaMisra, @Perun85, @azabbasi, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working. fix-checked-in Fix checked into main or preview, but not yet released. IoTSDK Tracks all IoT SDK issues across the board
Projects
None yet
Development

No branches or pull requests

4 participants