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