Bare with me on this, as I explain where I'm coming from and where I'm trying to go.
We've integrated Go into our code base as a separate service that communicates with some server code through TLS. For the most part, this worked flawlessly through Go 1.10. We were affected by some of the Go 1.11 changes that deprecated <https://tip.golang.org/doc/go1.11#crypto/x509> the use of the common name as a non-host name. x509: Common Name is not a valid hostname: ... > As a result, we've been restricted to 1.10 although we've made some steps to try to get up to the most recent level. Recently, we decided to migrate our Go service's certificate to a new, standardized certificate that will be accepted by Go 1.11's TLS certificate validation that removes the deprecated use of the CN. This certificate is generated by our server code. We've hit a snag in terms of creating a migration path for our customers on existing server instances. As some context, the migration path is not quite simple as we are likely to have our legacy self-signed certificate deployed to hundreds if not thousand of non-Go clients. So although we have a new certificate, it's a difficult play to ask our customers to migrate to a new self-signed certificate without pulling teeth. One idea on the table is to utilize an extension from the TLS RFC 6066 standard detailed here <https://tools.ietf.org/html/rfc6066#page-12> and basically allow the server to manage multiple certificates. That would allow our old clients to continue using legacy certificates and also provide a migration path for new Go clients. Is that implemented in Go or are there any plans to? Are there any alternatives you can think of given the scenario above? We're trying to _avoid_ writing any custom validation logic on the Go client as encouraged here <https://github.com/golang/go/issues/24151#issuecomment-410038558>. We could also possibly use SNI although it seems like we'd be overloading the use of this field. Thanks! -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
