IXWebSocket wss c++ client cannot connect to Node.js wss server using an ip address
Michael Wojcik
Michael.Wojcik at microfocus.com
Mon Feb 20 20:12:12 UTC 2023
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
> Viktor Dukhovni
> Sent: Monday, 20 February, 2023 11:54
>
> On Mon, Feb 20, 2023 at 01:31:07PM -0500, Pierre-Luc Boily wrote:
>
> > My compiler doesn't like the following defines :
> > "X509_CHECK_FLAG_NEVER_CHECK_SUBJECT" and
> > "X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS". When I add the include
> file
> > "x509v3.h", the compiler now complains about line 181 in x509v3.h,
> > which is probably because he doesn't know what is "X509_NAME".
> >
> > My compiler version is visual studio 2017 and I use OpenSSL (compiled
> > under visual studio 2017 as well)
It's not an issue with the compiler; it's an issue with Microsoft's rat's-nest of headers in the Windows SDK.
> >
> > Should I ask this question under the dev mailing list instead?
No, that list is for OpenSSL development. This is the correct list.
> To use these macros, it suffices to include the requisite header. If your
> compiler is unhappy, that's between you and your compiler. The
> <openssl/x509v3.h> header includes the headers it needs.
The problem here is that neither Microsoft nor OpenSSL are careful with their use of the C namespaces (preprocessor, tag, and typedef), and consequently there are collisions. This is compounded by Microsoft's belief that it's fine to let one common header (windows.h) drag in everything under the sun.
You'd have the same issue with any compiler, if you're using the Windows SDK.
Of course this is a common issue with C APIs, which rarely attempt to avoid namespace collisions. (That's the main motive behind the namespace mechanism in C++.)
Anyway, as the page Viktor linked to suggests, the problem is often the X509_NAME macro in wincrypt.h, which gets included by windows.h by default (and by a bunch of other Microsoft headers, often incorrectly).
You can try these workarounds:
1. Add #define WIN32_LEAN_AND_MEAN before including any Windows SDK headers (usually windows.h). That blocks a lot of often-unnecessary Windows SDK definitions. If your program compiles cleanly with this defined, using it is a good idea.
2. If it turns out you can't use WIN32_LEAN_AND_MEAN, try #define NOCRYPT instead.
3. If that doesn't work, use #undef X509_NAME after your Windows SDK headers and before including any OpenSSL headers.
This sort of thing is a common problem when writing programs for Windows that use non-Microsoft APIs.
--
Michael Wojcik
More information about the openssl-users
mailing list