Windows build with Boost 1.83.0 and OpenSSL 3.x fails: undefined type 'asn1_string_st' in rfc2818_verification.ipp

[ihsandemir]

Summary

The nightly-Windows workflow fails to compile for the msvc-latest_boost_1830 matrix entry when OpenSSL is enabled. Build output (from nightly-Windows run):

C:\Boost\include\boost-1_83\boost\asio\ssl\impl\rfc2818_verification.ipp(85,36): error C2027:
    use of undefined type 'asn1_string_st'
    [D:\a\hazelcast-cpp-client\hazelcast-cpp-client\build\hazelcast-cpp-client.vcxproj]
    (compiling source file '../hazelcast/src/hazelcast/client/client_impl.cpp')
        C:\Program Files\OpenSSL\include\openssl\types.h(57,16):
        see declaration of 'asn1_string_st'

C:\Boost\include\boost-1_83\boost\asio\ssl\impl\rfc2818_verification.ipp(85,15): error C2660:
    'memcmp': function does not take 2 arguments
    (compiling source file '../hazelcast/src/hazelcast/client/client_impl.cpp')
        while trying to match the argument list '(_Ty *, int)'
            with [_Ty=unsigned char]

The Boost 1.90.0 matrix entry compiles fine; only Boost 1.83.0 + OpenSSL 3.x (installed via choco install openssl on the Windows runner) is affected.

Root cause

The client never references boost::asio::ssl::rfc2818_verification — it uses the modern boost::asio::ssl::host_name_verification (see hazelcast/src/hazelcast/util/util.cpp). However, three internal headers include the umbrella <boost/asio/ssl.hpp>:

• hazelcast/include/hazelcast/client/internal/socket/BaseSocket.h
• hazelcast/include/hazelcast/client/internal/socket/SSLSocket.h
• hazelcast/include/hazelcast/client/internal/socket/SocketFactory.h

In Boost 1.83.0, <boost/asio/ssl.hpp> transitively includes <boost/asio/ssl/rfc2818_verification.hpp>, which in Boost.Asio's default header-only mode pulls in rfc2818_verification.ipp. That .ipp dereferences ASN1_STRING fields directly (domain->data, domain->length). Starting with OpenSSL 3.0, ASN1_STRING is an opaque type whose layout is no longer exposed by the public headers, and MSVC refuses to compile the field accesses (hence the C2027; the C2660 is a follow-on because domain->data collapses to a non-pointer expression, making memcmp(domain->data, ...) look like a two-argument call).

GCC/Clang on Linux/macOS happen to accept the opaque-struct dereference more permissively in this code path, which is why only the Windows + MSVC + OpenSSL 3.x combination breaks.

Upstream Boost removed rfc2818_verification from the umbrella <boost/asio/ssl.hpp> after 1.83.0 (it is no longer present in 1.90.0), so the Boost 1.90.0 matrix entry is unaffected.

Reproduction

1. Run the nightly-Windows workflow (.github/workflows/nightly-windows.yml).
2. Any matrix entry with boost_folder_name: boost_1_83_0 and with_openssl.toggle: ON reproduces the failure when MSVC compiles a translation unit that transitively includes <boost/asio/ssl.hpp> (e.g. client_impl.cpp via ClientConnectionManagerImpl.h -> SocketFactory.h).

Proposed fix

Replace the umbrella include with the specific subheaders the codebase actually uses (context.hpp, error.hpp, host_name_verification.hpp, stream.hpp) in the three internal headers above. This is the same approach already used in hazelcast/src/hazelcast/util/util.cpp. It avoids dragging in rfc2818_verification.hpp entirely and restores the Boost 1.83.0 + OpenSSL 3.x Windows build without affecting any other matrix entry.

Tracking: HZ-5424