第7章 既知の問題

Red Hat Enterprise Linux (RHEL) で .NET を実行するための既知の問題は次のとおりです。

以前のバージョンの RHEL では動作しません。

  1. 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 フラグを使用します。

  2. nuget.org には s390x の NuGet パッケージはありません。

    rhel.8-s390x または linux-s390x ランタイム識別子を使用すると、これらのパッケージを取得しようとする一部の dotnet コマンドが失敗することがあります。これらのコマンドは、他の既知の問題で説明されているように s390x で完全にサポートされていないか、ランタイム識別子を指定しないことで問題を修正できます。

  3. s390x では、単一ファイルのアプリケーションはサポートされていません。
  4. PublishReadyToRun/crossgen は s390x ではサポートされていません。

  5. 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 を設定します。

  6. テストプロジェクトテンプレート (xunit、nunit、mstest) の Microsoft.NET.Test.Sdk パッケージのデフォルトバージョンは s390x では使用できません。テストをビルドまたは実行しようとすると System.NotSupportedException: Specified method is not supported 例外により失敗します。

    s390x でテストを実行する場合は、Microsoft.NET.Test.Sdk パッケージのバージョンを 17.0.0 以上に更新します。

  7. Visual Studio Code などの IDE によって使用される言語サーバーである OmniSharp は、s390x では使用できません。

  8. RHEL 9 では、セキュリティーを強化するために、脆弱なセキュリティーアルゴリズムが複数無効になっています。

    これらのアルゴリズムを使用する .NET API によっては、実行時に CryptographicExceptions で失敗します。脆弱なアルゴリズムを使用する必要があり、セキュリティー低下のリスクを取る場合には、以下を使用してシステムのセキュリティーポリシーを緩和できます。 

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

    または 

    # update-crypto-policies --set LEGACY”

    詳細は、RHEL 9 リリースノート 「セキュリティー」セクションにある主な変更点の概要を参照してください。

  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>

  10. NTLM テクノロジーは、RHEL 9 では安全ではないと考えられます。

    NTLM 認証サポートを提供する gss-ntlmssp パッケージは、RHEL 9 から削除されました。そのため、RHEL 9 の .NET は NTLM に対して認証できなません。NLTM 認証を使用する場合は、別のメカニズムを使用して認証してください。

    詳細は、RHEL 9 の導入に関する考慮事項のアイデンティティー管理のセクション を参照してください。