AzureStack統合システムの証明書更新(Extension Host準備)

Azure Stack統合システムは必要ポート数を少なくするためにExtension Hostという機構を導入します。そのために既存のAzure Stackオーナー含めて1811Updateを導入するまでに新しく追加される2つのワイルドカードSSL証明書を追加する必要があります。

参考:Enhance security and simplify network integration with Extension Host on Azure Stack | Blog | Microsoft Azure

というわけで、私も証明書の更新作業をしたのですが一部ミスをして無駄に時間を使ってしまったこともあり…(反省)…顛末を記録しておきます。

作業の流れ

作業は以下の流れになります。

  1. 新しい証明書要求の作成
  2. 証明書への署名
  3. 証明書のインポートとエクスポート
  4. 証明証のテスト
  5. 証明書の入れ替え

新しい証明書要求の作成

証明書の作成は証明書要求(CSR)を作成し、それを証明局にて署名してもらう流れになります。Azure Stack用のCSRの作成は以前は苦労して自分で準備する感じでしたが今は作成ツールが用意されており相当楽になりました。ドキュメントも更新されています。

まず下記のページに証明書の要件が記載されています。が、これを加味したCSRを作成してくれるツールが用意されているので極論を言えばこちらは理解しなくても作業的には大丈夫です。(でも理解しておくのがもちろんベターです。)

そして、実際のCSRの作成方法は以下のページに記載されています。

実際の作業はReadinessCheckerというツールを使って行います。マニュアルどおりなので簡単です。

注意点1

私がハマったポイントの1つ目のポイントですが、このReadinessCheckerのバージョンが古いと肝心のExtension Host用のホスト名が追加されていないという状況になりますので注意してください。必ず最新バージョンで作業を行ってください。

Generate Azure Stack Public Key Infrastructure certificates for Azure Stack integrated systems deployment | Microsoft Docs の下のクローズされたFeedBackに私の残念な投稿が…。欧米の方はこういうときにとても優しいコメントをくれるので助かります(笑

image

下記のAzure Stack PowerShellのドキュメントにAzure PowerShellの既存バージョンのアンインストール方法も記載がありますので参考に…。

 

結局これでStart-AzsReadinessCheckコマンドレットを作成してCSRが作成できることになります。

 

証明書への署名

次に証明書要求にたいして認証機関で署名をします。公的なところにリクエストするのであればあとはお任せ…なのですが、私の今回のケースではWindows Serverで構築したEnterprise CAで署名を行いました。

注意点2

この際に、ReadinessCheckerで作成した証明書要求だと「テンプレート要求」が含まれておらずそのままでは証明書を発行できません。

さらに、以前のAzure Stackの証明書は「サーバー認証」のみで良かったのですが今回ExtensionHostに対応させるためには「サーバー認証」に加えて「クライアント認証」も有効にしてあげる必要があります。

こちら、回避方法は色々とあると思いますが、私はEnterprise CA側にて新規に「サーバー認証」と「クライアント認証」を有効化した証明書テンプレートを(複製して)作成しそれを利用しました。

このあたり私も詳しくないのですが、Windows ServerのStandaloneCAだとこのあたり特に気にせずに証明書発行できるようです。Enterprise CAの「テンプレート」の概念は私もう少し勉強が必要です…。

証明書テンプレートの作成、公開まわりは下記ブログ記事が参考になりました。(いつも)ありがとうございます。

 

証明書のインポートとエクスポート

証明書が発行できたらそれを証明書要求を作成したPCで取り込み、さらに秘密鍵つきでエクスポートします。これもドキュメントにまとまっていますのでそのとおりで大丈夫です。

最近はドキュメントに画像もつけてくれるようになりましたし本当にわかりやすくなりましたよね!

 

証明書のテスト

こちらもドキュメント通りで大丈夫です。

エラーがでたら無視せずに立ち止まって対処しないといけません。

 

証明書の入れ替え

証明書の入れ替えは下記のドキュメントに従って行います。

注意点3

証明書の入れ替えはかなり長時間がかかります。10時間は見ておくて良いです。私はよく理解せずに当初証明書を自分のNotePCの共有に配置してシークレットローテーションを実行してしまいました。12時くらいに実行して…18時くらいになって終わったのかどうだかよくわからない状態で(理由は後述)自宅に帰ってしまいました。これは大変よくなかったです。HLH上に作業用の仮想マシンを構築し、Azure Stackと常時つながっている環境を用意して、そこに証明書も配置してPowerShellコマンドを実行すべきです。(反省を込めて…)

 

そして、残念ながら私の場合にはこのときにERCSのメモリ不足の障害も併発してしまっていたようで、実行している最中にRemotePowerShellのセッションが切れてしまい、結果がきちんと確認できない状態になってしまいました。現在私の触っている環境ではこのようにERCS自体が不安定になり様々なエラーが散発してしまう次期が一時期ありました(その後のUpdate後に発生しなくなった模様です)。長時間かかる処理を行いたい場合には「普段使っていないERCSに接続して処理を流す」ということも現実的な選択肢として考慮に入れておくのが良いと思います。

 

注意点4

ドキュメントにも記載がありますが、証明書の更新処理は失敗することもあるようです。

シークレットのローテーションが済むまで待ちます。
シークレットのローテーションが正常に完了すると、コンソールに [Overall action status: Success](全体的なアクションの状態: 成功) と表示されます。 > [!note]
> シークレット ローテーションが失敗した場合、エラー メッセージの指示に従い、-Rerun パラメーターを付けて start-secretrotation を再実行します。 シークレット ローテーションの失敗が繰り返される場合、サポートにお問い合わせください。

失敗した場合には「-Rerun」のパラメーターをつけて再実行する必要があります。これ非常に重要です。なぜなら私は前述のようにRemotePowerShellが切れてしまったことも相まってよくわからず「-Rerun」をつけずにもう一度実行してしまったのですが、なんと最初の更新作業は成功しておわっていたのに2回目に実行してしまったのです。そして2回目が正常に終わらずエラーとなり、なんどやっても症状変わらず結局サポートに問い合わせて解決してもらう羽目になったからです…。

 

でも、これで証明書の更新作業はおしまいです。今後はExtension Hostの効果で証明書のホスト名追加…ということはもう無いと思いますので次は証明書の期日切れに更新する感じになると思います。

子供3人。家族優先。都内SIer勤務。Windows系中心のインフラよりの何でも屋。脱原発。 Microsoft MVP for Cloud and Datacenter Management.

コメントを残す

メールアドレスが公開されることはありません。