Hello

I’m Adeyemi and I’d be happy to help you with your question.

Updating OpenSSL when it's integrated within applications can be a bit tricky, but it's not impossible. Here are some general steps you can follow:

1. Identify the Applications: Determine which applications on your system are using OpenSSL. This might require checking the documentation or contacting the software vendor.
2. Check for Updates: Many applications bundle OpenSSL and will provide updates that include updated versions of OpenSSL when they become available. Check the software vendor's website or contact them directly to see if they have released an update.
3. Recompile the Application: If the application's source code is available, and it's feasible, you could recompile the application with the updated OpenSSL library. This is a more technical approach and requires some knowledge of programming and compilation.
4. Use a Package Manager: If you're using a package manager like vcpkg, you can update just OpenSSL and nothing else. This might not be applicable in all scenarios, especially if the application statically links OpenSSL.

If none of the above options are viable, your best bet would be to contact the vendor of the software and inquire about their plans for addressing the OpenSSL vulnerability.

Remember, it's crucial to test all changes in a safe and reversible manner, ideally in a non-production environment first. Always backup your data before making such updates.

I hope this helps.

Give back to the community. Help the next person who has this issue by indicating if this reply solved your problem. Click Yes or No below.

Kind regards, Adeyemi

I finally made it, I installed OpenSSL 3.2.0-dev on Windows 11.

These are the detailed steps so that anyone in the future can do it:

I ended up using the first method, with C++, as seen here: https://github.com/openssl/openssl/blob/master/NOTES-WINDOWS.md#quick-start

Here are the instructions, I tried to make them as detailed as possible, let me know if it needs changes or fixes:

First steps: Installing the necessary software:

Step 1: Install Perl - Install the Strawberry version, much easier to install and it installs everything and also adds them automatically to the Windows PATH variables

Step 2: Install NASM, and add it to the Windows system (or your user's) PATH variables. I ended up adding it only to my user's variables PATH: C:\Users\<username>\AppData\Local\bin\NASM

Step 3: Install Visual Studio (I have Visual Studio Community 2022), and install the Desktop development with c++. I ended up choosing the following packages(I'm sure not all are necessary, but if you know, please let me know which ones are the ones I need so that I'll update the photo to avoid installing too many packages):

Step 4: Download and install the Build Tools for Visual Studio (I assume in the future this link will change so look for the Build Tools installation link for your Visual Studio version): https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022

Step 5: After installing the build tools, launch the Visual Studio installer. In the installer, you will now see the Build Tools. Click on "Modify" under the Visual Studio Build Tools:

And then install the needed packages for the OpenSSL installation, it's what's going to install nmake:

Then, the build and installation steps:

Step 6: Clone the openssl repository to some folder on your PC (I cloned it in C:/ so I ended up having C:/openssl/), and fix the line endings by running the following commands:

> git clone git://git.openssl.org/openssl.git

> cd openssl
> git config core.autocrlf false
> git config core.eol lf
> git checkout .

Update: If you want another version, clone the repository without checking out, fix the line-endings and then checkout to the version you want. For example if you want 3.1.0 stable (Note the -n flag for no-checkout):

> git clone -n git://git.openssl.org/openssl.git

> cd openssl
> git config core.autocrlf false
> git config core.eol lf
> git checkout openssl-3.1.0

Step 7: In Windows Search, search for "Developer Command Prompt for VS 2022" (Or any of your versions), and run it as administrator:

Which will open this command window:

Step 8: You need to set the right environment for the version of OpenSSL you want to install, otherwise build will fail. In my case, I wanted to install OpenSSL for 64-bit systems, copy-paste the following (including the quotes, and change the path according to your Visual Studio installation path):

"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat"

which will then set the environment, as seen here:

Step 9: From the same Developer Command Prompt, cd into the folder you cloned the openssl source code, in my case it was C:/openssl, and then follow the steps from the OpenSSL guide:

> perl Configure VC-WIN64A
> nmake
> nmake test
> nmake install

Note that these steps take time, it took me around 20-30 minutes to finish all these 4 commands

Step 10: That's it! It's installed! You can find the OpenSSL executable (openssl.exe) at C:\openssl\apps. (And add it to Windows system or user's PATH variables if you want)

In my case when I run openssl version I see OpenSSL 3.2.0-dev (Library: OpenSSL 3.2.0-dev )

Hello Jane,

Your case is not related to Windows for Business or Windows 365 Enterprise. What you are dealing with is an application dependency issue around OpenSSL versions on Windows. Winget installs the latest OpenSSL binaries into a system path, but applications do not automatically switch to using them. Each program either links statically to its own bundled OpenSSL libraries or dynamically loads them from a specific path. That means even if you have the newest OpenSSL installed globally, older applications may still be calling their embedded or outdated DLLs.

To verify which version is actually being used, you need to inspect the binaries that the application loads. On Windows, the most reliable way is to use Process Explorer from Sysinternals. Launch the application, open Process Explorer, and check the loaded modules under the process. If you see libssl-1_1.dll or libcrypto-1_1.dll, note the file path. That path tells you whether the program is using the system-installed OpenSSL or its own copy. You can also run openssl version from the command line to confirm the version of the OpenSSL binary you installed via Winget, but that only confirms the global installation, not what each application is consuming.

There is no single command line that forces all applications to use the new OpenSSL. Each application must either be updated by its vendor to link against the newer libraries, or you must replace the older DLLs in the application’s directory with the updated ones though this is risky and not recommended unless the vendor explicitly supports it. The best practice is to update the applications themselves to versions that are compiled against the latest OpenSSL.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

thank you for the info.... I'm wondering... for example a VM that I run in AZURE and shows the below:c:\packages\plugins\microsoft.azure.security.monitoring.azuresecuritywindowsagent\1.8.0.76\libcrypto-1_1-x64.dllc:\packages\plugins\microsoft.azure.security.monitoring.azuresecuritywindowsagent\1.8.0.76\libssl-1_1-x64.dllc:\packages\plugins\microsoft.guestconfiguration.configurationforwindows\1.29.44.0\dsc\gc\libcrypto-1_1-x64.dllc:\packages\plugins\microsoft.guestconfiguration.configurationforwindows\1.29.44.0\dsc\gc\libssl-1_1-x64.dllWill manual upgrading of openssl to newer version help with those references? Or do I somehow update them?

There is no resolution that will make it go away from the vulnerability dashboard that someone undoubtedly is pestering you about. What you are looking at is some dynamically linked libraries that contain some cryptographic functions that the applications in question make use of in some way or another. Building upon open source like this makes sense, since the alternative would be for everyone to spend time and resource on doing their own likely error-prone cryptographic implementation. Can you just compile your own OpenSSL dll files and use them to swap the allegedly vulnerable ones? Depends on the app. Sometimes it goes OK, sometimes it breaks the app. Someone is not very likely to stage a man-in-the-middle attack on microsoft windows photos. If the DLL is not in your systems PATH variable, then other applications on the system cannot make use of the DLL unless they address the exact path it is in. A better approach is to open a conversation with whoever is pestering you about the vulnerability scores. Explain that MS Defender will report on components on harddrive with CVE's, but it will NOT be able to determine for you which of these are exploitable. Thus, spending resources chasing a clean sheet in a vulnerability dashboard is a rather large waste of time. In fact, if you have a security team on your throat about CVE's in a dashboard, then ask them to help you prioritize the ones that are exploitable.

It's not possible to do anything as far as I am aware. We've had a number of OpenSSL vulnerabilities reported, and we've passed Certifications that check for vulnerabilities still. I assume they're still code signed by Microsoft (in terms of Microsoft products that use them) even though they're third party libraries, I imagine its not just a case of replacing them without breaking something.