We are creating an application where ThreadX based client would be communicating with IOT Hub. Made appropriate adapter changes to make client work with IOT Azure C SDK. We observe "Bad Certificate" error thrown by client on wire shark error. From wireshark we are certain that client sends "Hello" on which Server (IOT Hub) responds "Server Hello, Certificate, Certificate Request, Server Hello Done". It is here when client tries authenticate server certificate we see "Bad Certificate" being thrown. We are attaching in mail the root certificate we are adding to client and the wireshark we see stating bad certificate.
This is not about the Azure C SDK support for ThreadX.
If you are certain from Wireshark that the steps till Server Hello Done are successfully completed, most probably this is an issue with certificate formatting, may be missing escape character at the end of each line in certificate etc.
You can try using the Certificate fingerprint instead to see if it works.
Related
I'm know working on establishing a connection to an Azure test IOT hub but using a SAS token and not a device certificate as mentioned here in the Azure certificates change
I was using this function from LwIP stack to make a tls config using my device certifcate
altcp_tls_create_config_client_2wayauth
and
mqtt_client_connect
to connect to the server
What I need to know is:
Should I use another altcp_tls function to connect using a SAS token?
How can I check that the TLS handshake is done? because this is what I need to know
I appreciate any help
I tried to use the connection string from the article as a client password in MQTT client parameters, but I don't know if the TLS handshake is done or not
I have an App Service that's protected by a TLS certificate. It worked fine with small payloads, however, it started failing with larger payloads.
According to an article, I enabled certificate negotiation for my API Management Service:
https://notetoself.tech/2019/06/13/api-call-with-client-certificate-policy-failing-to-execute-due-to-message-size-on-azure-api-management/
However, it still randomly fails with certificate negotiation error, as seen below:
Important - I do not want to use client authentication between browser <-> API management. I'm using it only between API management <-> App Service.
I could not find any information on this substatus 72 code. What does it mean and can it be fixed? Is Azure client certificate authentication broken and won't work with large payloads?
The Negotiate Client Certificate checkbox will not help here as this is for the mutual auth between the client and your apim service where your problem is between apim and app service. Your app service should force apim to exchange the client certificate during the initial SSL handshake rather than waiting until it is needed.
This problem is not related specifically to azure, see this
https://techcommunity.microsoft.com/t5/networking-blog/https-client-certificate-request-freezes-when-the-server-is/ba-p/339672
The issue description to me or at least to how I understood it does not match with the error code as the 17 substatus code means that the client certificate has expired or is not yet valid.
See this https://www.google.com/search?q=403.17+http+code&oq=403.17+http+code&aqs=chrome..69i57.9265j0j7&client=ms-android-samsung-gn-rev1&sourceid=chrome-mobile&ie=UTF-8
And this https://techcommunity.microsoft.com/t5/iis-support-blog/client-certificate-revisited-how-to-troubleshoot-client/ba-p/348053
For testing purposes I would like to enable the 'Incoming Client Certificates' option in my Azure App Service (running a WCF webservice), and see if my Client application can still connect to the webservice. Since I am still in a testing phase, my app service still has the .azurewebsites.net domain name.
However, I can't seem to figure out how to get a proper client certificate that the server will accept (without switching to a custom domain name, which I know will work).
Currently, I see 2 possible routes to a solution:
Somehow get my hands on .cer that is signed by a CA trusted by the App Service server.
Generate a self-signed .pfx and .cer with my own self-signed CA. Import the pfx on the App Service and install the .cer on the client.
Both directions have not yielded any success so far. Does anyone have any experience with this?
Per my understanding, the client certificate is used by client systems to make authenticated requests to a remote server. In this case, your webservice is the remote server in a C/S mode. As you point out, "validating this certificate is the responsibility of the web app. So this means that any certificate will be valid as long as you don't validate anything". It does not effect on whether you have a custom domain or not in your web app service.
If you want to use client cert authentication with Azure app, you can refer to How To Configure TLS Mutual Authentication for Web App.
If the server has requested client certificate in its server hello and the client cert has signing capability, then it is expected to send the CertificateVerify message to the server. It contains signed hash of all messages from Client Hello till that point which are buffered on the server side. The server TLS layer will decrypt this using the client public key (which is in the Client certificate received earlier) and compare with its calculated hash. It will call back to application layer if this fails.
The application needs to handle it at that point and return its own error or continue with the session. https://www.rfc-editor.org/rfc/rfc5246#section-7.4.8
One example of this with Wolfssl library is https://github.com/wolfSSL/wolfssl/blob/14ef517b6113033c5fc7506a9da100e5e341bfd4/wrapper/CSharp/wolfSSL-Example-IOCallbacks/wolfSSL-Example-IOCallbacks.cs#L145
We use Azure Service Bus and Azure Web App which fills queue. They are in the same resource group. We use WindowsAzure.ServiceBus v2.6.5.
We get this error very rarely:
The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.
Question: Is this internal error on Azure ? If it's not, what can we do to not get this error ?
I managed to find our more information about this issue. First of all,
what needs to be established is that this is a pure client issue, this
is why there are no tracking IDs. The client refuses to complete the
TLS handshake with Service Bus.
This is a known issue this is a known issue with the way how Microsoft
manages certificates and how they are used on non-HTTP(S) transports.
The errors occur when the endpoint that hosts the intermediate
certificates for Microsoft is unavailable or slow or cannot be reached
by the client for any reason. We are investigating a workaround for
injecting the required extra certificate into the TLS handshake for
the SBMP and AMQP transports similar to how this is done by HTTP.SYS,
so that this extra request is not needed.
The immediate workaround available is to enable
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Https
This will force all traffic to use a WebSockets tunnel that is
protected by a prior TLS/HTTPS handshake, and that handshake carries
the required intermediate certificate. The WebSockets handshake does
impose a little extra latency as the connection is established, but
will otherwise be comparable with the regular communication mode. The
messaging protocol used through that tunnel will still be AMQP or
NetMessaging, so you should not be worried to get HTTP characteristics
when choosing this option.
This is the response from Microsoft. I'll apply this and if I don't face any problem at some period time, I will accept this as an answer. Who faces this problem, they can try this also.
Edit:
ConnectivityMode.Https is just in avaliable service bus 3. I have to use servicebus 2 because of issue on Signalr. Therefore I couldn't apply this solution.
I believe there must be a missing certificate.
From this stack overflow post https://stackoverflow.com/a/24224550/4735373 here is a link that may help: https://corp.sts.microsoft.com/Onboard/ADFSOnboard.htm#Corp-STS-Certificates
I'm trying to add a .pfx certificate to Websphere8 server to establish a connection to an IIS server.
I tried to add the certificate to the deaultkeystore as a personal certificate and added the same as a signing certificate to the defaulttrustkeystore.
When ever I send a request through my application I'm getting a 401 unauthorized error.
I checked the communication b/w servers using Wireshark but there is no FINISHED message from either client or server.
So I wan't to know exact procedure to install a certificate on websphere server to get authenticated and thereby send the XML as a part of HTTPS Post request.
I contacted the web service provider, he said me that other users, or people who already implemented the client for this service, convert the pfx to .cer and send it along with the request. I also want to know how that is possible. I'm coding using Java 6.
Thanks for the help.