On Mon, Jan 29, 2024 at 07:45:27PM +0000, Stuart Henderson wrote: > On 2024/01/29 09:51, giova...@paclan.it wrote: > > On 1/26/24 23:11, Tim wrote: > > > I'm trying to troubleshoot an issue where Chrome/Chromium browsers > > > randomly fail to correctly use SSL against my web server. > > > > > This is a known issue, see > > https://marc.info/?l=openbsd-ports&m=167449054903277&w=2 > > > > > So I am trying to compile and install an apache-http port with OpenSSL 1.1 > > > library instead of LibreSSL. > > > > > > I have managed to compile and install this customer port, however, I > > > don't know if I ultimately succeeded because when it starts it still > > > says this in the log file: > > > > > > [Fri Jan 26 14:02:57.131803 2024] [mpm_prefork:notice] [pid 67010] > > > AH00163: Apache/2.4.58 (Unix) LibreSSL/3.8.2 configured -- resuming > > > normal operations > > > > > > Is this message wrong? Or am I still ending up with an Apache2 > > > compiled against LibreSSL instead of OpenSSL? > > > you can find it by running "ldd /usr/local/lib/apache2/mod_ssl.so". > > That will show the libraries used but not the headers. (It is possible > to compile with openssl libraries but libressl headers - that will cause > problems too). > > I didn't check where httpd gets this version number in the log entry > from, but it can either be a function in one of the libraries > (libssl/libcrypto), or from the opensslv.h header. > > Even if you get apache-httpd built against the correct libraries, some > of the other libraries which it pulls in are built using libressl > libraries. Those will need to be rebuilt using openssl too. This > includes apr-util and curl - but curl is used widely in the ports tree > and you're likely to cause problems for other installed packages if you > change that. > > Basically: building against a non-default version of a widely used > library is a hard problem and really best avoided. > > If your setup is reasonably simple, you may be able to use the > workaround of a single cert with a bunch of additional hostnames in > subjectAltName. In that case, SNI is not needed for the site to work, > and that will almost certainly be the easiest way... > > Another possible approach (untested)... > what about this one so I can commit it upstream as well ? Giovanni
Index: modules/ssl/ssl_private.h =================================================================== --- modules/ssl/ssl_private.h (revision 1915475) +++ modules/ssl/ssl_private.h (working copy) @@ -249,7 +249,7 @@ #endif /* ALPN Protocol Negotiation */ -#if defined(TLSEXT_TYPE_application_layer_protocol_negotiation) +#if !defined(LIBRESSL_VERSION_NUMBER) && defined(TLSEXT_TYPE_application_layer_protocol_negotiation) #define HAVE_TLS_ALPN #endif
