Mailing List Archive

On Fri, Mar 1, 2024 at 12:59?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Fri, Mar 1, 2024 at 11:15?AM <jorton@apache.org> wrote:
> >
> > Author: jorton
> > Date: Fri Mar 1 10:15:13 2024
> > New Revision: 1916068
> >
> > URL: http://svn.apache.org/viewvc?rev=1916068&view=rev
> > Log:
> > CI: add OpenSSL 3.2, test OpenSSL 3.x using Apache::Test
> > trunk to pick up r1916067.
>
> I had to modify Apache-Test too when running the perl test framework
> with openssl >= 3.0 and proposed a patch here [1] (not enough karma to
> commit on perl.a.o).
> It was an issue with mod_proxy's client certs IIRC, which r1916067 is
> possibly fixing too, but just in case you are still fighting with this
> ;)
>
> [1] https://lists.apache.org/thread/z655wrccpqsvxdwyj8znrp6qd194c410

Well, this is an issue if trying to test httpd linked with openssl < 3
on a system with openssl >= 3 (perl will the system's by default), so
it's not what our ci is doing now IIUC, but should it (or should one
try this)..

On Fri, Mar 01, 2024 at 12:59:10PM +0100, Yann Ylavic wrote:
> On Fri, Mar 1, 2024 at 11:15?AM <jorton@apache.org> wrote:
> >
> > Author: jorton
> > Date: Fri Mar 1 10:15:13 2024
> > New Revision: 1916068
> >
> > URL: http://svn.apache.org/viewvc?rev=1916068&view=rev
> > Log:
> > CI: add OpenSSL 3.2, test OpenSSL 3.x using Apache::Test
> > trunk to pick up r1916067.
>
> I had to modify Apache-Test too when running the perl test framework
> with openssl >= 3.0 and proposed a patch here [1] (not enough karma to
> commit on perl.a.o).
> It was an issue with mod_proxy's client certs IIRC, which r1916067 is
> possibly fixing too, but just in case you are still fighting with this
> ;)

Ah, interesting, thanks. I should read dev@perl more often!

I haven't seen that particularly failure, and trunk seems to now be
working (touch wood) with 3.1 and 3.2. The Ubuntu runners are all on
OpenSSL 3.0 anyway, and r1916058 ensures that TestSSLCA.pm is using the
bin/openssl from the installed version of OpenSSL rather than a
possibly-mismatched system /usr/bin/openssl. Do you still want that
TestSSLCA.pm change merged?

Also - I guess the note about *not* accepting PKCS#8 format keys in
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatefile
is now wrong then?

Regards, Joe

On Fri, Mar 1, 2024 at 1:24?PM Joe Orton <jorton@redhat.com> wrote:
>
> On Fri, Mar 01, 2024 at 12:59:10PM +0100, Yann Ylavic wrote:
> > On Fri, Mar 1, 2024 at 11:15?AM <jorton@apache.org> wrote:
> > >
> > > Author: jorton
> > > Date: Fri Mar 1 10:15:13 2024
> > > New Revision: 1916068
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1916068&view=rev
> > > Log:
> > > CI: add OpenSSL 3.2, test OpenSSL 3.x using Apache::Test
> > > trunk to pick up r1916067.
> >
> > I had to modify Apache-Test too when running the perl test framework
> > with openssl >= 3.0 and proposed a patch here [1] (not enough karma to
> > commit on perl.a.o).
> > It was an issue with mod_proxy's client certs IIRC, which r1916067 is
> > possibly fixing too, but just in case you are still fighting with this
> > ;)
>
> Ah, interesting, thanks. I should read dev@perl more often!
>
> I haven't seen that particularly failure, and trunk seems to now be
> working (touch wood) with 3.1 and 3.2. The Ubuntu runners are all on
> OpenSSL 3.0 anyway, and r1916058 ensures that TestSSLCA.pm is using the
> bin/openssl from the installed version of OpenSSL rather than a
> possibly-mismatched system /usr/bin/openssl. Do you still want that
> TestSSLCA.pm change merged?

I think it can be useful for those who test httpd with openssl1 still
(not maintained anymore, but we have to keep compatibility in 2.4 at
least).

>
> Also - I guess the note about *not* accepting PKCS#8 format keys in
> https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatefile
> is now wrong then?

OpenSSL >= 3 can surely load keys in pkcs#8 format since it's the
default for genrsa now, hopefully it can still load the pkcs#1 ones
still (I didn't try that) or it would be a mess for mod_proxy (and the
docs)..
Let me try that first and if it's ok I think we can simply say that
the note applies to openssl < 3 only.

On Fri, Mar 1, 2024 at 1:42?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Fri, Mar 1, 2024 at 1:24?PM Joe Orton <jorton@redhat.com> wrote:
> >
> > Do you still want that
> > TestSSLCA.pm change merged?
>
> I think it can be useful for those who test httpd with openssl1 still
> (not maintained anymore, but we have to keep compatibility in 2.4 at
> least).

But the issue with this patch is that it doesn't check which openssl
version httpd is actually using, so it always generates pkcs#1 keys
even if not needed.
If we had a way to check the system's openssl AND httpd's openssl are
< 3 it would be better, but I don't see how to do this.

On Fri, Mar 1, 2024 at 1:42?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
>
> On Fri, Mar 1, 2024 at 1:24?PM Joe Orton <jorton@redhat.com> wrote:
> >
> > Also - I guess the note about *not* accepting PKCS#8 format keys in
> > https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxymachinecertificatefile
> > is now wrong then?
>
> OpenSSL >= 3 can surely load keys in pkcs#8 format since it's the
> default for genrsa now, hopefully it can still load the pkcs#1 ones
> still (I didn't try that) or it would be a mess for mod_proxy (and the
> docs)..
> Let me try that first and if it's ok I think we can simply say that
> the note applies to openssl < 3 only.

The perl framework seems to pass all the tests here if I use openssl
>= 3 for both the system and httpd and then force pkcs#1 keys (i.e.
genrsa -traditional), so it seems fine to say that
SSLProxyMachineCertificateFile works with pkcs#1 and pkcs#8 keys when
httpd's openssl >= 3 but only pkcs#1 ones when openssl < 3.

On Fri, Mar 01, 2024 at 01:52:15PM +0100, Yann Ylavic wrote:
> On Fri, Mar 1, 2024 at 1:42?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> >
> > On Fri, Mar 1, 2024 at 1:24?PM Joe Orton <jorton@redhat.com> wrote:
> > >
> > > Do you still want that
> > > TestSSLCA.pm change merged?
> >
> > I think it can be useful for those who test httpd with openssl1 still
> > (not maintained anymore, but we have to keep compatibility in 2.4 at
> > least).
>
> But the issue with this patch is that it doesn't check which openssl
> version httpd is actually using, so it always generates pkcs#1 keys
> even if not needed.
> If we had a way to check the system's openssl AND httpd's openssl are
> < 3 it would be better, but I don't see how to do this.

I suppose we could export the detected version from configure via apxs
-q and pick it up in Apache::Test, but I think it would be likely to
make the whole house of cards even more fragile. So I'm not sure it's
worth investing effort in that tbh. Better to assume/require that the
bin/openssl version matches the version mod_ssl uses.

Regards, Joe

On Fri, Mar 1, 2024 at 2:12?PM Joe Orton <jorton@redhat.com> wrote:
>
> On Fri, Mar 01, 2024 at 01:52:15PM +0100, Yann Ylavic wrote:
> > On Fri, Mar 1, 2024 at 1:42?PM Yann Ylavic <ylavic.dev@gmail.com> wrote:
> > >
> > > On Fri, Mar 1, 2024 at 1:24?PM Joe Orton <jorton@redhat.com> wrote:
> > > >
> > > > Do you still want that
> > > > TestSSLCA.pm change merged?
> > >
> > > I think it can be useful for those who test httpd with openssl1 still
> > > (not maintained anymore, but we have to keep compatibility in 2.4 at
> > > least).
> >
> > But the issue with this patch is that it doesn't check which openssl
> > version httpd is actually using, so it always generates pkcs#1 keys
> > even if not needed.
> > If we had a way to check the system's openssl AND httpd's openssl are
> > < 3 it would be better, but I don't see how to do this.
>
> I suppose we could export the detected version from configure via apxs
> -q and pick it up in Apache::Test, but I think it would be likely to
> make the whole house of cards even more fragile. So I'm not sure it's
> worth investing effort in that tbh. Better to assume/require that the
> bin/openssl version matches the version mod_ssl uses.

Yes agreed, let's drop this patch. There is still the
$APACHE_TEST_OPENSSL_CMD workaround to force the openssl version used
by the framework to align with httpd's (for those who want to test
with openssl < 3).

Thanks!
Yann.

>
> Regards, Joe
>