認証局を構成する

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

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

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

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

デバイスがOkta Universal Directoryから削除されると、そのデバイスに関連付けられていた証明書は使用できなくなります。今後同じデバイスを使用するには、そのデバイスに関連付けられていた証明書を削除してから、新しい証明書を再デプロイする必要があります。

OktaをCAとして構成するには、モバイルデバイス管理（MDM）ソフトウェアでSimple Certificate Enrollment Protocol（SCEP）プロファイルを作成してから、OktaでSCEP URLを生成します。Oktaでは、SCEPチャレンジを生成するために次の方法を提供しています。

  • MDM SCEPポリシー構成は、例にすぎません。自分の組織のニーズに応じてSCEPポリシーを構成してください。
  • ［Static SCEP URL（静的SCEP URL）］：MDMソフトウェアは、すべてのデバイスに同じチャレンジシークレットを割り当てます。このデバイス管理構成では、チャレンジシークレットがデバイス間で共有されます。構成用に作成された共有シークレットが検証され、各デバイスに一意のクライアント証明書が発行されます。

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

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

    • 「Jamf Proを使用して、macOSの動的SCEPチャレンジを使用するCAとしてOktaを構成する 」を参照してください。

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

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

CAとしてのOktaは、更新リクエストをサポートしません。その代わりに、証明書の有効期限が切れる前にプロトコルを再配布して期限切れ証明書を交換します。プロトコルの再配布が許可されるには、すべてのMDM SCEPポリシーが構成されている必要があります。

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

独自のCAを提供する場合、Oktaは証明書の失効をサポートします。Oktaは、証明書失効リスト（CRL）で失効した証明書または保留中の証明書を確認し、それらの証明書による管理シグナルの送信をブロックします。Oktaは、HTTPプロトコルまたはHTTPSプロトコルを使用するCRLエンドポイントと、管理者がアップロードしたものと同じ中間証明書によって署名されたCRLのみをサポートします。クライアント証明書には、証明書配布ポイントのURI（Uniform Resource Identifier）も含める必要があります。これらの条件が満たされると、OktaはCRLをダウンロードして、CRLにあるすべての証明書を取り消します。証明書失効タスクは、1日に数回実行されるバックグラウンドプロセスで実行されます。証明書が失効としてマークされている場合、クライアントはその証明書を使用して管理ステータスを設定することはできません。システムログのイベントを確認して、証明書がいつ取り消されるかについての詳細を確認してください。

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

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

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

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

ルートCAによって取り消された中間CAは、手動で削除します。これらは自動的には削除されません。

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

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

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

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

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