OS - Windows 10
.net Environment - .net core 2.1
SDK - Microsoft.Azure.Devices.Client - 1.21.0
Microsoft.Azure.Devices.Provisioning.Client - 1.4.0
Microsoft.Azure.Devices.Provisioning.Transport.Amqp - 1.1.9
Microsoft.Azure.Devices.Provisioning.Transport.Http - 1.1.6
Microsoft.Azure.Devices.Provisioning.Transport.Mqtt - 1.1.8
Description of the issue
I'm trying to connect a simulated device (.net core console app) to IOT hub via azure Device Provisioning Service. This is based on x.509 cetificates (root+ intermediate certificate).
I created the enrolment group ok, then uploaded the root certificate and completed verification.
After that generated the device certificate from root certificate and tried to connect to IOT hub using sample code from below link:
https://github.com/Azure-Samples/azure-iot-samples-csharp/tree/master/provisioning/Samples/device/X509Sample
After having all setup when I tried to connect to IOT bub I'm getting below error, tried all protocol - Amqp,Http,Mqtt...
Microsoft.Azure.Devices.Provisioning.Client.ProvisioningTransportException
HResult=0x80131500
Message={"errorCode":401002,"trackingId":"408d5ad7-aa7c-45a1-b19a-e4af41ccf54b","message":"CA certificate not found.","timestampUtc":"2019-08-23T09:17:53.762099Z"}
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
Below is the input to device client along with certificate:
private static string s_idScope = "0ne00074417";
private const string GlobalDeviceEndpoint = "global.azure-devices-provisioning.net";
private static string s_certificateFileName = "simulateddevicecert.pfx";
Is there anything missing in the setup that is causing this error? Also is there any REST API exposed by azure DPS to register device? (instead of using Azure Devices/Client SDK)
As shown here,
please include the intermediate certificate as well in the certificate chain presented by the device.
The REST API docs for registering a device to DPS can be found here.
In my case error 401002 was caused by mismatched deviceId and CN field in certificate which device used to authenticate.
In my case, I used the wrong connection string.
I used the device connection string instead of the service connection string when trying to call a direct invoke method.
I'm posting this here, because this is among the first search results for the 401002 error, and there's no info on this check on the Azure doc websites.
Related
With the now deprecated azure-iot-python-skd version 1 it was possible to connect a downstream device using X.509 authentication to a transparent iotedge enabled gateway by setting the connection string like this:
HostName=<edge device hostname>;DeviceId=<device_id>;x509=true
And then set the certificates by using set_option("TrustedCerts" ...), set_option("x509certificate", ...) and set_option("x509privatekey", ...)
How can this be done with the new version 2 sdk?
I could not figure out how to do it using create_from_x509_certificate(...) or create_from_connection_string(...).
please try the following where you pass in your root_ca_cert as a string:
Create instance of the device client using the connection string:
device_client = IoTHubDeviceClient.create_from_connection_string(connection_string=YOUR CONNECTION STRING,server_verification_cert=YOUR ROOT CA AS STRING)
await device_client.connect()
create_from_connection_string will not work in this case. You need to use create_from_x509_certificate as below:-
self.device_client = IoTHubDeviceClient.create_from_x509_certificate(
x509=x509,
hostname=hostname,
device_id=device_id,
server_verification_cert=root_ca_cert,
gateway_hostname=gatewayHostname
)
Refer this ticket which is the bug fix done by MS team
We're struggling to get IBM MQ to work across SSL.
We've been provided with the certificate chain for the remote host and installed into the Windows Certificate Store (Local Machine). These all look valid.
We're using the following connection properties:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "other-server.com");
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256"); connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*SYSTEM");
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmywindowsusernamewithoutdomain");
MQEnvironment.SSLCertRevocationCheck = true;
We've established that the "CertificateLabel" is the "Friendly name" in Windows parlance.
We've proven unencrypted communication and network-level configuration.
We're using 8.0.0.7 client.
These are the issues we've come across:
All secure communications fail with a 2538 error. (MQRC_HOST_NOT_AVAILABLE, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q045380_.htm)
No success setting the Friendly Name to ibmwebspheremq and ibmwebspheremqmywindowsusername#domain and ibmwebspheremqmywindowsusernamewithoutdomain
General questions:
Are we correct in assuming that we can install generated certificates exclusively in the Windows Certificate Store?
Is the 2538 error even related to SSL communications? It feels like a network error, though there is that final point in the referenced error documentation.
Is there anywhere we can look for more informative error information? eg. relating to the SSL trust chain to see if there is an issue there?
The issue was the following line:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "otherserver.com");
Turns out that:
It needs it in a canonical format, so DN=, etc.
You don't even need that line
Though we did learn a few things along the way:
The line:
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmyusername");
Is the string ibmwebspheremq plus your Windows username (without your domain) and the label should be set on the Friendly name of your client machine's outgoing certificate NOT including the username.
The various folders inside your Windows certificate store are significant. The intermediate CAs should be correctly filed.
We are developing an hybrid application ( Android , iOS )
and we are facing an issue communicating with our backend services.
We are using untrusted certificate in the development environment and this lead to an error invoking the services using WLResourceRequest in the hybrid code.
The error on the android platform is the following:
java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
And reading from android logcat comes out this:
04-20 12:50:04.300 9427-9450/com.myApp D/wl.resource_request: WLResourceRequest.handleOnFailure in WLResourceRequest.java:658 :: Unexpected errorCode occurred. Please try again.
04-20 12:50:04.308 9427-9450/com.myApp D/com.worklight.androidgap.plugin.WLResourceRequestPlugin: WLResourceRequestPlugin$1$1.onFailure in WLResourceRequestPlugin.java:92 :: inside WLResourceRequestPlugin failure
How can we manage to pass through the certificate validation? or is there something we can do to properly invoke the services?
You can overcome this by adding the CA certificate to your device.
Go to Settings -> Security -> Install from SD card and install the CA certificate to the device.
I have come across what I think is a bug preventing me from loading an X509Certificate2 on Ubuntu or the Debian-based docker image provided by Microsoft. This means that I can't initialise JwtAuthentication in my web API on these platforms, and I'm looking for help:
Are you successfully using JwtAuthentication on Linux?
If so, how are you initialising an X509Certificate for the JwtBearerOptions?
Can you see a problem with what I'm doing, or suggest a work-around or solution?
I have logged the issue with the corefx team and you can see the full discussion here, but below is the main description of the problem:
I have a Web API running in a docker container. The container is built from the provided 1.1.0 package:
FROM microsoft/aspnetcore:1.1.0
and the Web API binaries are copied in. The API runs fine and returns data as expected until I turn on authentication, at which point it needs an X509SecurityKey to set the TokenValidationParameters.IssuerSigningKey value. It throws an exception when it attempts to initialise an X509Certificate2 from a string value:
string certValue = certificate.Value;
byte[] byteCert = Encoding.ASCII.GetBytes(certValue);
return new X509Certificate2(byteCert);
throws an OpenSslCryptographicException:
Unhandled Exception: System.Exception: Failed to extract the Token Signing certificate from the Federation metadata. --->
Interop+Crypto+OpenSslCryptographicException: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
at Internal.Cryptography.Pal.CertificatePal.FromBlob(Byte[] rawData, String password, X509KeyStorageFlags keyStorageFlags)
at System.Security.Cryptography.X509Certificates.X509Certificate..ctor(Byte[] data)
at Mercury.Shared.Rest.Authentication.AdfsFederationMetadata.GetSigningCertificate()
The string value from which the X509Certificate2 is being initialised is:
MIIC4jCCAcqgAwIBAgIQHWt3kGySgJxPtsalC0EoKzANBgkqhkiG9w0BAQsFADAtMSswKQYDVQQDEyJBREZTIFNpZ25pbmcgLSBzdHMuYWxsYW5ncmF5LmNvLnphMB4XDTE2MDkwNzA5MDQyM1oXDTE3MDkwNzA5MDQyM1owLTErMCkGA1UEAxMiQURGUyBTaWduaW5nIC0gc3RzLmFsbGFuZ3JheS5jby56YTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANdq9BEuBRPsTdpngeFyXbfH5lBg5WyENQW0qz2FtDw3AvZhiPdFyvTPZIeZDc4vhg+gPuG8pCxhFa6hPqNIwnLSVuyhUi4/CtZrLghF2wVVcyriijvirzdVp2m56nO31NB5HXbSerTmey1gJsgumr+MiaM2CEI9z5ctwAp66jqM9jVv7kzqIwB33irSck+X97jUa9XVa0/0QPBdrSVUR0i4rmfZ9orRdTKC3IA13bD9duk2Kc9V7t8t/woo80Kbbb3ZseYk5N8AI+7RRw9+oSAm8zZQzBYkNkAMeI1mto1faXsm9Aea4HXbyCbvVOx/JGj5Ki7YK/BtzWAyCgRu0TkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAd9rdJ1V9te8njMHiEuvr1DLVUBt2YdpZ8qGFC2rWDKeEW8iARrMfbtrlQovvE1radxoZ2gWR1AaaoEqzmLvF9fEAZ7xjR2P2UlT+ZgntfMn/c+3j7gWnfGNHIjosaYiyF72q4k6bgOx1TV8X08kD2AMBH27utXeeUQTZTd0bUWaWpr76NrDB95k4P6d0t5bkYsguiQjV+2t5/dSvrbTPVbXQmWGyC53IS2OI37AI2bIaeCCDkRHDoxu+L/DtgH8N60k2CLfa+pf0/cxQCR39p4Z+tquVKfYgJIsdZLD6bbrqK9VdpSR2vyUcDLMTGnO0tuDuzBd/xdhJ0GKbnBv3+g==
The same code runs with no problem on Windows, building a certificate from the same string.
Edit: Note that while I initially encountered this problem running a docker image, subsequent testing has shown that it also occurs using Ubuntu 14.04 + .NET Core 1.1
The problem here is that what is being passed to the constructor are the bytes of the base64 representation of the key, and not the bytes of the key itself.
If this code works on Windows then maybe it's a good idea to create an issue in the .net core github referencing this problem.
Thanks for the answer. For those who would like to copy and paste:
var certificateWithoutHeaderAndFooter = certificateString
.Replace("\\n","")
.Replace("-----BEGIN CERTIFICATE-----", "")
.Replace("-----END CERTIFICATE-----", "");
var certificateBytes = Convert.FromBase64String(certificateWithoutHeaderAndFooter);
var certificate = new X509Certificate2(certificateBase64Bytes);
Worklight 6.0.0, targeting iPad.
I have a simple demonstration application, no authentication at present. I am demonstrating use of reverse proxy. So I am building my application using the Build for Remote Server workaround and can see in xcode the correct server specification. I have some adapter calls, but for a particular demo scenario I also want to make an explicit call to
WL.Client.connect( ... );
If I use an http connection I see a request like this:
http://192.168.0.19/MyApp/apps/services/api/Work01/ipad/init
and it works just fine. If instead I use an SSL connection, as expected I see this
https://192.168.0.19:443/Infrabel01/apps/services/api/Work01/ipad/init
And I get the following error.
> [ERROR ] FWLSE0059E: Login into realm 'NullLoginModule' failed. The
> environment 'ipad' supports multiple versions, therefore you must
> request it with a version parameter.. [project Infrabel01] The
> environment 'ipad' supports multiple versions, therefore you must
> request it with a version parameter. [ERROR ]
> FWLSE0117E: Error code: 4, error description: AUTHENTICATION_ERROR,
> error message: An Error occurred while performing authentication using loginModule
> NullLoginModule, User Identity Not available. [project Infrabel01]
> [project Infrabel01]
That "request it with a version parameter" is intriguing. Is there some extra parameter I need to pass? Or is the overall implication that connecting over SSL requires authentication?
I had the same problem.
I have solved it by using the real IP address of the server in the WL app instead of using localhost:
When the emulator is running your app, press the Menu button.
Select to change your server URL
Remove "localhost" and use the IP address.
Accept and try again.
This fixed my problem.
Please make sure your Worklight server or proxy server is enabled SSL with certificate which signed by a trust public CA like Verisign. Worklight not support private CA certificate.