Chapter 7. Known issues

dotnet dev-certs https --trust does not work on RHEL.

.NET supports the creation of HTTPS certificate through dotnet dev-certs https, but it does not support trusting them through dotnet dev-certs https --trust. The client that connects to the ASP.NET Core application, such as curl or Firefox, will warn about the untrusted self-signed certificate. To work around this in a browser such as Firefox, ignore the warning and trust the certificate explicitly when the warning about the untrusted certificate comes up. Command-line tools support flags to ignore untrusted certificates. For curl, use the --insecure flag. For wget, use the --no-check-certificate flag.

There are no NuGet packages for s390x on nuget.org.

Using the rhel.8-s390x or linux-s390x runtime identifier can cause some dotnet commands to fail when they try to obtain these packages. These commands are either not fully supported on s390x as described in the other known issues, or the issue can be fixed by not specifying the runtime identifier.

.NET 6.0 on s390x does not understand memory and cpu limits in containers.

In such environments, it is possible that .NET 6.0 will try to use more memory than allocated to the container, causing the container to get killed or restarted in OpenShift Container Platform. As a workaround you can manually specify a heap limit through an environment variable: MONO_GC_PARAMS=max-heap-size=<limit>. You should set the limit to 75% of the memory allocated to the container. For example, if the container memory limit is 300MB, set MONO_GC_PARAMS=max-heap-size=225M.

The default version of the Microsoft.NET.Test.Sdk package in the test project templates (xunit, nunit, mstest) is unusable on s390x. Trying to build/run tests will fail with a "System.NotSupportedException: Specified method is not supported" exception.

If you are trying to run test on s390x, update the version of the Microsoft.NET.Test.Sdk package to at least 17.0.0.

RHEL 9 has disabled several weak security algorithms to improve security.

Some .NET APIs using these algorithms will fail at runtime with CryptographicExceptions. If you really must use the weak algorithms and risk compromising security, you can loosen the system’s security policies by using:

update-crypto-policies --set DEFAULT:SHA1

# update-crypto-policies --set DEFAULT:SHA1

or

update-crypto-policies --set LEGACY”

# update-crypto-policies --set LEGACY”

For more information, see the “Security” section in the overview of major changes in the RHEL 9 release notes.

Strong Naming will not work out of the box on RHEL 9.

RHEL 9 has disabled the use of SHA-1 in the default configuration. .NET uses SHA-1+RSA to identify assemblies that have been signed with a strong name. The explicit SHA-1+RSA algorithm combination is a part of the ECMA-335 specification involving strong naming. However, given the recent attacks against SHA-1, RHEL 9 has deprecated the use of SHA-1 (when combined with RSA) to improve security across the entire operating system. This means that any use of strong naming, including verification at build time, will fail.

The OpenSSL errors on RHEL 9 will indicate an invalid digest algorithm. For example:

error : Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:03000098:digital envelope routines::invalid digest

error : Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:03000098:digital envelope routines::invalid digest

There are several possible workarounds:

The NTLM technology is considered insecure in RHEL 9.

The gss-ntlmssp package, which provides NTLM authentication support, has been removed from RHEL 9. That means .NET in RHEL 9 can not authenticate against NTLM. If you use NLTM authentication, please use another mechanism to authenticate.

For more details, see the Identity Management section of Considerations in Adopting RHEL 9.