登録方式

したがって、証明書登録プロトコルの中核となる特性は、証明書の要求者をどのように認証するかという点にあります。証明書の用途によって、どのプロトコルが有利かは変わります。

もう1つの重要な特性は、実際にどれだけ普及しているかです。対象とするユースケースにおいて、登録方式またはプロトコルが認証局側とクライアント側の両方でサポートされている必要があります。

代表的な登録プロトコルは次のとおりです。

• SCEP
• ACME
• EST
• MicrosoftのRPC/DCOM
• MicrosoftのSOAP
• 認証局のWebページでの手動登録
• その他の独自プロトコル

SCEP

歴史と仕様

Simple Certificate Enrollment Protocol（SCEP）を最初に考案したのはCiscoです。当時は標準がなかったにもかかわらず、MDMシステムで広く採用されました。Ciscoはさらに歩を進め、SCEPを置き換える後継プロトコルとしてEnrollment over Secure Transport（EST）を設計しています。そのためESTはRFC 7030として早くから公開標準になりましたが、SCEPがRFC 8894で標準化されたのはずっと後のことで、その時点ではすでにMDMシステムにおける証明書登録の事実上の標準になっていました。

技術

SCEPはHTTPベースです。SCEPリクエストは、暗号化および署名されたPKCS#7であり、GETまたはPOSTリクエストでSCEPサービスに送信されます。サービスはSCEPレスポンスを返しますが、これもやはり暗号化および署名されたPKCS#7です。リクエストにはPKCS#10の証明書署名要求が含まれ、レスポンスには発行されたX.509証明書が含まれます。

認証

PKCS#10リクエストには「SCEPチャレンジ」が含まれ、SCEPサービスごとに異なる帯域外の方法によって署名要求を認証および認可します。今日実際に使われているSCEPチャレンジは3種類あります。

静的SCEPチャレンジ

最も単純なのは固定のパスフレーズです。PKCS#10内のSCEPチャレンジがSCEPサービスに保存された既定値と一致すれば証明書が発行され、一致しなければ要求は拒否されます。この方式の問題は、要求された証明書の属性が要求者と合致しているかどうかをほとんど検証できない点にあります。この問題についてはCVEも登録されています。

これらの方式はさらに次のように区別できます。

1. 直接 SCEP登録の場合、証明書の登録対象となるエンティティがSCEPサービスと直接通信します。たとえばMDMシステムが、あるAndroid端末に対してSCEPチャレンジ「SecurePassword」を使ったSCEP登録を指示します。Android端末はCSRを生成し、できれば正しい値を設定したうえで、SCEPチャレンジとして「SecurePassword」を付加します。そしてCSRをSCEPサービスへ送信し、発行された証明書を受け取ります。
2. 透過型SCEPプロキシ は、HTTPのリバースプロキシとよく似たものです。SCEPは暗号化および署名されているため、プロキシがSCEPのリクエストやレスポンスの中身を実際に参照したり変更したりすることはできませんが、ネットワークの境界に基づいて、誰がいつ証明書を登録できるかを制御できます。
3. プロトコルアダプター型SCEPプロキシ は、他のシステムに代わってSCEPで証明書を要求するシステムです。たとえばJAMFのようなMDMシステムが、あるiPhoneに代わってSCEPサービスに証明書を要求できます。証明書と秘密鍵を受け取った後は、別のプロトコルでその証明書を配布できます。この方法であれば、SCEPチャレンジにアクセスできるのはMDMシステムだけであり、証明書の内容も制御できます。

動的SCEPチャレンジ

この場合、各SCEPチャレンジは1回の証明書要求にのみ有効です。これによりSCEPサービスはSCEPリクエストを識別し、要求された証明書の属性がその要求に許可されたものと一致するかを検証できます。

MDMシステムとSCEP認証局が、ある要求に使うSCEPチャレンジについて合意する方法は、実務上おおむね2つあります。

1. MDMシステムが必要に応じて、SCEPリクエスト用のワンタイムコードをSCEPサービスに要求します。
   1. その一例がMicrosoft NDESです。NDESには、AD資格情報で認証される独立した「管理者」ページがあります。このページにアクセスするたびに、1回のSCEPリクエストに使える新しいワンタイムコードが生成され、表示されます。ただしこの構成で使う場合、ワンタイムコードは汎用的なものであるため、NDESは証明書の属性を一切検証しません。
2. MDMシステムが、管理対象システムにSCEPでの証明書要求を指示する際にワンタイムコードを生成します。SCEPリクエストがSCEPサービスに届くと、サービスは通常Webフックを使ってMDMシステムからワンタイムコードを取得し、リクエスト内のSCEPチャレンジと一致するかを確認する必要があります。このやり取りには標準がないため、MDMシステムとSCEPサービスが何らかの形式について合意しなければならず、リクエストの属性が検証されるかどうかは実装次第です。

署名付きメタデータ

SCEPチャレンジの長さには事実上の制限がありません。そのため、人が読める「パスフレーズ」である必要はなく、BLOBであってもかまいません。

IntuneはSCEPチャレンジとして、署名および暗号化されたXMLを使用します。証明書を登録してSCEPリクエストを作成させたいときに、サーバー側でこのXMLを生成し、クライアントデバイスへ送ります。

SCEPサービスは、PKCS#10リクエスト全体をIntuneのSCEPチャレンジサービスへ送信しなければなりません。SCEPチャレンジサービスは、XMLを復号するための秘密鍵と、それが正規のIntuneサービスによって作成されたことを確認するための公開鍵を保持しています。

XMLには、Subjectがどのような値であるべきかといった、リクエストに関するメタデータが含まれます。この情報は、一方ではSCEP構成プロファイルから、他方では証明書の発行対象となるユーザーまたはデバイスの個別のオブジェクトデータから導き出されます。

たとえば、SCEP構成プロファイルでSubjectにCN={{DeviceId}}が設定されているとします。IDがxyzのデバイスが証明書を要求すると、XMLにはSubjectがCN=xyzであるべきだと記載されます。SCEPチャレンジサービスは、XMLの情報とPKCS#10リクエスト内のSubjectを比較します。Subjectが異なれば検証は失敗し、これと他の属性が一致すれば成功します。

SCEPサービスは、検証に成功した場合にのみ証明書を発行します。

Microsoftは、この検証について解説した記事を公開しています。

Microsoft NDESは追加のNDESポリシーモジュールでこれに対応します。他のSCEP認証局がこれをネイティブにサポートしているかどうかは製品によります。

Microsoft RPC/DCOM

歴史

Microsoft Active Directory Certificate Services（ADCS）は、単に「Microsoft CA」と呼ばれることもあり、Windows Serverに組み込まれた認証局ソフトウェアです。このソフトウェアはもともと前世紀の終わりに開発され、その後10年から15年ほどにわたって機能が追加されてきました。

代替となるのはMicrosoftのSOAPやSCEPで、MicrosoftはそれぞれをWeb Enrollment、NDESと呼んでいます。

仕様と普及状況

その後MicrosoftがMicrosoft OpenSpecで仕様を公開したとはいえ、このプロトコルを実装した他の認証局システムを当社は把握していません。クライアント側では、Windowsがこのプロトコルを標準でサポートしており、他のプラットフォームはサポート対象外です。

技術

主要な登録方式は、RPCまたはDCOMをベースとする独自プロトコルです。

自動登録もこのプロトコルを使用します。自動登録を機能させるには、次の条件が必要です。

• ドメインに参加したデバイス
• グループポリシーで自動登録が有効になっていること
• （スタンドアロンではなく）エンタープライズ認証局であること
• その認証局が証明書テンプレートを発行していること
• ユーザーまたはデバイスがそのテンプレートに対する登録および自動登録の権限を持っていること

自動登録を確認する既定の間隔は8時間ですが、certutil -pulse、あるいは多くの場合それ以上に有効なgpupdate -forceで強制実行できます。

認証

このプロトコルはActive Directoryに組み込まれた認証プロトコルを使用します。つまり、ユーザーとコンピューターはAD資格情報で認証されます。