0

I've been developing an embedded system with wolfSSL inside. I have a test program to verify the wolfSSL. I used 'openurl https://www.microchip.com/' to test wolfSSL against the xxx company page.

I tried several other web pages other than www.microchip.com, but the result is the same.

Then I found the server rejected 'Client Hello' with 'handshake failure' (with error code = 40). My question is how I can know the cause of why the server rejected the connection negotiation. How can I know what I could miss before the rejection?

My test program is from Microchip's git hub: "https://github.com/Microchip-MPLAB-Harmony/net_apps_pic32mz/blob/master/docs/GUID-EAFAC274-BD06-4CB8-8797-15A853587DD8.md" and it's supposed to be trustable.

Stan Huang at Taiwan
  • 477
  • 1
  • 5
  • 16
  • 1
    There is no easy step by step instruction of how to solve such problems since the cause of the problem can vary a lot. Its basically a mismatch of what the client does and what the server expects from the client: client certificates, supported ciphers, signature algorithms, extensions (like SNI), protocol version .... If you have access to the server check there for log messages indicating problems. If not provide a packet capture (as pcap, not screenshot) so that one can analyze what the client does and compare it to what the server expects (which is hopefully public so that one can check). – Steffen Ullrich Aug 31 '22 at 15:59
  • It's said 'wrong time' is the most possible reason why the server rejects to continue the negotiation dialog. Now, I just confirmed the device's system time is consistent with my PC, which in turn consistent with the world time. So, the 'wrong time' cause can be excluded. The simple browser is from Microchip's git hub. It can be believed the code correctness. So, the problem is what's the possible cause other than the above two ones. – Stan Huang at Taiwan Sep 01 '22 at 05:55
  • 1
    *"It's said 'wrong time' is the most possible reason why the server rejects to continue the negotiation dialog."* - no idea where this is said but I doubt it. Wrong time of the client is a common reason for the client to fail in the verification of the servers certificate (i.e. certificate deemed expired or not valid), but I've never saw it as a reason for the server to reject the client (apart from validation of client certificates - if the server time is wrong). And outside of certificate validation the time is irrelevant in TLS. – Steffen Ullrich Sep 01 '22 at 06:08
  • I just confirmed the system time is right at my device from its console. The system greeting message contains its current time. I found it's the same as my PC's time,which is consistent with the world time too. So, the most possible cause, 'wrong time', can be excluded now. – Stan Huang at Taiwan Sep 01 '22 at 10:09
  • 1
    *"So, the most possible cause, 'wrong time', can be excluded now. "* - Like I already said, wrong time is not the most possible cause for server triggered handshake failure. No idea where you've read that, but it likely wasn't about the handshake failure alert coming from the server (as you've written in your question) but instead just about a failed handshake due to certificate validation problems on the client side. – Steffen Ullrich Sep 01 '22 at 10:41

0 Answers0