認証局を構成する

認証局（CA）は、デジタル証明書の管理や発行を行う信頼できるエンティティです。デジタル証明書は公開鍵の所有権を示し、デバイスのオンラインIDを表します。

管理対象デバイスを必要とするアプリサインインポリシーを評価している際、Oktaではクライアント証明書がインストールされているかどうかを確認することで、各デバイスの管理ステータスを識別します。Oktaは、証明書がインストールされていることを証明するため、証明書を使用してデジタル署名を作成し、サーバー上で検証します。CAを構成すると、デバイスにクライアント証明書を発行して、この操作をサポートできるようになります。OktaをCAとして構成することも、独自のCAを提供することも可能です。

証明書がデプロイされると、ユーザーとデバイスがunmanagedとして表示される場合があります。ユーザーが認証後にOkta FastPassに問題なくサインインすると、Admin Consoleでユーザーとデバイスのステータスが更新され、managed状態が反映されます。

オプション：OktaをCAとして構成する

OktaをCAとして構成することで、時間を節約し、証明書の発行方法を合理化して、独自の公開鍵基盤（PKI）の複雑で高コストなデプロイと保守を避けることができます。

OktaをCAとして構成するには、モバイルデバイス管理（MDM）ソフトウェアでSimple Certificate Enrollment Protocol（SCEP）プロファイルを作成してから、OktaでSCEP URLを生成します。

Oktaでは、SCEPチャレンジを生成するために次の方法を提供しています。

  • 静的SCEP URL（Static SCEP URL）：MDMソフトウェアは、すべてのデバイスに同じチャレンジシークレットを割り当てます。このデバイス管理構成では、チャレンジシークレットがデバイス間で共有されます。構成用に作成された共有シークレットが検証され、各デバイスに一意のクライアント証明書が発行されます。

    以下を参照してください。

    • Jamf Pro を使用して、macOSの静的SCEPチャレンジを使用するCAとしてOktaを構成する

    • Workspace ONE を使用して、Windowsの静的SCEPチャレンジを使用するCAとしてOktaを構成する

  • Dynamic SCEP URL（動的SCEP URL）：MDMソフトウェアは、一意のチャレンジシークレットをデバイスに割り当てます。この構成では、存続期間が短い一意のチャレンジシークレットがデバイスごとに生成されます。シークレットは、ほかのデバイスと共有されません。デバイスは、チャレンジシークレットを単一のクライアント証明書に利用できます。

    以下を参照してください。

    Jamf Pro を使用して、macOSの動的SCEPチャレンジを使用するCAとしてOktaを構成する

  • Delegated SCEP URL（委任済みSCEPのURL）：Microsoft Intuneは、リクエストごとに一意のチャレンジシークレットを生成します。Oktaは、チャレンジシークレットを確認して、デバイスのクライアント証明書を生成します。

    以下を参照してください。

    • Microsoft Intune でmacOSの委任SCEPチャレンジを使用するCAとしてOktaを構成する

    • Microsoft Intune でWindowsの委任SCEPチャレンジを使用するCAとしてOktaを構成する

MDM SCEPポリシー構成は、例にすぎません。自分の組織のニーズに応じてSCEPポリシーを構成してください。

OktaをCAとして使用する証明書の取り消し

Oktaは、発行されたものの、成功した認証で90日以内に使用されなかったデバイス証明書を取り消します。

オプション：独自のCAを提供する

環境に次のいずれかがある場合、独自のCAを提供できます。

  • MDMソフトウェアと統合されたPKI
  • 既存のActive Directory証明書サービス（ADCS）インフラストラクチャ

独自のCAを使用するときは、証明書は次の前提条件を満たす必要があります。

  • 期限切れでないこと
  • RSAキーまたはDSAキーをサポート
  • 2048ビット以上のキー
  • BasicConstraints拡張機能（2.5.29.19）がCAであることを示す（パスの長さ >=0）
  • KeyUsage拡張機能（2.5.29.15）に証明書の署名が含まれる

Windowsの場合、クライアント証明書はマシンストアではなく、現在のユーザーの証明書ストアにあります。ローカルのマシン証明書ストアを使用せざるを得ない場合は、ユーザーが秘密鍵にアクセスするために昇格が必要ないことを確認してください。

macOSの場合は、クライアント証明書をデプロイするための適切なレベルを選択します。

  • デバイスのすべてのユーザーが確実に管理されるようにするには、コンピューターレベル（Computer Level）を選択します。

  • デバイスのMDMマネージドユーザーのみを管理対象として識別したい場合は、ユーザーレベル（User Level）を選択します。

すべてのアプリケーションでクライアント証明書が利用できることを確認します。「管理対象デバイス向けに独自の認証局を提供する」と「Appleデバイス向けのSCEP MDMペイロード設定」を参照してください。

独自のCAを使用する証明書の取り消し

独自のCAを提供する場合、Oktaは証明書の失効をサポートします。Oktaは、証明書失効リスト（CRL）で失効した証明書または保留中の証明書を確認し、それらの証明書による管理シグナルの送信をブロックします。Oktaは、HTTPプロトコルまたはHTTPSプロトコルを使用するCRLエンドポイントと、管理者がアップロードしたものと同じ中間証明書によって署名されたCRLのみをサポートします。クライアント証明書には、証明書配布ポイントのURI（Uniform Resource Identifier）も含める必要があります。

これらの条件が満たされると、OktaはCRLをダウンロードして、CRLにあるすべての証明書を取り消します。証明書失効タスクは、1日に数回実行されるバックグラウンドプロセスで実行されます。証明書が失効としてマークされた後、クライアントはその証明書を使用して管理ステータスを設定することはできません。システムログのイベントを確認して、証明書がいつ取り消されるかについての詳細を確認してください。