2021年5月29日土曜日

DockerコンテナのベースイメージをCentOSからAlmaLinuxに移行する

先日正式リリースされたAlmaLinuxについて、ESXi上の仮想マシンとしてインストールする手順を以下に記載した。

インストール手順や使い勝手は、当然RHEL 8やCentOS 8と遜色なく使えることは確認できていたので、今回はDockerコンテナとして使用するベースイメージをCentOSからAlmaLinuxに移行することにした。

具体的には、CentOSをベースイメージとしたSquid、Postfix、Unboundのコンテナ用のDockerfileを流用し、ベースイメージのみCentOSからAlmaLinuxに変更を行うだけで、AlmaLinuxのコンテナが動作することの確認を行った。

環境

  • Docker : 19.03.14
  • コンテナ : Squid用コンテナ
なお、CentOSをベースイメージとしたコンテナ作成時の記事は以下を参照すること。

ベースイメージ変更手順

1. AlmaLinuxのイメージを取得

AlmaLinuxのイメージ名をまずは入手するため、docker searchで検索してみる。いくつかイメージが表示されるが、「The official build of AlmaLinux OS」と記載されているalmalinuxが公式イメージとなる。なお、旧イメージとなるalmalinux/almalinuxは、DEPRECATION NOTICEと記載がある通り非推奨イメージとなるので注意。

# docker search almalinux
NAME                                 DESCRIPTION                                     STARS               OFFICIAL            AUTOMATED
almalinux/almalinux                  DEPRECATION NOTICE: This image is deprecated…   6
iloreto/almalinux                    AlmaLinux with Epel                             1
almalinux                            The official build of AlmaLinux OS.             1                   [OK]
roccqqck/almalinux-ssh               almalinux openssh-server                        0

~(以下略)~

Docker HubのURLは以下となる。

本イメージをdocker pullで入手する。

# docker pull almalinux
Using default tag: latest
latest: Pulling from library/almalinux
6648a3e8296a: Pull complete
Digest: sha256:2b91d8dce1a9ab0fa770786fc83bd8b2ca0cb66e6bc34a4a692c685bdb78877d
Status: Downloaded newer image for almalinux:latest
docker.io/library/almalinux:latest

# docker images almalinux
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
almalinux           latest              493af99fcc06        2 weeks ago         190MB

2. Dockerfileを編集

CentOS用で作成済みのDockerfileはそのまま流用できると想定し、以下★箇所に記載のFROMのベースイメージ指定をcentosからalmalinuxに修正する。

# cat Dockerfile
FROM almalinux ★

ENV TZ=Asia/Tokyo \
    http_proxy=http://192.168.33.23:8080 \
    https_proxy=http://192.168.33.23:8080
RUN dnf install squid -y

COPY squid.conf /etc/squid/
RUN /usr/sbin/squid -N -z

EXPOSE 8080
CMD ["/usr/sbin/squid", "-N", "-f", "/etc/squid/squid.conf"]

3. イメージをビルド

先ほど修正したDockerfileを使用して、docker buildでイメージをビルドする。特にエラーなく一発でイメージ作成が成功するはずだ。

# docker build -t almalinux-squid:1 .
Sending build context to Docker daemon   5.12kB
Step 1/7 : FROM almalinux
 ---> c2fc9360164e
Step 2/7 : ENV TZ=Asia/Tokyo     http_proxy=http://192.168.33.23:8080     https_proxy=http://192.168.33.23:8080
 ---> Running in 2f389328fe79
Removing intermediate container 2f389328fe79
 ---> aeeb11d5bf8a
Step 3/7 : RUN dnf install squid -y
 ---> Running in 0a9131d735d2
determining the fastest mirror (91 hosts).. done.
AlmaLinux 8 - BaseOS                            1.0 MB/s | 4.4 MB     00:04
AlmaLinux 8 - AppStream                         1.7 MB/s | 6.9 MB     00:04
AlmaLinux 8 - PowerTools                        798 kB/s | 2.1 MB     00:02
AlmaLinux 8 - Extras                            6.2 kB/s | 3.6 kB     00:00

~(中略)~

Step 7/7 : CMD ["/usr/sbin/squid", "-N", "-f", "/etc/squid/squid.conf"]
 ---> Running in 8dd10f52851d
Removing intermediate container 8dd10f52851d
 ---> 45a92ef9bfe7
Successfully built 45a92ef9bfe7
Successfully tagged almalinux-squid:1

4. AlmaLinuxのコンテナを起動

docker runで起動させると問題なく起動にも成功した。

# docker run -d -p 8080:8080 --name "almalinux-squid" -v /var/log/docker/almalinux-squid:/var/log/squid almalinux-squid:1
50204f614b2357739e090c2947769369942ae85d4a3d7b8faab9b01db17d9972

# docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
50204f614b23        almalinux-squid:1   "/usr/sbin/squid -N …"   3 seconds ago       Up 2 seconds        0.0.0.0:8080->8080/tcp   almalinux-squid

まとめ

AlmaLinuxはCentOS 8の代替ディストリビューションとしてリリースされたというだけあって、Dockerfileに記載のベースイメージの変更を行うだけで、問題なくコンテナが起動することが確認できた。

本記事ではSquidのコンテナのみ実行結果を記載したが、PostfixやUnboundにおいても、ベースイメージ変更は問題なく実施できており、AlmaLinuxへの移行は簡単できることを確認できた。

更新履歴

  • 2021/4/7 新規作成
  • 2021/5/29 Docker Hubのイメージ名がalmalinuxに変更となったことに伴い、手順を更新

2021年5月25日火曜日

QNAP NASで定期的なスナップショット取得を設定する

自宅では2017年に購入したQNAP TS-231PをCIFSのファイルサーバとして現役で利用している。QNAP NASのOSはQTSと呼ばれるが、QTSはバージョンアップを重ねるごとに機能強化がされており、現在のバージョンではボリュームに対してスナップショットの取得ができるようになっている。

今までは、スナップショット機能が実装前にボリュームを作成したことにより取得することができなかったが、先日物理ディスクの交換時にボリュームの再作成を行った。これにより、ボリュームに対してスナップショットを取得できるようになったので、定期的なスナップショット取得をするよう設定してみた。

本記事ではQNAP NASのボリュームに対して、定期的なスナップショットを取得する手順を記載する。

環境

  • QNAP NAS : TS-231P
  • QTS : 4.5.1.1540

手順

1. スナップショットマネージャーを開く

QNAPのWeb管理画面にログインし、「ストレージ&スナップショット」を開く。

左メニューから、「ストレージ」→「ストレージ/スナップショット」を選択してボリューム一覧を表示させたのち、スナップショット取得対象のボリュームを選択する。

ボリューム選択後、左上にある「スナップショット」→「スナップショットマネージャー」を選択し、スナップショットマネージャーを開く。

2. スナップショットのスケジュールを設定

「スナップショットのスケジュールを設定する」のボタンを選択すると、「スナップショット設定」のポップアップが表示される。ここでは、スナップショットの実行タイミングや保存期間を設定することができる。

3. スナップショットの実行タイミングを設定

「スナップショットのスケジュールを設定する」タブでは以下の通り設定する。

設定項目 設定例 説明
スケジュールを有効にする 有効 スナップショットの自動取得を実施する場合は有効にする。
繰り返し 毎日 01:00 取得タイミングを設定する。毎時間、毎日、毎週、毎月だけでなく、一定間隔で繰り返し実行といった設定が可能。
スマートスナップショットを有効にする チェック 対象のボリュームのデータに変更があった場合のみスナップショットを取得する設定。

4. スナップショットの保存期間を設定

「スナップショット保存」タブでは以下の通り設定する。

スナップショット取得数には上限がある。上限数は「スナップショットは最大いくつとれますか?」をクリックして確認することができる。

設定項目 設定例 説明
保存期間 3日 保存期間を超過したスナップショットは削除するよう設定する。
指定した件数のスナップショットを保存する 3スナップショット 保存するスナップショットを件数で管理する場合は、こちらで設定を行う。
スマートバージョニング 毎日1、毎月3 異なる期間でスナップショットを保持させたい場合に使用。例えば、毎日1件のスナップショットを残すだけでなく、1件でよいので3か月分のスナップショットを残したい場合などに使用する。

上記設定完了後、「OK」を選択し、設定を保存する。

5. スナップショット取得結果確認

実際に、スナップショットが取得された結果はスナップショットマネージャーから確認できる。

また、CIFSによるファイル共有をしている場合は、@Recently-Snapshotというフォルダから直接スナップショット取得時のデータを確認することができるため、すぐにスナップショット時点のファイルにアクセスすることができる。これが非常に便利だ。


以上で、QNAP NASで定期的なスナップショット取得する設定は完了となる。

2021年5月18日火曜日

vCenter Server ApplianceのSSLサーバ証明書を入れ替える

vCenter Server Appliance (vCSA) のvSphere Clientでは、インストール時に自己署名証明書が生成されてSSLによる通信ができるようになっているが、通常では以下のように「保護されていない通信」という警告がブラウザのアドレスバーに表示がされてしまう。

本記事では、vCSAにてCSR (証明書署名要求) を作成し、オレオレ認証局にて署名を行い、SSLサーバ証明書入れ替える手順を記載する。

なお、検証が目的であるため、今回はオレオレ認証局によるオレオレ証明書にてSSLサーバ証明書を作成し、入れ替えを実施した。オレオレ認証局及びオレオレ証明書の作成手順は、以下記事を参照いただきたい。また、ESXiの証明書入れ替え手順も記載している。

環境

本記事で使用したvCSAのバージョンは以下の通り。

  • vCetnre Server : vCenter Server Appliance 6.7 Update 3
  • アクセス確認用ブラウザ : Google Chrome

SSLサーバ証明書作成の一覧の流れを以下に図示する。

手順

1. vCSAにSSHでログイン

vCSAのサーバ証明書の入れ替えは、CLIにて実施する。Tera Termなどを使用してvCSAにSSHログインする。

ログインすると、特殊なコマンドのみ受け付けるモードになるので、shellを入力しBashモードにする。

Connected to service

    * List APIs: "help api list"
    * List Plugins: "help pi list"
    * Launch BASH: "shell"

Command> shell
Shell access is granted to root
root@t1160vcsa [ ~ ]#

2. CSR作成

証明書入れ替えは、専用のcertificate-managerと呼ばれるツールを用いて対話式にて行う。certificate-managerを実行するとメニューが表示されるが、Tera Termのウィンドウサイズがデフォルトの場合は表示が崩れるので、ウィンドウサイズを大きめにして実行すること。

メニューでは以下の通り、「1. Replace Machine SSL certificate with Custom Certificate」を選択したのち、対話式でCSRの作成を行う。

root@t1160vcsa [ ~ ]# /usr/lib/vmware-vmca/bin/certificate-manager

~(中略)~

Note : Use Ctrl-D to exit.
Option[1 to 8]: 1 ←★1を選択

Please provide valid SSO and VC privileged user credential to perform certificate operations.
Enter username [Administrator@vsphere.local]:
Enter password:
         1. Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate

         2. Import custom certificate(s) and key(s) to replace existing Machine SSL certificate

Option [1 or 2]: 1 ←★1を選択

Please provide a directory location to write the CSR(s) and PrivateKey(s) to:
Output directory path: /tmp ←★/tmpを入力

Please configure certool.cfg with proper values before proceeding to next step.

Press Enter key to skip optional parameters or use Default value.

Enter proper value for 'Country' [Default value : US] : JP
 ↑★「JP」を入力
Enter proper value for 'Name' [Default value : CA] : t1160vcsa.intrat.local
 ↑★「vCSAのFQDN」を入力
Enter proper value for 'Organization' [Default value : VMware] :
 ↑★任意。変更不要ならそのままEnter
Enter proper value for 'OrgUnit' [Default value : VMware Engineering] :
 ↑★任意。変更不要ならそのままEnter
Enter proper value for 'State' [Default value : California] : Tokyo
 ↑★「Tokyo」等を入力
Enter proper value for 'Locality' [Default value : Palo Alto] : Minato-ku
 ↑★「Minato-ku」等を入力
Enter proper value for 'IPAddress' (Provide comma separated values for multiple IP addresses) [optional] :
 ↑★任意。そのままEnterでOK
Enter proper value for 'Email' [Default value : email@acme.com] :
 ↑★任意。変更不要ならそのままEnter
Enter proper value for 'Hostname' (Provide comma separated values for multiple Hostname entries) [Enter valid Fully Qualified Domain Name(FQDN), For Example : example.domain.com] : t1160vcsa.intrat.local
 ↑★「vCSAのFQDN」を入力
Enter proper value for VMCA 'Name' :t1160vcsa.intrat.local
 ↑★「vCSAのFQDN」を入力
2021-04-30T06:59:49.025Z  Running command: ['/usr/lib/vmware-vmca/bin/certool', '--genkey', '--privkey', '/tmp/vmca_issued_key.key', '--pubkey', '/tmp/pubkey.pub']
2021-04-30T06:59:49.068Z  Done running command
2021-04-30T06:59:49.069Z  Running command: ['/usr/lib/vmware-vmca/bin/certool', '--gencsr', '--privkey', '/tmp/vmca_issued_key.key', '--pubkey', '/tmp/pubkey.pub', '--config', '/var/tmp/vmware/certool.cfg', '--csrfile', '/tmp/vmca_issued_csr.csr']
2021-04-30T06:59:49.134Z  Done running command

CSR generated at: /tmp/vmca_issued_csr.csr
         1. Continue to importing Custom certificate(s) and key(s) for Machine SSL certificate

         2. Exit certificate-manager

Option [1 or 2]: 2 ←★2を選択
root@t1160vcsa [ ~ ]#

上記を実行すると、/tmp配下に以下ファイルが生成される。

ファイル名 説明
vmca_issued_csr.csr CSR (証明書署名要求) のファイル。
vmca_issued_key.key CSR作成時に生成されたサーバの秘密鍵。

上記のCSR (vmca_issued_csr.csr) を認証機関で署名してもらうことでSSLサーバ証明書を作成することができる。ただし、vCSAはSFTPやSCPによる接続が少々面倒なので、catなどで直接テキスト情報として取得してしまうのが手っ取り早い。

root@t1160vcsa [ ~ ]# cat /tmp/vmca_issued_csr.csr
-----BEGIN CERTIFICATE REQUEST-----
MIIDKTCCAhECAQAwgYAxHzAdBgNVBAMMFnQxMTYwdmNzYS5pbnRyYXQubG9jYWwx

~(中略)~

MoqKIu7L005PVeSuATdL5AZenovKHNrKGy+uKBKnK786U+d6ZKqH/2xoHLg4
-----END CERTIFICATE REQUEST-----

3. オレオレ認証局でCSRに署名

以降の作業は、Linuxにて事前にオレオレ認証局を構築していることを前提とする。オレオレ認証局の構築手順は、以下URLを参照すること。

先ほど取得したCSR情報を/etc/pki/tls/misc/newreq.pemに貼り付ける。

# cd /etc/pki/tls/misc/
# cat newreq.pem
-----BEGIN CERTIFICATE REQUEST-----
MIIDKTCCAhECAQAwgYAxHzAdBgNVBAMMFnQxMTYwdmNzYS5pbnRyYXQubG9jYWwx

~(中略)~

MoqKIu7L005PVeSuATdL5AZenovKHNrKGy+uKBKnK786U+d6ZKqH/2xoHLg4
-----END CERTIFICATE REQUEST-----

次に、SAN (Subject Alternative Name) の設定をsan.txtに以下の通り記載する。SANに埋め込むFQDNは必ずvCSAのFQDNと一致させること (ワイルドカードの利用不可)。これが一致していない場合、後続の証明書のインポート時に失敗する。

# cat san.txt
subjectAltName = DNS:t1160vcsa.intrat.local, IP:192.168.11.160

準備が整ったので、CAスクリプトを使ってCSRに署名を行う。

# ./CA -sign
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem: ←★CA作成時に設定したパスワードを入力
Check that the request matches the signature
Signature ok

~(中略)~

Sign the certificate? [y/n]:y ←★yを入力


1 out of 1 certificate requests certified, commit? [y/n]y
 ↑★yを入力

Write out database with 1 new entries
Data Base Updated

~(中略)~

-----BEGIN CERTIFICATE-----
MIIDtzCCAp+gAwIBAgIUTeRKOvluYWQQIfSA0z6d5dj8Ug0wDQYJKoZIhvcNAQEL

~(中略)~

4JJOGgG6dI198y/CSdlt+OKn8spijKR3YktVtYBA1Wcq9kH2vMjqnEzTCQ==
-----END CERTIFICATE-----
Signed certificate is in newcert.pem

署名されたSSLサーバ証明書は、以下コマンドで出力させることができるので、テキストをコピーなどして保存しておく。

# cat newcert.pem | grep -A 100 BEGIN
-----BEGIN CERTIFICATE-----
MIIDtzCCAp+gAwIBAgIUTeRKOvluYWQQIfSA0z6d5dj8Ug0wDQYJKoZIhvcNAQEL

~(中略)~

4JJOGgG6dI198y/CSdlt+OKn8spijKR3YktVtYBA1Wcq9kH2vMjqnEzTCQ==
-----END CERTIFICATE-----

なお、もしSANの設定が適切ではない場合などの理由で証明書のインポートに失敗した場合は、以下のように「Performing rollback of Machine SSL Cert...」といったメッセージが表示され、証明書のロールバックが開始される。ロールバックの際もサービスの停止・起動は発生するので10分くらい時間を要するので、注意すること。

Previous MACHINE_SSL_CERT Subject Alternative Name does not match new MACHINE_SSL_CERTIFICATE Subject Alternative Name

Performing rollback of Machine SSL Cert...
Get site nameus : 0% Completed [Rollback Machine SSL Cert...]

4. SSLサーバ証明書をインポート

vCSAに証明書をインポートする際には、事前に以下ファイルに各種証明書情報を保存する必要がある。

フルパス 説明
/tmp/machine_name_ssl.cer 署名されたSSLサーバ証明書を新規ファイルで作成する。
/tmp/vmca_issued_key.key CSR作成時に生成された秘密鍵 (新規に作成は不要)。
/tmp/Root64.cer 署名した認証局 (CA) の公開鍵を新規ファイルで作成する。

上記の通り、machine_name_ssl.cerRoot64.cerは新規作成を行う。viを使って直接テキスト貼り付けで作成してしまうのが手っ取り早い。

root@t1160vcsa [ ~ ]# cat /tmp/machine_name_ssl.cer
-----BEGIN CERTIFICATE-----
MIIDtzCCAp+gAwIBAgIUTeRKOvluYWQQIfSA0z6d5dj8Ug0wDQYJKoZIhvcNAQEL

~(中略)~

4JJOGgG6dI198y/CSdlt+OKn8spijKR3YktVtYBA1Wcq9kH2vMjqnEzTCQ==
-----END CERTIFICATE-----

root@t1160vcsa [ ~ ]# cat /tmp/Root64.cer
-----BEGIN CERTIFICATE-----
MIID2zCCAsOgAwIBAgIUTeRKOvluYWQQIfSA0z6d5dj8UgIwDQYJKoZIhvcNAQEL

~(中略)~

h5ibLwLq+FBIM8UixMoK/CpWpfBevfmqLNEz7PVpwA==
-----END CERTIFICATE-----

必要なファイルを作成したのち、再度certificate-managerを実行し、以下の通り対話入力を行いSSLサーバ証明書をインポートする。なお、SSLサーバ証明書インポート時に各種サービスの停止・起動が発生するため、完了まで10分程時間を要する。

root@t1160vcsa [ ~ ]# /usr/lib/vmware-vmca/bin/certificate-manager

~(中略)~

Note : Use Ctrl-D to exit.
Option[1 to 8]: 1 ←★1を選択

Please provide valid SSO and VC privileged user credential to perform certificate operations.
Enter username [Administrator@vsphere.local]:
Enter password:
         1. Generate Certificate Signing Request(s) and Key(s) for Machine SSL certificate

         2. Import custom certificate(s) and key(s) to replace existing Machine SSL certificate

Option [1 or 2]: 2 ←★2を選択

Please provide valid custom certificate for Machine SSL.
File : /tmp/machine_name_ssl.cer ←★/tmp/machine_name_ssl.cerを入力

Please provide valid custom key for Machine SSL.
File : /tmp/vmca_issued_key.key ←★/tmp/vmca_issued_key.keyを入力

Please provide the signing certificate of the Machine SSL certificate
File : /tmp/Root64.cer ←★/tmp/Root64.cerを入力

You are going to replace Machine SSL cert using custom cert
Continue operation : Option[Y/N] ? : y ←★yを入力
Command Output: /tmp/machine_name_ssl.cer: OK

Get site nameCompleted [Replacing Machine SSL Cert...]
default-first-site
Lookup all services
Get service default-first-site:9923b037-5d1d-4afe-93de-6462b43535ad
Update service default-first-site:9923b037-5d1d-4afe-93de-6462b43535ad; spec: /tmp/svcspec_qd17bss4

~(中略)~

Get service c34642a3-eac1-401c-b629-d3af2bbde2b4_kv
Don't update service c34642a3-eac1-401c-b629-d3af2bbde2b4_kv
Updated 34 service(s)
Status : 70% Completed [stopping services...]
Status : 85% Completed [starting services...]
Status : 100% Completed [All tasks completed successfully]

5. 確認

実際に、vSphere ClientのWeb画面にアクセスし、ブラウザで証明書の警告が発生しないことを確認する。前提として、オレオレ認証局の公開鍵をWindowクライアントの「信頼されたルート証明機関」としてインストール済みであるとこととする。

まず、vCSAのIPアドレスに対してアクセスしてみる。SANにはホスト名だけでなくIPアドレスも記載しているため、証明書の警告は表示されなくなる。

同様にFQDNでアクセスしても証明書の警告が表示されなくなっており、問題なくSSLサーバ証明書の入れ替えができていることが確認できた。

参考

2021年5月11日火曜日

Linuxでオレオレ認証局を構築する & ESXiのSSLサーバ証明書入れ替え手順

SSLサーバ証明書を作る場合、証明書を必要とする機器にてCSR (証明書署名要求) を作成し、それを第三者機関の正式な認証局にて署名してもらう必要がある。正式な認証局による署名は各種申請や審査があり、費用も発生することから、検証目的などで使用することは現実的ではない。

そこで、正式な第三者の認証局を使うのではなく、自分で認証局を作り、自分でSSLサーバ証明書を作成する。このような認証局、証明書はオレオレ認証局オレオレ証明書と呼ばれる (正式には自己署名証明書と呼ぶ)。

今回、Linuxサーバをオレオレ認証局として構築し、CSRに署名を行うことで、以下のような「保護されていない通信」といったブラウザの証明書に関する警告を表示させないように設定する。例として、ESXiのWeb管理画面となる「VMware Host Client」に使うSSLサーバ証明書を作成して入れ替えを行う。

環境

Cent OS 8をオレオレ認証局として構築し、ESXiにて生成したCSRに署名をすることで、SSLサーバ証明書を作成する。なお、動作確認にはChromeのみで確認しているが、ChromiumベースのMicrosoft Edgeでも同様の動作となると想定される。

  • 認証局Linux OS : CentOS 8
  • 動作確認ブラウザ : Google Chrome
  • ESXi : 6.7 Update 3

SSLサーバ証明書作成の一覧の流れを以下に図示する。

オレオレ認証局を作成

1. opensslのパッケージをインストール

Linuxをオレオレ認証局として構築する場合は、opensslのパッケージが必要となる。ただし、CentOSの場合は、最小インストールの場合でもデフォルトでインストールされているので、確認だけしておく。

# rpm -qa | grep openssl
openssl-1.1.1c-2.el8_1.1.x86_64
openssl-libs-1.1.1c-2.el8_1.1.x86_64
xmlsec1-openssl-1.2.25-4.el8.x86_64
openssl-pkcs11-0.4.8-2.el8.x86_64

2. openssl.cnfを修正

証明書を発行する際の設定は/etc/pki/tls/openssl.cnfで実施する。デフォルトでは有効期限が1年と短いなど使い勝手が悪いので、以下の通りviなどを使って修正を行う。

設定項目 設定値 説明
default_days 3650 証明書の有効期限を約10年に設定。
countryName_default JP デフォルトでJP (日本) を設定。
stateOrProvinceName_default Tokyo デフォルトでTokyoを設定。
basicConstraints CA:TRUE 認証局となるため、CA:TRUEに設定。

3. CAスクリプトを入手

CentOS 7以前のopensslでは、/etc/pki/tls/misc/CAというスクリプトが用意されており、認証局作成や署名などを簡単に実施できるようになっていた。残念ながら、CentOS 8のopensslには含まれなくなってしまったようなので、CentOS 7の環境からCAスクリプトを入手し、同様に/etc/pki/tls/misc/に配置する。

4. CAスクリプトを修正

CAスクリプトに対して以下修正を行う。SAN (Subject Alternative Name) の設定理由は後述する。

行数 設定項目 設定値 説明
64 CADAYS="-days 1095" CADAYS="-days 3650" 3年→10年に修正。
156 $CA -policy policy_anything -out newcert.pem -infiles newreq.pem $CA -policy policy_anything -extfile san.txt -out newcert.pem -infiles newreq.pem SANを設定するため、-extfile san.txtを追記。

5. 認証局を作成

./CA -newcaを実行し、認証局として必要な秘密鍵と公開鍵の作成を行う。対話式で入力が必要となるので、以下の通り必要項目を入力する。

# cd /etc/pki/tls/misc/
# ./CA -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a RSA private key
.........................................+++++
............................................+++++
writing new private key to '/etc/pki/CA/private/./cakey.pem'
Enter PEM pass phrase: ←★パスワードを入力
Verifying - Enter PEM pass phrase: ←★再度パスワードを入力
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [JP]: ←★そのままEnter
State or Province Name (full name) [Tokyo]: ←★そのままEnter
Locality Name (eg, city) [Default City]: ←★そのままEnter
Organization Name (eg, company) [Default Company Ltd]:
 ↑★そのままEnter
Organizational Unit Name (eg, section) []:
 ↑★そのままEnter
Common Name (eg, your name or your server's hostname) []:My Private CA
 ↑★認証局の名称などを記載。任意の名前でもFQDNでも区別がつけばOK
Email Address []: ←★そのままEnter

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: ←★そのままEnter
An optional company name []: ←★そのままEnter
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/./cakey.pem:
 ↑★最初に設定したパスワードを再入力
Check that the request matches the signature
Signature ok

~(中略)~

Write out database with 1 new entries
Data Base Updated

作成された秘密鍵、公開鍵の保存先は以下の通りとなる。

保存先
秘密鍵 /etc/pki/CA/private/cakey.pem
公開鍵 /etc/pki/CA/cacert.pem

Windows OSの「信頼されたルート証明機関」として認証局の公開鍵をインポート

1. 認証局の公開鍵をダウンロード

先ほど認証局作成時に生成された公開鍵cacert.pemを端末にダウンロードする。

Windowsでは拡張子がpemの場合、証明書ファイルとして認識しないため、拡張子をcerに変更し、ファイル名をcacert.cerとして保存する。

2. 公開鍵を「信頼されたルート証明機関」としてインポート

非ドメイン環境 (Workgroup環境) の場合は、タスクバーの検索から「証明書」を入力し、「コンピューター証明書の管理」にて証明書をインポートする。

「信頼されたルート証明機関」
 →「証明書」

一方、ドメイン環境 (Active Directory環境) では、グループポリシーエディターを使って証明書をインポートすると便利である。グループポリシーの設定箇所は以下となる。

「コンピューターの管理」
 →「ポリシー」
  →「Windowsの設定」
   →「セキュリティの設定」
    →「公開キーのポリシー」
     →「信頼されたルート証明機関」

インポート手順自体は、ドメイン有無に関わらず同じとなる。

まず、「信頼されたルート証明機関」を右クリックし、「インポート」を選択する (選択箇所は「すべてのタスク」→「インポート」の場合もある)。

「保存場所」は「ローカルコンピューター」を選択する。

「インポートする証明書ファイル」は、先ほど認証局からダウンロードしたcacert.cerを選択する。

「証明書ストア」は「信頼されたルート証明機関」を選択する。

最後に「正しくインポートされました。」と表示されればOKとなる。

CSRを作成し、認証局にて署名

1. ESXiにてCSRを作成

ESXiのVMware Host Clientにログインし、「管理」→「セキュリティとユーザー」タブ→「証明書」→「新しい証明書をインポート」を選択する。

「FQDNの署名要求を作成」または「IPアドレスの署名要求を作成」のどちらかを選択する。私の環境ではIPアドレスによる直接アクセスであることから、後者を選択した。

「証明書署名要求の結果」にてCSRがテキストで出力されるので、「クリップボードにコピー」を押してコピーし、先ほど作成したオレオレ認証局の/etc/pki/tls/misc/newreq.pemファイルとして保存する。

# ls -l /etc/pki/tls/misc/
合計 12
-rwxr-xr-x 1 root root 5178  4月 29 16:04 CA
-rw-r--r-- 1 root root 1240  4月 29 16:44 newreq.pem

2. SAN設定用のテキストファイルを作成

SSLサーバ証明書では、以下を3点を確認することで、アクセス先のサーバが正当なものであることを確認している。

  1. SSLサーバ証明書に記載のCommon Name (CN)がブラウザに入力したURLのドメインと一致すること
  2. SSLサーバ証明書が信頼されるルート証明書機関による署名がされていること
  3. SSLサーバ証明書の有効期限が切れていないこと

しかし、Google Chromeでは、CNによるドメイン確認は廃止され、SAN (Subject Alternative Name) による確認を行うよう仕様が変更されている。そのため、作成するオレオレ証明書についても、SANの情報を埋め込む必要がある。

具体的には、SANの情報を記載するsan.txtというファイルをCAスクリプトと同じディレクトリに作成し、CAスクリプトで署名する際にその情報の埋め込みを行う (CAスクリプトは前述の手順にて修正済み)。

SANには、対象となるドメインやIPアドレスをカンマ区切りで複数記載することができ、ドメインの場合はサブドメインにワイルドカード (*) も使用可能である。ドメインの場合は頭にDNS:を付与し、IPアドレスの場合はIP:を付与する。

今回は、自宅ドメインすべてを含む*.intrat.localという設定とIPアドレスとなる192.168.33.10の両方を記載した。

# cat san.txt
subjectAltName = DNS:*.intrat.local, IP:192.168.33.10

3. CSRに署名しSSLサーバ証明書を作成

以上でようやく準備は整った。./CA -signを実行し、CSRに署名を行う。

# ./CA -sign
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem: ←★CA作成時に設定したパスワードを入力
Check that the request matches the signature
Signature ok

~(中略)~

Certificate is to be certified until Apr 27 07:54:39 2031 GMT (3650 days)
Sign the certificate? [y/n]:y ←★yを入力


1 out of 1 certificate requests certified, commit? [y/n]y
 ↑★yを入力
Write out database with 1 new entries
Data Base Updated

~(中略)~

Signed certificate is in newcert.pem

問題なく完了すると、SSLサーバ証明書としてnewcert.pemが生成されているはずだ。

# ls -l
合計 32
-rwxr-xr-x 1 root root 5195  4月 29 18:09 CA
-rw-r--r-- 1 root root 4482  4月 29 19:23 newcert.pem
-rw-r--r-- 1 root root 1172  4月 29 19:23 newreq.pem
-rw-r--r-- 1 root root   72  4月 29 18:16 san.txt

4. SSLサーバ証明書をESXiにインポート

作成されたSSLサーバ証明書はテキストファイルとなっているため、catを使うことで証明書情報を出力させることができる。必要情報は、BEGIN CERTIFICATEからEND CERTIFICATEまでとなるので、テキストで表示させコピーしておく。

# cat newcert.pem | grep -A 100 BEGIN
-----BEGIN CERTIFICATE-----
MIID9TCCAt2gAwIBAgIUTeRKOvluYWQQIfSA0z6d5dj8UggwDQYJKoZIhvcNAQEL

~(中略)~

BxTM2w+vx0CcT2vO7IjUQo3+zGBSQVHl+7QTZm6O8k0/NDMLr9WS1Bh0ZMykXit/
JoKBnz+NRLl2
-----END CERTIFICATE-----

コピーした証明書情報をESXiの「証明書」欄に貼り付けて、「インポート」ボタンを押す。

問題なければ、「証明書は正常に更新されました。ブラウザを更新する必要があります」と表示される。

5. 動作確認

ブラウザはF5による画面更新では効果がない場合がある。その際は、一度ブラウザをすべて閉じたのち起動させることで、新しい証明書情報でアクセスできることを確認することができる。

問題なく設定ができていれば、証明書の警告画面やアドレスバーの「保護されていない通信」の警告は表示されることなく、ESXiのVMware Host Clientの画面が表示されるはずだ。

なお前述した通り、Chromeでは証明書のSANの値にてドメインやIPアドレスの正当性を確認する。今回の設定ではドメインとしてワイルドカードで設定をしていることから、FQDNによるアクセスをした場合でも、警告メッセージは表示されることはなく、正常にアクセスをすることができる。

参考

2021年5月4日火曜日

ESXi上のLinux仮想マシンでCD/DVDドライブ接続解除時の「質問の回答」を回避する方法

ESXi上で稼働しているLinux仮想マシンでは、仮想CD/DVDドライブの「接続」チェックを解除しようとすると、以下のような「質問の回答」が表示されて、回答するまで仮想マシンの応答が停止してしまう。

ゲスト OS が CD-ROM ドアをロックしてその CD-ROM を使用している可能性があります。これにより、ゲストがメディアの変更を認識できなくなる可能性があります。可能な場合は、接続を切断する前に、ゲスト内から CD-ROMを取り出してください。切断を続行しますか (そしてロックをオーバーライドしますか)?

※上記質問に「はい」を答えれば接続が解除され「いいえ」を答えれば接続したままになる。

これは昔からある事象であり、みんな回避方法を常識として知っていたのかもしれないが、私自身が長年vSphere製品に携わっていたのに知らずに過ごしていた(いつも「質問の回答」が表示されたら「はい」を選択していた)。

今回、長年知らなかった回避方法を実際に試してみたので以下に記載する。

eject cdromを実行する

もっとも簡単な方法は、OSにてejectコマンドを実行することだ。

[root@localhost ~]# eject cdrom

ejectコマンドを実行すると、仮想CD/DVDドライブの「接続」を解除してくれる。以下は、ejectコマンド実行後の仮想マシンの「設定の編集」が面となる。

ただし、単純にejectコマンドを実行すると何のプロンプトも返らないので、成功か失敗かよくわからなくなる。そこで、-vオプションを使って詳細表示をさせるとわかりやすいだろう。

[root@localhost ~]# eject -v cdrom
eject: device name is `/dev/sr0'
eject: /dev/sr0: not mounted
eject: /dev/sr0: is whole-disk device
eject: /dev/sr0: is removable device
eject: /dev/sr0: trying to eject using CD-ROM eject command
eject: CD-ROM eject command succeeded

なお、ejectコマンドはCD/DVDドライブのアンマウント処理も同時に実施してくれるため、マウント後のumountコマンドによるアンマウント手順は不要となる。以下にマウント状態でのejectコマンドを実行した場合の動作を記載する。

[root@localhost ~]# mount cdrom /mnt/
mount: special device cdrom does not exist
[root@localhost ~]# eject -v cdrom
eject: device name is `/dev/sr0'
eject: /dev/sr0: mounted on /mnt
eject: /dev/sr0: is whole-disk device
eject: /dev/sr0: is removable device
eject: /mnt: unmounting
eject: /dev/sr0: trying to eject using CD-ROM eject command
eject: CD-ROM eject command succeeded

仮想マシンの詳細設定にcdrom.showIsoLockWarningmsg.autoanswerを設定する

個人的には毎回仮想マシン構築時に設定する手間も発生することから、おすすめはできない設定となる。

仮想マシンの「設定の編集」→「仮想マシンオプション」→「構成パラメータ」の「構成の編集」ボタンを選択し、以下2行のパラメータを追加する。この設定はOS起動状態で反映可能である。

パラメータ 値 (接続解除させないパターン) 値 (強制切断パターン)
cdrom.showIsoLockWarning TRUE FALSE
msg.autoanswer TRUE TRUE

参考

人気の投稿