仮想化エンジニア奮闘記

Citrix や VMware といったサーバー・デスクトップ仮想化の最新技術や設計情報の検証結果を共有します。(本ブログは個人のものであり、所属する会社とは関係ありません。)

UNCパスのファイルをdel処理する時は気をつけろ!

みなさまお疲れ様です。

最近は思いついたものを色々記事にしており、仮想系の記事が少ないですがすみません。

 

今回は Windowsバッチ や Powershell 等でUNCパスのファイルをdel処理で削除する際に気をつけた方がよいことを記載します。さっそく結論です。

pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理を入れること。エラーになっていた場合は、del処理を行わないこと。

 

例えば下記のような2つの処理を行っているスクリプトを考えてみます。

①ログなどのファイルをリモートのファイルサーバーにコピーする

②ログがたまり続けないように一定期間経過したファイルサーバー上のファイルは、スクリプト実行サーバーからローテーション処理をかける

 

f:id:kenta53682:20170618125415p:plain

 

forfilesでUNCパスはサポートされていないため、「pushdしてdel処理を行う」ことを考えるかと思います。

が、上記のスクリプトだと、pushdに失敗した時の条件分岐が入っていないので、pushd失敗時はデフォルトの作業ディレクトリで削除処理が走ります。

 

タスクスケジューラでは作業フォルダを指定しない場合、「C:\windows\system32」が作業フォルダとなります。(taskschd.mscがある場所だからだと思います。)

 

もうお分かりかと思いますが、pushd失敗時 (ファイルサーバーがシャットダウンされている場合など) はスクリプト実行サーバーの「C:\windows\system32」配下のファイルが削除される処理が走ります これはやばい笑

 

このような悲しいことが起きないよう、少なくとも①だけは必ず守りましょう!

①pushd や cd 等でUNCパスに移動をしてdel処理を流す際は、移動がエラーになっていないか必ず分岐処理(if)を入れる

②タスクスケジューラの「開始(オプション)」にて作業ディレクトリを明示的に指定する (or スクリプトの最初で必ず作業ディレクトリにcdする)

③forfilesでdel処理を行う場合、del対象の名前や拡張子が決まっている場合、「/m [ファイル名]*.[拡張子] のようにマスクを入れる

 

ちなみに、なぜこれを記事にしているかというと直近で私が「system32配下のファイルが削除される」問題を引き起こしてしまったからです。

OSリストアが必要となる大問題なので、スクリプト作る人もレビューする人も絶対条件分岐が入っているか意識して下さい。

SANスイッチの基本的な内容を覚えよう!

みなさまお疲れさまです。

本日はSANスイッチのあれこれについて共有します。本記事はSAN初級者向けの人をターゲットにした記事となります。

 

「SAN触ったことないけどなんだか難しそう!」って思っている方、僕もそうでした!

ですが、実はSANはポイントを押さえれば難しくありません!

むしろネットワークの方が色々機能があってよっぽど難しいです 笑!

 

 

本記事は下記のトピックでSANスイッチの記載をしてゆこうと思います。

①SANってどんな機器が必要なの?どう繋ぐの?

②SAN構築にあたって考えることって?

 

 

①SANってどんな機器が必要なの?どう繋ぐの?

SAN接続には大きく「サーバー」「SANスイッチ」「ストレージ」という3つの機器が関わってきます。

 

多くの方が、SANと聞くと光ファイバーで機器間が繋がっているイメージを持たれていると思いますが、実際そのイメージは当たっていて、SANでは光ファイバーケーブルを使用して8Gbps(最近では16Gpbs)等でデータ転送を行います。

 

光ファイバーで機器間を接続するために、サーバー・ストレージに「Host Bus Adapter」というFibre Channel Protocolをしゃべれるインターフェースを搭載する必要があります。PCI-Expressを使ってマザーボードと接続される、簡単に言うとSANにおけるNICの立ち位置のインターフェースです。

 

f:id:kenta53682:20170613215950p:plain

上記HBAの赤枠部分に光ファイバーケーブル(NICでいうところのLANケーブル)が挿されるわけですね。

 

サーバー側は上記のHBAを別途購入し、ストレージ側はSAN対応のモデルを買うと標準で上記のHBAがついてきます。

 

ここで1点注意事項です。サーバーHBA・SANスイッチ・ストレージHBAでは先の画像のように光ファイバーを接続できる口を搭載した状態で出荷されません。光ファイバーでつなぐためには、下記のように光ファイバーの口を別途購入する必要がある場合がほとんどです。その光ファイバーの口となるモジュールを「SFP+トランシーバーモジュール」と呼びます。(1個4~5万するので、機器発注する際は絶対に忘れないで下さい。)

f:id:kenta53682:20170613220128p:plain

 

従って、サーバー・SANスイッチ・ストレージ間は簡単に書くと下記のように接続されます。(下記は簡単に書いた図です。物理構成は②を参照して下さい。)

f:id:kenta53682:20170613220946p:plain 

なお、光ファイバーでサーバ・ストレージ間を直接接続することがサポートされている機器もあるようです。いわゆるDirect Attached Storage(DAS)なのですが、今回はSANの記事なので扱いませんし、実務でもDASをするなら安価なSASで接続することがほとんどかなと思います。(DASするくらいのお客様はコストを抑えたい、という気持ちが強いと思いますし。)

 

 

 

②SAN構築にあたって考えることって?

SAN構築にあたり考えることは多くありません。

基本は「冗長化」「ゾーニング」という2点を考えればよいです。

 

1) SANの冗長化

SANはサーバーとデータが配置されているストレージまでの経路を提供するものなので、機器障害時にサービス提供を維持できるように冗長化について考えなくてはいけません。

 

SANの冗長化については「物理的に異なる経路のパスを複数作る」という鉄則があります。この鉄則に従って下さい。

 

SANスイッチはStandaloneのSANスイッチが2台ある状態として導入することが推奨されています。この時、お互いのSANスイッチは連携をせず、物理的に異なるパスを作ります。この時、それぞれの経路をFabric A / B のように「Fabric」という単語で表します。

サーバーやストレージのHBAは多くが2口以上あるものなので、Standalone 2台のSANスイッチそれぞれに足を伸ばすことで「物理的に異なる経路のパスを複数作り」冗長化する形となります。

 

f:id:kenta53682:20170613223845p:plain

 

サーバー側ではマルチパスドライバーがインストールされている必要があり、通常時はストレージへのアクセスに経路①、経路②を負荷分散しながら利用します。経路①に障害が発生したら経路②のみでストレージへのアクセスを継続して提供する形となります。

 

設定は2台のSANスイッチに入れる必要がありますが、「1台に間違った設定を入れてストレージにアクセスできなくなった」のようなリスクを回避することができます。

 

 

2) SANのゾーニング

NWスイッチのVLANと似た機能として、SANスイッチでは「ゾーニング」という機能を持っています。ゾーニング設定を行うことで、ストレージにアクセスできるホストを絞ることができます。セキュリティ要件や問題発生時の影響を最小限にとどめるためにゾーニング設定を行います。

 

SANのゾーニングについては「1イニシエータ 1ゾーン」という鉄則があります。この鉄則に従って下さい。

 

ここでいう「イニシエータ」とはサーバーのHBAポートのことを言います。例えば下記の図のように、サーバーHBAポート毎にゾーンを分けるのが鉄則となります。

 

f:id:kenta53682:20170613232158p:plain

 

このゾーンはHBAポート毎に割り当てられるWWPN(World Wide Port Name)という値を元に設定します。WWPNはNICでいうMACアドレスと思って下さい。

 

サーバ側のWWPN・ストレージ側のWWPNを1つのゾーンに含めることで、あるサーバーHBAからアクセスできるストレージを限定することができます。

 

通常、ストレージは2コントローラあると思いますので、それを踏まえると実環境では下記のように冗長化 + ゾーニングが設定されていることが多いです。下記の図を見て頂いても、「1イニシエータ 1ゾーン」の鉄則が守られてると分かるかと思います。

ZoneA:Server HBA① WWPN、Controller A HBA① WWPN、Controller B HBA① WWPN が含まれる

ZoneB:Server HBA② WWPN、Controller A HBA② WWPN、Controller B HBA② WWPN が含まれる

 

f:id:kenta53682:20170613234805p:plain

 

実はSANスイッチ構築にあたり独自で考えることは多くなく、基本的には鉄則に従って構築を行うことが重要です。

 

SANスイッチはIBM・HP・富士通・日立・Brocadeなど各ベンダーから製品が出ていますが、多くの製品がHWは各ベンダー固有のものを使いつつも、OSはBrocade社のFabricOSが使われています。Brocade社はSAN界隈ではよく出てくる会社名なので覚えておくとよいと思います。

 

なおBrocade社は下記SlideshareのようにSANに関する記事を多く公開しています。

参考にしてみて下さい。

 

【参考サイト】Brocade Slideshare (日本語記事も数多くあります!)

 Brocade presentations channel

 

それでは本日は以上となります。長々とありがとうございました。

Citrix XenDesktop 7.14がリリースされました

今日はストレージの記事と2本だててブログ書きます。(こっちは短いです 笑)

 

5月23日~25日にかけて、フロリダ州のオーランドでCitrix Synergyがありました。

(私はまだ行ったことがないのですが、仮想化エンジニアとしてはいつか行ってみたいですね。)

 

Synergyのタイミングと合せて、XenServer 7.2 そして XenDesktop 7.14 のリリースが発表されました。

 

個人的に、XenDesktopはマイナーバージョンが14まで来るとは思わなかったです。

XenDesktop 7.14のWhat's newはまだ見切れていないですが、追々時間があれば共有や検証をしたいと思います。

 

ちなみに、XenDesktopの次のバージョン 7.15 はLTSRを予定しており、2017年秋に発表される予定となっています。

 

2016年は自治体情報システム強靭性向上モデル等で、インターネット分離ソリューションとしてXenAppを導入されているお客様が多かったと思います。

 

上記導入では大方 XenDesktop / XenApp 7.6 を導入されていたかと思いますが、

7.6もだいぶ古く(自分がエンジニア2年目=2014年?とかの時リリースでしたもん笑)

ようやく次期LTSRリリースが近づいてきたか、という感じですね。

 

なんかXenDesktop 7.0 とかの時に Project Avalon とか名付けられていたのが懐かしいですわー。当時は厨二っぽくてめっちゃかっこいいと思った 笑

上記ネタが分かる人はCitrixオタクですね 笑

 

以上です。ありがとうございました。

ストレージ・SANスイッチリプレース時の移行方針について

みなさまお疲れ様です。

今回はストレージとSANスイッチが保守切れになり、リプレースする必要が出てきた場合、どのような移行ステップを考えればいいかを記事にします。

 

本記事では一例として「SANスイッチと一部のストレージが保守切れでリプレースの必要あり」という状況を考えてみましょう。

下記の図で赤点線部分をリプレース対象とします。「OLD Storage」はESXi用にデータストアを提供しているストレージと仮定します。

 

f:id:kenta53682:20170607212435p:plain

 


提案に当たって、下記3ステップを見据えておく必要があります。
①現状調査
②互換性の確認
③移行方針の検討

 


①現状調査
次の「②互換性確認」のために必要となる作業です。
SANスイッチに接続されているサーバー・ストレージの情報を確認します。
下記の情報をまとめておくと②でベンダーへの確認がスムーズになると思います。
・現行サーバー:OSバージョン
・現行サーバー:HBA Firmwareバージョン
・現行サーバー:HBA Driverバージョン
・現行SANスイッチ:FabricOSバージョン
・現行SANスイッチ:空きポートの確認
・現行ストレージ:Controller Firmwareバージョン
・現行ストレージ:SFPモジュール搭載状況、HBA空きポート状況確認


②互換性の確認
SANスイッチをリプレースする場合、新規SANスイッチはFabricOSが最新バージョンになるはずです。

 

この時、サーバー側のOS / HBA Firmware / Driver、ストレージ側のController Firmwareの互換性を確認する必要があります。具体的には下記を確認する必要があると考えられます。

 

互換性確認1 現行サーバー ⇔ 新SANスイッチ ⇔ 新ストレージ の互換性
◆新SANスイッチ、新ストレージが現行サーバーOSと互換性があること
→対応していないとOSバージョンアップが発生する恐れあり

 

◆新SANスイッチ、新ストレージが現行サーバーHBA Firmware / Driverと互換性があること
→対応していないとHBA Firmware / Driver バージョンアップが発生する恐れあり
→また、HBA Firmwareをバージョンアップする場合、現行SANスイッチとの互換性も確認 (移行時に事前作業としてFirmwareを上げるため)

 

※互換性確認1で、現行サーバーをサポートするFabricOSバージョンを確定させる

 

互換性確認2 現行ストレージ ⇔ 新SANスイッチ の互換性
◆現行ストレージコントローラーのFirmwareと1)で確定させたFabricOSバージョンの互換性があること
→対応していないとController Firmwareバージョンアップが発生する恐れあり
→また、Controller Firmwareをバージョンアップする場合、現行SANスイッチとの互換性も確認 (移行時に事前作業としてFirmwareを上げるため)
→下手をすると現行ストレージがサポートされないリスクあり

 

f:id:kenta53682:20170607213435p:plain

 

互換性確認3 現行SANスイッチ ⇔ 新ストレージ の互換性
◆現行SANスイッチのFabricOSと新ストレージの互換性があること

→データ移行の際に、現行SANスイッチに新ストレージを接続するため確認

→対応していないと現行SANスイッチのFabricOSのバージョンアップが発生する恐れあり

 

 

特に互換性の確認が取れないまま提案を進めると(そんなことは100%ないはずですが)
「いざ実作業を始めて問題が起き、サポートされない構成だと判明した」
「OSやHBAバージョンアップなど予想外の作業ボリュームとなり大赤字」
ということになりかねません。

 

 

③移行方針の検討
互換性まで確認ができたら、最後に移行方針を検討します。
規模が大きくないお客様であれば、提案時にある程度移行方針を固めると思います。

下記では移行方針の一例を記載します。

 

移行ステップ1 現行サーバー・ストレージのFirmwareバージョンアップ
まずは事前作業として、現行で稼働しているサーバー・ストレージのFirmwareバージョンアップ作業を行います。
②の確認結果に基づき、必要な機器のみバージョンアップを行います。

 

f:id:kenta53682:20170607213813p:plain

 

 

移行ステップ2 データ移行のため、新ストレージと現行SANスイッチ間のパスを作る
次の手順で行うデータ移行のため、現行ストレージと新ストレージ間のパスを作ります。
新ストレージにHBA空きポートが2つない場合、移行期間中は暫定的に1パスだけで運用を行うようお客様と調整する必要があります。
また、現行SANスイッチ側ににゾーニング設定が必要となります。

f:id:kenta53682:20170607213843p:plain

 


移行ステップ3 仮想マシンデータ移行
現行ストレージから新ストレージに対してvmdkを移行します。
ESXiホストから見ると現行ストレージ・新ストレージ両方が見える状態なので、Storage vMotionが可能です。

 

f:id:kenta53682:20170607213917p:plain

 

移行ステップ4 機器移行
すべての仮想マシンのStorage vMotionが終了したら、いよいよ機器を新SANスイッチに移行します。
一気に機器移行は問題発生時のリスクが大きいので、徐々に移行する方法が無難です。
接続して新ストレージが認識できない等があれば、旧SANスイッチ側に機器を切り戻して調査を行うなどの対応が可能です。

f:id:kenta53682:20170607213942p:plain

 

 

移行ステップ5 現行SANスイッチ・新ストレージ間のパス切断
移行のために準備した現行SANスイッチ ⇔ 新ストレージ間のパスを切断します。
旧SANスイッチと旧ストレージはそのまま撤去する流れとなります。

f:id:kenta53682:20170607214008p:plain

 
以上長文でしたがありがとうございました。SANの記事って意外と少ないですよね。
この記事が同じ悩みを抱えている方の助けになれば幸いです。
但し、移行方法についてはお客様環境毎にBestなものは変わります。本記事をベースにお客様にあった移行方針を考えるようご注意下さい。

Unity VSAを試してみた(2)ー FAST VPとは?

みなさまお疲れ様です。

5/27-28にかけて自宅の検証環境にNSX for vSphereをデプロイし、ついに我が家にSoftware Defined Data Center(SDDC)が実現しそうです 笑

 

さて今回も引き続き、Unity VSAの記事を書きます。前回の記事は↓参照。

Unity VSAを試してみた(1)ー Unity VSAのデプロイ - 仮想化エンジニア奮闘記

 

◆FAST VPとは?

FAST VPはFully Automated Storage Tiering for Virtual Poolsの頭文字を取った単語で、ストレージプール内を下記のように3階層に分け、データのアクセス状況や使用頻度を分析して自動的に適切な階層へデータを移動させる機能です。
SSD   :最大パフォーマンス階層
SAS   :パフォーマンス階層
③ NL-SAS     :容量階層

 

f:id:kenta53682:20170530004744p:plain

 

SSD数を抑え、NL-SASで容量を確保することでコスト削減をしつつも、パフォーマンスの最大化を図れる点がFAST VPのメリットとなります。

 

なお、Unity VSAではFAST VPが各仮想ディスクに適したストレージ階層を自動的に区別し、割り当てることはできないため、プール作成時に各仮想ドライブにストレージ階層を手動で割り当てる必要があります。

 

Unity VSAでFAST VPを使うには、下記のように共有またはローカルディスクの割り当てを行う形になるかと思います。なお、私の自宅環境では「ESXiのローカルディスクを使ってUnity VSAを使う」方式でFAST VPを実装しています。

 

f:id:kenta53682:20170530010421p:plain

 

 

◆FAST VPの設定について

先述の通り、Unity VSAではプール作成時に各仮想ドライブが3階層のうちどの階層に所属するかを手動で設定します。この階層設定はプール作成後、変更できないため注意して下さい。

1) まず、Unity VSAにディスクを追加します。この時、ディスクは「Thick Provisioning Eager Zeroed Thick」が推奨です。ディスク追加時にゼロ書き込みが行われるため、容量が多いと時間がかかりますが、タスク終了まで待ちましょう。

キャプチャを取った段階で既に実運用中のプールがあるのでディスク数が多いですが、13番目の100GBのディスクを追加しています。

 

f:id:kenta53682:20170530204105p:plain

 

2) Unisphere管理コンソールにログイン後、プールを作成します。任意の新規プール名を設定します。

 

3) そして本画面で仮想ディスクがどの階層に所属するかを選択します。SSDSAS、NL-SASに応じて階層を選択してプールを作成します。

f:id:kenta53682:20170530204603p:plain

 

4) プール作成後、プールのプロパティを開くと、下記のようにどのディスクがどの階層として設定されているかを確認することができます。

f:id:kenta53682:20170530204912p:plain

 

5) FAST VPの設定ではデータ再配置のレートやスケジューリングが設定可能です。

f:id:kenta53682:20170530205300p:plain

 

次回はFAST VPの動作検証をやってみようと考えています。

なお、Fast VPの詳細はこちらのホワイトペーパーにも記載されていますのでご参照下さい。

 

それでは本日は以上となります。ありがとうございました。

Unity VSAを試してみた(1)ー Unity VSAのデプロイ

みなさまお疲れ様です。

 

本日は、DELL EMCから発表されているUnityVSA(Virtual Storage Appliance)を検証で使用したので共有致します。
今後はVMware Virtual Volumes(VVOL)の検証に使う予定のため、VVOLの記事も後々書こうかと思います。

 

◆Unity VSAとは

Unity VSAはDELL EMCのユニファイド ストレージ(※)で、VMware vSphere環境にデプロイして使用できるストレージアプライアンスです。

※ユニファイドストレージとは、ブロックストレージもファイルストレージもいけるストレージのことです。簡単に言うと、SAN(Unityは物理のみ対応)(ブロック)・iSCSI(ブロック)・NFS/CIFS(ファイル)対応できるストレージのことを指します。

 

オール フラッシュ ミッドレンジ データ ストレージ – Unity | Dell EMC Japan

 

Unity自体は物理ストレージとしても販売されていますが、VSAはUnityとほぼ同様の機能・管理コンソールを備えた仮想アプライアンスとなります。

「物理ストレージを置くほどではないかな。」というような支店・拠点・クラウド等に導入し、本社のUnity(物理) ⇔ 支店・拠点等(仮想) で相互レプリケーションを行うといった構成も可能となるため、ターゲットとしては上記のとおり支店や拠点やクラウドへの配置、またはUnity(物理)を設定変更する前の検証用途で使えるのではないかと考えています。

 

Unity VSAは無料版もあるため、私のように自宅の環境でストレージを使ってみたい、という方にもおススメかなと思います。(今まではLinuxWindows ServerでNFSサーバーを立てていましたが、VMwareとの連携機能が使えず不満がありました 笑)

 

物理と仮想でUnityの機能差がありますが、こちらはネットワールド様の記事が参考になるかと思います。無料版だとデータストアサイズが4TBまでとなります。

ネットワールド らぼ: ★Unity&Unity VSAリリース★

 

◆Unity VSAのデプロイおよび設定手順について

実はこのブログで手順を紹介するまでもなく、EMC Community Networkにて検証をして下さった方がいらっしゃるので、Unity VSAのデプロイや設定手順についてはそちらをご参照頂ければと思います。(DELL EMCにより正式にサポートされていない点はご認識下さい。とはいえ非常に役立つ資料かと思います。)

 

https://community.emc.com/docs/DOC-54344

 

1点、上記資料で私が異なる手順を取ったのが、Unity VSAアプライアンスの管理IPをセットアップするとき、仮想マシンコンソールにつないでIPをセットするコマンドを打ちました。

(上記資料だとConnection Utilityを使用しています。Unity(物理)をセットアップする時もConnection Utilityを使うと思うので汎用的だと思います。)

> svc_initial_config -4 "IPv4 Netmask Gateway"

 

あと、ストレージコンソールの証明書更新するときは下記手順でできます。

1) 秘密鍵を [xxxx.pk] と名前変更する。証明書を [xxxx.crt] と名前変更する。

2) Unity VSAの任意のフォルダにSCP転送する。

3) 手順2でSCP転送したフォルダにディレクトリ移動後、下記コマンドを実行する

> svc_custom_cert [xxxx]

※この時、秘密鍵「.pk」や証明書「.crt」の拡張子を除いたファイル名を指定するのがみそです。

 

◆Unity VSAでNFS / iSCSI / Virtual Volumesを作ってみた

というわけで、自宅のESXiにUnity VSAで作ったNFS / iSCSI / VVOLをマウントしてみました。うーん。壮観!!!

(私の環境ではサーバーに容量が大きいローカルディスクを搭載し、Unity VSAにハードディスクとしてアタッチして疑似共有ストレージとして運用をしています。)

f:id:kenta53682:20170525210828p:plain

 

というわけで、次回はVVOLのSoftware Defined Storage(SDS)やUnity VSAのFast VPの機能に触れらればいいなと思っています。

 

それではありがとうございました。

 

Google Chromeで[missing_SubjetAltName]エラーが出る

皆さんお疲れ様です。

 

最近自宅の環境でChromeバージョンアップ後に「missing_SubjectAltName」エラーが出て対応を行ったので備忘録として残します。

↓ なエラーです。

f:id:kenta53682:20170525203014p:plain

 

Chrome 58では下記のニュースのように従来の「Common Name (CN)」ではなく「Subject Alt Name」にFQDN(もしくはIP)が入っていないとエラーになるようです。

 

Chromeがコモンネームの設定を非推奨化、そのエラー対策としての自己署名証明書のCSRの作り方

 

Subject Alt Nameってどこよ?って方、簡単にいうと ↓ ここです。

下記はGoogleサーバー証明書ですが、「サブジェクト代替名」というのが「Subject Alt Name」です。

f:id:kenta53682:20170525200533p:plain

 

さて、私の自宅検証環境ではActive Directory Certificate Services(ADCS)により証明書を発行しています。この時、CSRにSubject Alt Nameを含めるにはどうすればよいか?下記に手順を記載します。

 

①Webサーバー用証明書テンプレートの設定を確認する

ADCSのWebサーバー証明書テンプレートをコピーした場合、既定で「サブジェクト名は要求に含まれる」という設定が入っています。そのため、CSR生成時にSubject Alt Nameを含めるようにしなければなりません。

逆に、「Active Directory の情報から構築する」の場合、「代わりのサブジェクト名に次の情報を含める」設定が「サブジェクト代替名に何を入れるか?」という設定で、「DNS 名」を入れるとSubject Alt NameにFQDNが入ります。

 

f:id:kenta53682:20170525201112p:plain

 

とはいえ、Webサーバー用の証明書なので、ドメイン参加したWindowsコンピューター以外にも発行したいですよね?基本は「Active Directoryの情報から構築する」という設定にはしていないと思います。それでは、CSRにSubject Alt Nameを含めるしかありません。mmcでCSRを作る時、Subject Alt Nameを含めるには次の手順を行います。

 

②mmcからSubject Alt Nameを入れた証明書を発行する

 

1) mmcを開き、証明書スナップインを開きます。新しい証明書要求の要求を行います。

f:id:kenta53682:20170525201829p:plain

 

2) 「開始する前に」「証明書登録ポリシーの選択」はそのまま「次へ」で進みます。「証明書要求」では赤枠部分を選択し、CSRサブジェクトをカスタマイズします。

(Webサーバー用テンプレートのセキュリティ設定で、mmcを実行しているコンピューターに対して「登録」権限をつけることを忘れないで下さい。忘れるとこの画面でテンプレートが表示されません。)

f:id:kenta53682:20170525202108p:plain

 

3) そうするとこのような画面が出てきます。「別名」という欄が「サブジェクト代替名に何を入れるか?」という設定なので、プルダウンから「DNS」を選択し、FQDNを入れて下さい。

f:id:kenta53682:20170525202237p:plain

 

3)の手順を踏み、証明書を発行することで、「サブジェクト代替名」にFQDNが入り、Chromeで証明書エラーがなくなります。ちなみに、Internet ExplorerではSubject Alt Nameがなくても全然問題はありませんでした。(が、そのまま放置しているとセキュリティ脆弱ポイントとなるので証明書を運用されている方は気にしてみて下さい。)

 

全然話は変わりますが、mmcで証明書を発行するとどうしても秘密鍵だけをエクスポートすることができません。(.pfxで秘密鍵付きの証明書としてエクスポートすることは可能)

秘密鍵を抽出したい場合はOpen sslを使って.pfx → .pemに変換して抽出ができました。

詳しくは ↓ をご確認下さい。

 

Tech TIPS:Windows上で、証明書や秘密鍵をPEM形式に変換してエクスポートする (1/2) - @IT

 

それでは本日は以上です。ありがとうございました。