On Tue, Jan 30, 2024 at 11:01:24AM +0100, Giovanni Bechis wrote:
> On Mon, Jan 29, 2024 at 07:45:27PM +0000, Stuart Henderson 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)...
> > 
> what about this one so I can commit it upstream as well ?

Please do not.

>  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
>