On Thursday, June 9, 2022 at 6:44:58 PM UTC+2 Brian Candler wrote: > 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. >
I am aware of the rejection of SHA1 hashes, but not this change. Could you kindly share the CL or release note? Much appreciated! 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 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/2722a14e-8d26-415a-affe-c403f47f270cn%40googlegroups.com.
