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.

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.

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

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?