Unhandled exception. System.EntryPointNotFoundException: Unable to find an entry point named 'CryptoNative_SslCtxRemoveSession' in shared library 'libSystem.Security.Cryptography.Native.OpenSsl'

[gbraccini]

An application developed in C# ( .net 8.0 ) that implements a grpcCore service with authentication system has suddenly stopped working, reporting the error in the following statement: Unhandled exception. System.EntryPointNotFoundException: Unable to find an entry point named 'CryptoNative_SslCtxRemoveSession' in shared library 'libSystem.Security.Cryptography.Native.OpenSsl'

The service is published on Azure on a docker container made from the image: image, appsvc/dotnetcore:8.0_20240819.2.tuxprod

We have put into production another image completely identical to the previous one and our service is back up and running.

Do you have any suggestions to understand what could have been damaged in that container?

[vcsjones]

CryptoNative_SslCtxRemoveSession was introduced in .NET 8.0.7 - it was not present in .NET 8.0.6 (or earlier).

The only way I could think of this happening is when there is a mismatch between the managed library and the native library. Basically, libSystem.Security.Cryptography.Native.OpenSsl was 8.0.6 or earlier, but System.Net.Security was using 8.0.7.

How are you publishing your app? Is if framework dependent, single file, self-contained, etc?

[gbraccini]

Thanks for your reply, our application has been running for months and worked perfectly. Suddenly one evening at 9pm without anyone changing anything it started giving errors.

Our webapp is published directly from Visual Studio on Azure via ftp and is framework-dependent. Target framework 8.0

The application runs on four instances and they have become unhealthy.

An identical image running on another container was successfully put into production.

[rzikm]

As vcsjones said, the entry point has been added in a servicing release. Does the problem persist after redeploying/restarting the containers in question?

If the issue persist, maybe filing a support ticket directly on Azure is a better idea since this is their infrastructure.

[dotnet-policy-service[bot]]

This issue has been marked needs-author-action and may be missing some important information.

[josip8]

Having the same issue. I have several apps deployed on Linux App Service, some of them are working, and some throw this error, deployment is framework dependent on .NET 8

[vcsjones]

Having the same issue. I have several apps deployed on Linux App Service

Does re-deploying or restarting the service alleviate the issue?

---

At this point, all I can surmise, is that App Service does automatic patching of framework-dependent applications, and something did not work correctly.

I would agree that Azure support is likely the best course of action here.

[gianlucabraccini]

re-deploying on a new container resolve the issue.

[dotnet-policy-service[bot]]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[dotnet-policy-service[bot]]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.