On Mon, 29 Jan 2024 19:45:27 +0000 Stuart Henderson <s...@spacehopper.org> 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)... > > Index: patch-modules_ssl_ssl_private_h > =================================================================== > RCS file: > /cvs/ports/www/apache-httpd/patches/patch-modules_ssl_ssl_private_h,v > retrieving revision 1.11 > diff -u -p -r1.11 patch-modules_ssl_ssl_private_h > --- patch-modules_ssl_ssl_private_h 15 Nov 2022 23:14:12 -0000 1.11 > +++ patch-modules_ssl_ssl_private_h 29 Jan 2024 19:44:30 -0000 > @@ -1,6 +1,15 @@ > Index: modules/ssl/ssl_private.h > --- modules/ssl/ssl_private.h.orig > +++ modules/ssl/ssl_private.h > +@@ -217,7 +217,7 @@ > + #endif > + > + /* ALPN Protocol Negotiation */ > +-#if defined(TLSEXT_TYPE_application_layer_protocol_negotiation) > ++#if 0 && defined(TLSEXT_TYPE_application_layer_protocol_negotiation) > + #define HAVE_TLS_ALPN > + #endif > + > @@ -232,9 +232,11 @@ > #define BN_get_rfc3526_prime_4096 get_rfc3526_prime_4096 > #define BN_get_rfc3526_prime_6144 get_rfc3526_prime_6144 > Thank you for looking at this. I will try your suggestion at my earliest opportunity and report back. --TimH
