Azureの既存VMをSSL対応してみた

Azureの既存VMをSSL対応してみた

おはようございます。
胃が気持ち悪くて１日寝込んでたHeyGです。

以前の仕事でAzureを初めて触りました。
そこで既存のVirtualMachine(仮想マシン)をSSL対応したので記事に残しておきます。

 

目次

Azure VMのSSL対応の方法

AzureのVirtualMachine（仮想マシン）のSSL対応は色々あります。

そもそも証明書の取得方法はいくつかあります。

  1. VM内でlets encryptで自己証明書を作成
  2. Azureのキーコンテナーで自己証明書を作成
  3. AzureのApp Service証明書で証明書を作成

しかし昨今のSSL動向は１や２で作成した証明書を危険な証明書として扱われ、警告がでるようになっています。

３で作成できる証明書はきちんとした証明書を発行できますが、有料です。

AWSなんかだと無料で警告のでない証明書を簡単に発行できるんですが、調べた限りは無理でした。

 

また、証明書を設定する方法もいくつかあります。

  1. VMのWebサーバーソフトウェア(ApacheやNginxなど)に直接設定
  2. アプリケーションゲートウェイをかませて、ゲートウェイにキーコンテナーの証明書を設定
  3. App Service証明書で作成した証明書をキーコンテナー経由でVMに保存し１と同じく直接設定

 

調べた限りAzureで警告の出ない証明書を設定する方法は

AzureのApp Service証明書で証明書を作成してキーコンテナー経由でVMのWebサーバーソフトウェア(ApacheやNginxなど)に直接設定

するほかなさそう。

ゲートウェイを使っているのであればゲートウェイに設定するのが妥当だと思いますが、最小構成では基本的にゲートウェイを使わないと思いますので、今回は触れません。

また、VMではなくAppServiceを使用している場合、無料の証明書が作れるようですが、そもそもAppService自体が割と高いです。

 

App Service証明書の作成

AzureポータルからAppService証明書を新規作成します。

「名前」はポータル上の表示名

「ネイキッド　ドメインのホスト名」は証明書を使いたいドメイン

「リソースグループ」は作成してるVMと同じリソースグループを指定

「証明書SKU」はシングルドメインかワイルドカードドメインかの違い

「法律条項」は契約にあたっての条項の確認

です。

設定して問題なければ作成してください。

 

証明書SKUのS1 StandardとW1 ワイルドカードの違い

違いは単純です。

example.com というドメインを使う場合

S1 Standardはexample.comだけをつかう時

W1 ワイルドカードはmain.example.comやsub.example.comをつかう時

基本的にはS1 Standardで問題ないでしょう

 

料金的には7838円と他の証明書サービスよりはお得だったりしますが、AWSなら無料だし、そこまでしてAzureにする必要があるのか謎ですが…

まあ取引先によってはAzureでお願いされる事がありますから逃げられない道ですが…

 

AppService証明書の構成を設定

今回は手順の１と２だけで、３はAppServiceを使っている場合に使用します。

 

AppService証明書の構成で格納設定

お使いのキーコンテナーに証明書の秘密鍵が保存されます。

VMで使う場合はこのキーコンテナーを経由して証明書を取得します。

 

AppService証明書の構成で確認設定

証明書の構成と難しい表現ですが、ドメインの所有権を確認するだけです。

今回は「手動による確認」を行います。

方法は上記画像の①に使用する文字列が表示されているので、それを対象ドメインのTXTレコードに設定するだけです。

お名前.comでドメインを取得しているので、お名前.com側で設定します。

 

ホスト名に@を入力

TYPEをTXTへ変更

VALUEに①の文字列を入力

追加して保存してください。

しばらく待つと下記のような画面になります。

こうなると成功です。

 

VMでAzure CLIを使って証明書を取得設定

VM側で上記で生成した証明書を使う場合、Azure CLIを使って取得する必要があります。

なので、Azure CLIをVMにインストールする必要があります。

 

VMにAzure CLIをインストール

OS毎にインストール方法は少し違うので詳しくは公式を確認してください。

https://docs.microsoft.com/ja-jp/cli/azure/install-azure-cli?view=azure-cli-latest

 

VMにAzure CLIを使って証明書をダウンロード

Azure CLIへのアクセス方法は以下です。

az login

また、複数のサブスクリプションを所有している場合テナントIDを指定する必要があります。

az login --tenant example-tenant-id

 

キーコンテナーのシークレットに証明書の秘密鍵情報が保存されているので、その名前を確認しておいてください。

下記画像の赤枠部分です。

 

証明書のダウンロードは

# az keyvault secret download --name "画像で確認した名前" --vault-name "キーコンテナーの名前" --encoding base64 --file "保存する証明書名.pfx"

で行えます。

ちなみにダウンロードしたファイルはテキストエディタで見ても空なので注意してください。

それにパスワードが空で設定されているため、Azureの他サービスで使おうとしてもパスワードないけど？って怒られたりするので気をつけてください。

 

保存した証明書へのパスワード再設定方法は

# openssl pkcs12 -in 保存した証明書名.pfx -out temp.pem -nodes -password pass:""
# openssl pkcs12 -export -out 保存した証明書名.pfx -in temp.pem -password pass:"設定したいパスワード"

で行えます。

 

pfxをpemやkeyへ変換

ApacheやNginxに設定する場合pemやkeyを使ってると思います。

変換方法は以下になります。

pem

# openssl pkcs12 -in 保存した証明書名.pfx -nodes -out 保存したいpem名.pem
Enter Import Password:
MAC verified OK

key

# openssl pkcs12 -in 保存した証明書名.pfx -nocerts -nodes -out 保存したいkey名.key
Enter Import Password:
MAC verified OK

 

Apacheにインストールした証明書を設定

今回はApacheで行ったのでApacheの設定ファイルを貼っておきます。

アプリがTomcatを使って裏側で動作しているため、AJPでプロキシしてありますが適宜置き換えてください。

<VirtualHost *:80>
  ServerName example.com

  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<Virtualhost *:443>
  ServerName example.com
  ProxyPass / ajp://localhost:8009/

  SSLEngine on
  SSLProtocol all -SSLv2 -SSLv3

  SSLCertificateFile /保存したディレクトリ/保存したpem名.pem
  SSLCertificateKeyFile /保存したディレクトリ/保存したいkey名.key
</VirtualHost>

設定を終えたら、Apacheを再起動して設定完了です！

 

まとめ

昔設定したものを記事にしているため、少し内容が薄いかもしれません。

まあAzure VMでSSL対応をする場合は上記でいけますが、有料ですよというお話でした。

そこまでこだわりがなければAWSで構築した方がいいんじゃないかな？と思います。

 

ではまた。

Share
Tweet

開発カテゴリの最新記事