| Author |
|
cwolkowski
Joined: 09 Dec 2020
Posts: 5
|
 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: 414
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: 5
|
| 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: 414
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 |
|
cwolkowski
Joined: 09 Dec 2020
Posts: 5
|
| Posted: Tue 20 Jan '26 18:14 Post subject: |
|
|
My organization has a team that does Security checks for vulnerabilities and reports us to upgrade.
For example:
Security Scorecard is reporting this issue as well Apache HTTP Server.
Vulnerability Description
Server-Side Request Forgery (SSRF) vulnerability \xC2\xA0in Apache HTTP Server on Windows with AllowEncodedSlashes On\xC2\xA0and MergeSlashes Off\xC2\xA0 allows to potentially leak NTLM hashes to a malicious server via SSRF and malicious requests or content Users are recommended to upgrade to version 2.4.66, which fixes the issue.
Is it possible for me to downgrade OpenSSL 3.6 to 3.5 on Apache 2.4.66 ? Would it be just copying the OpenSSL files from the 2.4.65 build ? |
|
| Back to top |
|
tangent
Moderator
Joined: 16 Aug 2020
Posts: 414
Location: UK
|
| Posted: Tue 20 Jan '26 22:50 Post subject: |
|
|
Re your Security team reported CVE-2025-59775 - Server-Side Request Forgery (SSRF) vulnerability.
This is not the first time this type of question has been asked; if you search this site for "libssl-3-x64.dll" you'll find a number of posts where OpenSSL file versions have been discussed.
The latest (CMake based) AL 2.4.66 package comes with these OpenSSL (3.6.0) core files:
| Code: | bin/libcrypto-3-x64.dll
bin/libssl-3-x64.dll
bin/openssl.exe
lib/libcrypto.lib
lib/libssl.lib
|
Note the static OpenSSL libraries aren't present in earlier AL releases.
So I've just tried replacing the above OpenSSL (bin) related files with those from (AL 2.4.65) OpenSSL 3.5.1, on a minimal functionality SSL based site, and things still appear to work ok. You'll certainly get the following start up warning in your Apache error log.
| Code: | | [Tue Jan 20 20:07:51.617317 2026] [ssl:warn] [pid 21484:tid 488] AH01882: Init: this version of mod_ssl was compiled against a newer library (OpenSSL 3.6.0 1 Oct 2025 (OpenSSL 3.5.1 1 Jul 2025), version currently loaded is 0x30500010) - may result in undefined or erroneous behavior |
but there's no guarantee it won't break some site functionality elsewhere with other SSL related tasks or linkage through mod_ssl.so, mod_session_crypto.so, etc. Also , what about potential vulnerabilities in OpenSSL 3.5.1, which is several revisions down from the latest 3.5 series release?
Even if this fix does work for your site, you'll make future support more complicated, especially as new releases will make the OpenSSL files diverge even further. As usual, your mileage may vary.
I'd suggest discussing options with your Security Team and Site Support Management, to get a concensus on how to proceed. |
|
| Back to top |
|
cwolkowski
Joined: 09 Dec 2020
Posts: 5
|
| Posted: Wed 21 Jan '26 18:24 Post subject: |
|
|
Thanks for taking the time to troubleshoot with the downgrade. I was going to try that today and then read your post and agree that this probably wouldn't be the best approach.
I decided to use the latest OpenSSL 3.6 and upgrade the code that depended on the legacy method. Everything seems to be good now.
Appreciate all your support! Thanks |
|
| Back to top |
|
