第 7 章 已知问题

dotnet dev-certs https --trust 无法在 RHEL 上工作。

.NET 支持通过 dotnet dev-certs https 创建 HTTPS 证书，但它不支持通过 dotnet dev-certs https --trust 信任它们。连接到 ASP.NET Core 应用程序的客户端（如 curl 或 Firefox）将警告不受信任的自签名证书。要在 Firefox 等浏览器中临时解决这个问题，请忽略警告并信任证书（当有关不受信任的证书的警告）。命令行工具支持标志来忽略不可信证书。对于 curl，请使用 --insecure 标志。对于 wget，请使用 --no-check-certificate 标志。

nuget.org 上没有 s390x 的 NuGet 软件包。

使用 rhel.8-s390x 或 linux-s390x 运行时标识符可能会导致一些 dotnet 命令在尝试获取这些软件包时失败。如其他已知问题所述，s390x 无法完全支持这些命令，或者通过不指定运行时标识符来解决这个问题。

s390x 中的 .NET 6.0 不支持容器中的内存和 cpu 限制。

在这种环境中，.NET 6.0 可能会使用比分配给容器更多的内存，从而导致容器被终止（kill），或在 OpenShift Container Platform 中重启。这个问题的一个临时解决方案是，使用环境变量 MONO_GC_PARAMS=max-heap-size=<limit> 指定一个堆限制。您可以将限制设置为分配给容器的内存量的 75%。例如，如果容器内存限制是 300MB，设置 MONO_GC_PARAMS=max-heap-size=225M。

测试项目模板(xunit、nunit、mstest)中的 Microsoft.NET.Test.Sdk 软件包的默认版本在 s390x 上不可用。尝试构建/运行测试会失败，并显示 "System.NotSupportedException: specifyd method are not supported" 例外。

如果您要在 s390x 上运行测试，请将 Microsoft.NET.Test.Sdk 软件包的版本更新为 least 17.0.0。

RHEL 9 禁用了几个弱安全算法来提高安全性。

使用这些算法的一些 .NET API 会在运行时使用 CryptographicExceptions 失败。如果您确实必须使用弱算法和风险影响安全性，您可以使用以下方法限制系统的安全策略：

update-crypto-policies --set DEFAULT:SHA1

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

或

update-crypto-policies --set LEGACY”

# update-crypto-policies --set LEGACY”

如需更多信息，请参阅 RHEL 9 发行注记中 主要更改概述中的"安全"部分。

在 RHEL 9 中，强大的命名将不会开箱即用。

RHEL 9 已在默认配置中禁用 SHA-1。.NET 使用 SHA-1+RSA 来识别使用强名称签名的假设。显式 SHA-1+RSA 算法组合是涉及强命名的 ECMA-335 规范的一部分。但是，由于对 SHA-1 的最新攻击，RHEL 9 弃用了 SHA-1 （与 RSA 结合使用）来提高整个操作系统的安全性。这意味着，任何使用强命名（包括构建时验证）将失败。

RHEL 9 上的 OpenSSL 错误将代表无效的摘要算法。例如：

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

有几个可能的临时解决方案：

在 RHEL 9 中，NTLM 技术被视为不安全。

提供 NTLM 身份验证支持的 gss-ntlmssp 软件包已从 RHEL 9 中删除。这意味着 RHEL 9 中的 .NET 无法针对 NTLM 进行身份验证。如果您使用 NLTM 身份验证，请使用其他机制进行验证。

如需了解更多详细信息，请参阅 采用 RHEL 9 中的注意事项 身份管理 部分。