第7章 既知の問題
Red Hat Enterprise Linux (RHEL) で .NET を実行するための既知の問題は次のとおりです。
以前のバージョンの RHEL では動作しません。
dotnet dev-certs https --trustは RHEL では機能しません。.NET は、
dotnet dev-certs httpsによる HTTPS 証明書の作成をサポートしますが、dotnet dev-certs https --trustによる信頼はサポートしていません。curlや Firefox などの ASP.NET Core アプリケーションに接続するクライアントは、信頼できない自己署名証明書について警告します。Firefox などのブラウザーでこれを回避するには、警告を無視し、信頼できない証明書に関する警告が表示されたときに証明書を明示的に信頼します。コマンドラインツールは、信頼できない証明書を無視するフラグをサポートします。curlには、--insecureフラグを使用します。wgetには、--no-check-certificateフラグを使用します。nuget.org には
s390xの NuGet パッケージはありません。rhel.8-s390xまたはlinux-s390xランタイム識別子を使用すると、これらのパッケージを取得しようとする一部のdotnetコマンドが失敗することがあります。これらのコマンドは、他の既知の問題で説明されているようにs390xで完全にサポートされていないか、ランタイム識別子を指定しないことで問題を修正できます。-
s390xでは、単一ファイルのアプリケーションはサポートされていません。 -
PublishReadyToRun/crossgen は
s390xではサポートされていません。 s390xの .NET 6.0 は、コンテナーのメモリーおよび CPU 制限を認識しません。このような環境では、.NET 6.0 がコンテナーに割り当てられた以上のメモリーを使用しようとする可能性があり、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: Specified method is not supported 例外により失敗します。s390xでテストを実行する場合は、Microsoft.NET.Test.Sdkパッケージのバージョンを 17.0.0 以上に更新します。-
Visual Studio Code などの IDE によって使用される言語サーバーである OmniSharp は、
s390xでは使用できません。 RHEL 9 では、セキュリティーを強化するために、脆弱なセキュリティーアルゴリズムが複数無効になっています。
これらのアルゴリズムを使用する .NET API によっては、実行時に CryptographicExceptions で失敗します。脆弱なアルゴリズムを使用する必要があり、セキュリティー低下のリスクを取る場合には、以下を使用してシステムのセキュリティーポリシーを緩和できます。
# update-crypto-policies --set DEFAULT:SHA1
または
# update-crypto-policies --set LEGACY”
詳細は、RHEL 9 リリースノート 「セキュリティー」セクションにある主な変更点の概要を参照してください。
RHEL 9 では、そのままでは厳密な命名は機能しません。
RHEL 9 では、デフォルト設定で SHA-1 の使用が無効になっており、.NET は SHA-1+RSA を使用して、厳密な名前で署名されたアセンブリーを識別します。明示的な SHA-1+RSA アルゴリズムの組み合わせは、厳密な命名に関する ECMA-335 仕様に含まれています。ただし、RHEL 9 では、最近の SHA-1 に対する攻撃を考慮して、SHA-1 (RSA と組み合わせた場合) の使用を廃止して、オペレーティングシステム全体のセキュリティーを向上させました。そのため、ビルド時の検証など、厳密な命名を使用すると失敗します。
RHEL 9 で OpenSSL エラーが発生すると、ダイジェストアルゴリズムが無効であることがわかります。以下に例を示します。
error : Unhandled exception. Interop+Crypto+OpenSslCryptographicException: error:03000098:digital envelope routines::invalid digest
次のように、回避策が複数あります。
システムのセキュリティーポリシーを緩めて、SHA-1+RSA のサポートを有効にします。
# update-crypto-policies --set DEFAULT:SHA1
注記これは、FIPS が有効になっている場合は機能しません。FIPS モードでは、SHA-1 は全く使用できません。
Public Signing に切り替えます。これを行うには、プロジェクトファイルを修正して、プロパティーを複数設定する必要があります。
<PropertyGroup> <AssemblyOriginatorKeyFil>$(MSBuildThisFileDirectory)Key.snk</AssemblyOriginatorKeyFile> <SignAssembly>true</SignAssembly> <PublicSign Condition="'$(OS)' != 'Windows_NT'">true</PublicSign> </PropertyGroup>
NTLM テクノロジーは、RHEL 9 では安全ではないと考えられます。
NTLM 認証サポートを提供する
gss-ntlmsspパッケージは、RHEL 9 から削除されました。そのため、RHEL 9 の .NET は NTLM に対して認証できなません。NLTM 認証を使用する場合は、別のメカニズムを使用して認証してください。詳細は、RHEL 9 の導入に関する考慮事項のアイデンティティー管理のセクション を参照してください。
