[jira] [Resolved] (THRIFT-6275) Go cross-test client presents no client certificate, and Go 1.27 cannot load client_v3.crt

["Jens Geyer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/THRIFT-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jens Geyer resolved THRIFT-6275.
--------------------------------
    Fix Version/s: 0.26.0
         Assignee: Sylwester Lachiewicz
       Resolution: Fixed

> Go cross-test client presents no client certificate, and Go 1.27 cannot load client_v3.crt
> ------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-6275
>                 URL: https://issues.apache.org/jira/browse/THRIFT-6275
>             Project: Thrift
>          Issue Type: Bug
>          Components: Go - Library, Test Suite
>            Reporter: Sylwester Lachiewicz
>            Assignee: Sylwester Lachiewicz
>            Priority: Major
>             Fix For: 0.26.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Every {{py-go_*-ip-ssl}} row of the cross-test matrix, 18 in all, has been listed in [test/known_failures_Linux.json|https://github.com/apache/thrift/blob/master/test/known_failures_Linux.json] since THRIFT-847 in 2015. Re-running them on a fork branch with the entries removed shows two defects on the Go client side: one that causes the failures, and one that a fix for the first exposes on Go 1.27.
> h2. 1. The Go cross-test client presents no client certificate
> The TLS configuration in [test/go/src/common/client.go|https://github.com/apache/thrift/blob/master/test/go/src/common/client.go#L46] sets only {{InsecureSkipVerify}}. The Python test server requires a client certificate ([test/py/TestServer.py:390|https://github.com/apache/thrift/blob/master/test/py/TestServer.py#L390], {{cert_reqs=CERT_REQUIRED}}), so every socket transport over SSL fails at the handshake:
> {noformat}
> Unexpected error in TestVoid() call: remote error: tls: certificate required
> {noformat}
> The http-ip-ssl rows pass only because the Python HTTP server does not ask for one, and rb-go passes because the Ruby server uses {{VERIFY_PEER}} without failing on an absent certificate. Every other cross-test client that presents a certificate sends {{client_v3.crt}}.
> h2. 2. Go 1.27 and later cannot load client_v3.crt
> {{test/keys/client_v3.crt}} lists the alternative names 127.0.0.1, ::1, ::ffff:127.0.0.1 and localhost. Since go1.27.0 Go's x509 parser rejects any certificate carrying an IPv4-mapped IPv6 address as a SAN, and the TLS client will not send a certificate it cannot parse:
> {noformat}
> x509: SAN iPAddress contains IPv4-mapped IPv6 address
> {noformat}
> Reproduced with Go 1.27.1; Go 1.24.3 and 1.26.2 load the certificate. The cross-test image builds with Go 1.24.3, so this does not cause the known failures, but the lib-go job runs on 1.26 and 1.27 and test/go loads the certificate once the client presents it. THRIFT-3660 added that entry in 2016 so the Python server's peer-address check would match a dual-stack peer. Since THRIFT-6201 the Python matcher reduces {{::ffff:127.0.0.1}} to {{127.0.0.1}} before comparing, so the entry is redundant.
> A related documentation defect: the recipe in [test/keys/README.md|https://github.com/apache/thrift/blob/master/test/keys/README.md] says to sign {{client_v3.crt}} with {{CA.pem}} and {{server.key}}, but the certificate shipped since the 2022 regeneration is self-signed with {{client_v3.key}}. A certificate made from the recipe is rejected by the Python server with {{unable to get local issuer certificate}}.
> h2. Proposed fix
> * Give the Go test client a {{--certPath}} flag like the server's and load {{client_v3.crt}} and {{client_v3.key}} into its TLS configuration when {{--ssl}} is set; pass the flag in {{test/tests.json}}.
> * Regenerate {{client_v3.crt}} self-signed with the same key, the same distinguished name and extensions, and the alternative names 127.0.0.1, ::1 and localhost. Regenerate {{lib/java/src/crossTest/resources/.clientkeystore}} from it, as the README describes.
> * Correct the README recipe to produce what is shipped.
> * Remove the 18 {{py-go_*-ip-ssl}} entries from the known failures.
> With those changes, all twelve py-go SSL combinations (binary, compact, json and header over buffered, framed and zlib) pass locally against a Python server built from master. The cross-test run behind this analysis is recorded on THRIFT-5809; THRIFT-4502 tracks the known-failures cleanup in general.
> _This issue was created with AI assistance._



--
This message was sent by Atlassian Jira
(v8.20.10#820010)