Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
 Topic: Apache 2.4.66 with OpenSSL legacy.dll not working |
|
| Author |
|
cwolkowski
Joined: 09 Dec 2020
Posts: 3
|
 Posted: Tue 13 Jan '26 18:53 Post subject: Apache 2.4.66 with OpenSSL legacy.dll not working |
 |
|
After upgrading to httpd-2.4.66-260107-Win64-VS18 I get an error when trying to use legacy.dll with my Apache/OpenSSL.
I've been using legacy.dll in previous versions of Apache with no issues. Specifically when I downgrade back to 2.4.65 it works.
| Code: | pkcs12: unable to load provider legacy
Hint: use -provider-path option or OPENSSL_MODULES environment variable.
3C320000:error:12800067:DSO support routines:win32_load:could not load the shared library:crypto\dso\dso_win32.c:108:filename(C:\Apache24\bin\legacy.dll)
3C320000:error:12800067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:147:
3C320000:error:07880025:common libcrypto routines:provider_init:reason(37):crypto\provider_core.c:1021:name=legacy |
I already have env variable set since it works on 2.4.65 and I re-set it to make sure on 2.4.66 but still gives error. |
|
| Back to top |
|
tangent
Moderator
Joined: 16 Aug 2020
Posts: 413
Location: UK
|
| Posted: Wed 14 Jan '26 22:15 Post subject: |
|
|
Apache Lounge HTTPD release 2.4.65 comes with OpenSSL 3.5.1, whereas release 2.4.66 bundles OpenSSL 3.6.0.
| Code: | C:\>C:\Apache24\bin\openssl.exe version
OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025) |
A quick search on the net for OpenSSL 3.6.0 with error "pkcs12: unable to load provider legacy" reveals:
OpenSSL 3.6.0 introduces significant updates, including the deprecation of some legacy PKCS functionalities as part of its ongoing effort to modernize the library and improve security. So knowing your configuration works with OpenSSL 3.5.1, your legacy support problem appears to be down to changes introduced in OpenSSL 3.6.0.
I've also tried updating openssl.cnf to specifically include "legacy provider" support, viz:
| Code: | # OpenSSL configuration file for Windows with legacy support
#
openssl_conf = openssl_init
[openssl_init]
providers = provider_sect
[provider_sect]
default = default_sect
legacy = legacy_sect # Reference the legacy section
[default_sect]
activate = 1 # Activate the default provider
[legacy_sect]
activate = 1 # Activate the legacy provider
|
Like your error log, the following shows the legacy provider request is recognized:
| Code: | C:\>C:\Apache24\bin\openssl.exe list -providers
Providers:
default
name: OpenSSL Default Provider
version: 3.6.0
status: active
legacy
name: OpenSSL Legacy Provider
version: 3.6.0
status: active |
But not apparently supported; least when I try an s_client connection with a legacy cipher.
I suspect you're either going to have to phase out your legacy support, or stick to an older release of OpenSSL. |
|
| Back to top |
|
cwolkowski
Joined: 09 Dec 2020
Posts: 3
|
| Posted: Thu 15 Jan '26 5:01 Post subject: |
|
|
Thanks for looking into this. I didn't see that OpenSSL 3.6.0 has removed the legacy function.
Appreciate it!  |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1293
Location: Amsterdam, NL, EU
|
| Posted: Fri 16 Jan '26 18:10 Post subject: |
|
|
| tangent wrote: | | Apache Lounge HTTPD release 2.4.65 comes with OpenSSL 3.5.1, whereas release 2.4.66 bundles OpenSSL 3.6.0. |
I am always a bit surprised that someone uses non LTS versions of OpenSSL. From https://openssl-library.org/policies/releasestrat/index.html
Version 3.6 will be supported until 2026-11-01
Version 3.5 will be supported until 2030-04-08 (LTS)
That is 3+ years extra support without upgrade troubles like in this issue. |
|
| Back to top |
|
tangent
Moderator
Joined: 16 Aug 2020
Posts: 413
Location: UK
|
| Posted: Fri 16 Jan '26 19:00 Post subject: |
|
|
It's a legitimate comment, and one I've pondered before.
There are people far more qualified than I am in the security world, (nor would I profess to know about subtle changes for legacy support made between these two versions), but in my opinion sticking with an earlier release series will over time unearth ever more functionality and compatability issues.
For example, I guess most people would be reluctant to run with OpenSSL 1.x these days, even if extended support is available?
If I do have one, my main concern over sticking with earlier LTS would be that going forward, there might be certain vulnerabilities they're unable to resolve due to the differences in supported features or code base functionality. Moreover, at some point it will be necessary to move to a later product release series, and then similar compatability problems will almost inevitably arise.
This problem is true for software (and operating systems) in general, not just security packages such as OpenSSL.
However, for consideration, maybe AL should regress back to using LTS releases, e.g. 3.5.4? |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1293
Location: Amsterdam, NL, EU
|
| Posted: Fri 16 Jan '26 19:06 Post subject: |
|
|
| My preference is using the latest LTS version of OpenSSL. The PHP devs only ship the Windows version with an OpenSSL LTS version as well. They even use OpenSSL 3.0.x LTS for PHP 8.4 which seems a bit too conservative for me. |
|
| Back to top |
|
Steffen
Moderator
Joined: 15 Oct 2005
Posts: 3162
Location: Hilversum, NL, EU
|
| Posted: Sun 18 Jan '26 19:25 Post subject: |
|
|
I think it is an issue for PHP. To offer LTS version we may have to do it for years. Stay with 3.6. Users can try to copy over the LTS files.
Maybe the php guys have a work around. |
|
| Back to top |
|
|
|
|
|
|
