複数のSubject Alternative Name（以下、SAN）を設定したいのに、コマンドラインからCERTREQやcertutilを使うと最初のエントリしか反映されずに困っている方は少なくありません。Windowsの証明書管理では便利な機能が多い反面、細かい仕様によって躓きやすいポイントもあります。本記事では、そのようなSANを複数設定する際に起こりがちな問題点と、INFファイルを使った確実な回避策について詳しく解説します。さらに、取得した証明書の取り回しをスムーズにするワークアラウンドもご紹介します。
複数のSANが反映されない問題と主な症状
CERTREQコマンドもしくはcertutilコマンドを用いて証明書要求を行う際、複数のSANを指定したつもりが実際には最初の一つしか取り込まれないという事象が報告されています。たとえば、以下の例のように複数のDNS名を指定すると、最初の“entry1.contoso.com”だけが発行された証明書に含まれ、“entry2.contoso.com”や“entry3.contoso.com”が無視されてしまうケースです。
certreq -submit -attrib "CertificateTemplate:Appliance\nSAN:dns=entry1.contoso.com&dns=entry2.contoso.com&dns=entry3.contoso.com" cert.csrあるいは「SAN:dns=entry1.contoso.com,SAN:dns=entry2.contoso.com…」とカンマ区切りで書いても、期待通り複数のSANが適用されないという報告も多く見受けられます。
なぜ起こるのか
Windows Serverの証明書テンプレート機能には「Subject Name」を要求側で自由に上書きできる「Supply in the request」という設定があります。しかし、コマンドラインによるSAN指定は、テンプレート側の設定やcertreq/certutilのコマンド解釈に起因してうまく複数値が受け付けられないことがあるのです。
テンプレート設定とコマンドの不整合
テンプレートに「Supply in the request」が設定されていても、実際に運用されているCA（証明書認証局）のポリシーによっては、SANを自由に指定できないよう制限されていたり、コマンド引数の書式がバージョンや状況によって期待通りに認識されない場合があります。このため、複数SANを登録したつもりでも最初のエントリのみが採用されてしまうのです。
INFファイルを使用した確実な複数SAN設定方法
この問題を回避するための王道かつ確実な手段が、INFファイル（構成ファイル）を利用する方法です。これは、証明書要求（CSR）を作成する際に詳細情報を記述したINFファイルを用意し、そこに複数のSANを記述してからcertreq -newコマンドでCSRを生成する手順です。以下にサンプルのINFファイル例を示します。
[NewRequest]
Subject = "CN=example.contoso.com"
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10
KeyUsage = 0xa0
SuppressDefaultProviderPrompt = TRUE
[RequestAttributes]
CertificateTemplate = Appliance
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "DNS=entry1.contoso.com&"
_continue_ = "DNS=entry2.contoso.com&"
_continue_ = "DNS=entry3.contoso.com"上記のINFファイルでは、2.5.29.17（Subject Alternative Name拡張）を{text}形式で明示指定し、その後に複数のDNS名を“&”で繋ぎつつ_continue_行を使って複数行に分割することで、確実に複数のSANを設定できます。具体的な手順は以下のとおりです。
- 上記の内容を「request.inf」などのファイル名で保存します。
- コマンドプロンプトやPowerShell上で、次のコマンドを実行します。
certreq -new request.inf request.csr- 生成された「request.csr」をCAサーバーに提出します。たとえば社内のActive Directory Certificate Services（AD CS）ポータルやcertreqコマンドの
-submitオプションから送信し、証明書を取得します。
こうすることで、複数のDNS名が漏れなくSubject Alternative Nameに含まれたCSRを作成できるため、管理者が意図した形の証明書を確実に発行可能です。
INFファイルの書式に関する注意点
INFファイルの構文は少々独特です。_continue_という行を使うことで、一つのレジストリエントリを複数行でつなげる仕組みを取っています。この際、行末の“&”を取り除いてしまうと正しく解釈されず、SAN情報が分割されてしまう場合があるので注意してください。また、必ず[Extensions]セクションで拡張OID「2.5.29.17（Subject Alternative Name）」をテキスト形式で指定する必要があります。
KeyLengthやProviderNameのカスタマイズ
INFファイル内では、RSA鍵長やプロバイダ名などさまざまな設定項目を指定可能です。セキュリティポリシーやサーバー要件に合わせて、2048ビットより長い鍵長を使いたい場合は「KeyLength = 4096」といった形でカスタマイズしてみてください。
例:
KeyLength = 4096
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"このように書けば、より強度の高い暗号化鍵を使用できます。
テンプレート設定の確認と運用上のポイント
複数SANを設定できるようにするためには、Active Directory Certificate ServicesのCertificate Template設定も正しく行われている必要があります。具体的には、「Subject Name」タブの「Subject name format」が「Supplied in the request（アプリケーションまたはユーザーが指定）」になっている必要があり、「Include this information in alternate subject name」などのオプションも適切に有効化しておく必要があります。
管理者権限とGPOの影響
証明書関連の操作には管理者権限が必要なケースが多いです。特に、マシン証明書を扱う場合は「MachineKeySet = TRUE」とINFファイルに書く必要がある一方で、実行するユーザーがローカル管理者権限を持たないと証明書の格納先がおかしくなってしまうこともあります。また、グループポリシーで証明書の自動登録や発行ポリシーが構成されている組織環境では、カスタマイズしたリクエストが拒否されるケースもあるので注意が必要です。
取得した証明書の取り回し：PFXからPEM形式への変換
Windows環境で取得した証明書は、通常PFX形式（PKCS #12）としてエクスポートできます。しかし、外部アプライアンスや特定のサーバーソフトウェアによってはPEM形式（.keyと.crtに分離された形式）でのアップロードを要求されることがあります。そのような場合は、OpenSSLを用いて以下のステップで変換可能です。
| 手順 | コマンド例 | 補足 |
|---|---|---|
| 1. PFXから秘密鍵と証明書を分離 | openssl pkcs12 -in mycert.pfx -out mycert.pem -nodes | パスワード保護されたPFXを読み込み、PEM形式で出力 |
| 2. 秘密鍵と証明書を個別ファイルへ分割 | openssl rsa -in mycert.pem -out mycert.key openssl x509 -in mycert.pem -out mycert.crt | 秘密鍵（mycert.key）と証明書（mycert.crt）を抽出 |
| 3. 中間証明書チェーンを分割 | （必要に応じて）テキストエディタ等で中間CA部分を抽出 | アプライアンスによっては中間証明書を別ファイルで要求される |
このように、Windowsで得たPFXをPEM形式へ変換することで、多様なプラットフォームやアプライアンスに対応できます。
証明書チェーンの管理
最終的にアプライアンスなどに証明書をアップロードするときは、ルート証明書と中間証明書チェーンが必須となる場合があります。OpenSSLで抽出した中間証明書群をまとめて「chain.crt」として保存し、ルート証明書は別ファイルにすることも一般的です。設定画面やデバイスの機能によってアップロード形式は異なるため、マニュアルをよく確認しましょう。
コマンドラインでの複数SAN指定がうまくいかない理由と今後の可能性
一部のドキュメントでは、CERTREQやcertutilにおいて複数のSANを直接指定する方法が紹介されていることもあります。しかし、実運用で試すと通らないケースが多く、環境依存の不具合が隠れている場合もあり、Microsoft公式ドキュメントでも確実とはされていません。特に下記のようなパターンでエラーあるいは一部SANだけが取り込まれる場合があります。
- 「&」区切りや「,」区切りの解釈がコマンドプロンプトと内部のAPIで噛み合っていない
- テンプレートに「Supply in the request」が設定されていても、別のポリシーが上書きしている
- certutilのバージョンやOSビルドによってサポート状況が異なる
将来的にMicrosoftがcertreqコマンドやcertutilの仕様を拡張し、複数SAN指定をわかりやすくサポートする可能性はありますが、現状ではINFファイル方式が最も安定した方法となっています。
トラブルシューティングのポイント
複数のSANを設定する際、予期せぬエラーが出たり、証明書が正しく発行されなかった場合は、以下の点をチェックしてみてください。
1. INFファイルの構文確認
_continue_行に余計な空白や改行が入っていないか- OID指定（2.5.29.17 = “{text}”）が正しく書かれているか
- “&”でちゃんと繋がっているか（末尾に“&”を置く必要がある）
2. CA側の設定確認
- 「Certificate Templates」コンソールでテンプレートが正しく複製・設定されているか
- 「Supply in the request」が有効になっているテンプレートを使用しているか
- 余計なカスタムポリシー（サブジェクト名の強制書き換えなど）が動作していないか
3. PowerShellやcertutilを使った検証
INFファイルを使わずとも、以下のような検証を実行してエラーメッセージを確認できます。
certreq -new request.inf request.csr
certreq -submit -attrib "CertificateTemplate:Appliance" request.csr
certutil -dump request.csrcertutil -dumpでCSRの中身を確認し、SANが期待通りに入っているかチェックしましょう。また、取得後の証明書についてもcertutil -dumpや「証明書の表示」からSANを検証できます。
まとめ：確実に複数SANを適用するにはINFファイルが最適解
CERTREQコマンドやcertutilコマンド単体の引数で複数のSANを指定する試みは、環境や設定に応じてうまく働かないことが珍しくありません。誤ったコマンド書式やテンプレート設定の不整合があると、時間をかけても成果が得られず、発行された証明書に期待するSANが含まれないままになってしまいます。
INFファイルを使うと、サブジェクト名やキー設定、SANリストなどを明示的に指定でき、複数SANを含むCSRを簡単に作成可能です。さらに、組織内のセキュリティポリシーに準拠しながら証明書を発行できます。外部アプライアンスへの適用時にはPFXからPEMへの変換などのステップが必要になる場合もありますが、INFファイル方式で取得した正しいSAN入り証明書を用意しておけば安心です。
複数のホスト名をまとめて保護したい場合や、DNS名以外にもIPアドレスやメールアドレスなどをサブジェクトに含めたいときは、ぜひINFファイルベースのアプローチを検討してください。INFファイルによる証明書要求フローが定着すれば、サーバー管理や更新作業の効率化にも大いに役立つはずです。
コメント