On Thursday, 9 June 2022 at 14:27:04 UTC+1 cpu...@gmail.com wrote: > We receive an alert 40 (Handshake failure ) when using openssl. So the > cert is definitively faulty in some way. > > :~/wallbox/hack$ openssl s_client -connect 192.168.1.180:4712 > Certainly it will report a failed verification, but s_client should continue (i.e. allow you to send and receive data), if the TLS connection was established. That is: it won't drop the connection on the floor unless you've specified "-verify_return_error"
Have you tried adding "-servername EEBUS" and/or "-verify 0" to the command line? And/or "-CAFile <path_to_file.pem>" where this file contains a copy of the (self-signed) certificate itself. Seems that in this case- if we regard openssl as "the standard" it's > obsolete to talk about Go. > Go doesn't use openssl internally. I was only trying to establish whether this vendor has *any* claim of their implementation interoperating with any sort of TLS client. If openssl won't talk to it, then you can pretty much argue they're not talking TLS at all. However if openssl s_client does talk to it, then you have another workaround: you could exec.Cmd <https://pkg.go.dev/os/exec> an instance of openssl s_client, and pipe data to and from it. But really I would question the wisdom of dealing with any vendor who (a) doesn't follow standards for certificates, and (b) will not allow you to replace the device certificate, or won't replace it themselves, when given direct evidence of its brokenness and non-compliance to standards. How exactly do you think this vendor will respond when you find a more serious security violation, or some other failing in their product? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/91fd5d77-a7af-4298-9cc0-7b97a7c4eae2n%40googlegroups.com.
