Re: Trying to install Apache 2.4 with OpenSSL 1.1 instead of LibreSSL

On Mon, 29 Jan 2024 19:45:27 +0000
Stuart Henderson <stu@spacehopper.org> wrote:

> On 2024/01/29 09:51, giovanni@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 @@
> +