I forgot to add one thing, and you didn't paste the whole certificate PEM so I can't check this.
Recent versions of Go won't verify the certificate unless it contains a subjectAltName; matching against only the CN is no longer supported. So if you do get your vendor to re-issue the cert, make sure it also includes a DNS SAN, if it doesn't already. It doesn't matter if it's just a string like "EEBUS"; you can specify the ServerName at connection time. On Thursday, 9 June 2022 at 17:38:04 UTC+1 Brian Candler wrote: > 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/f8f1b1ca-c2a5-40e8-b4a0-c5733b06da2fn%40googlegroups.com.
