Edited at

EC2で構築したUiPath Orchestrator サーバを、自己署名じゃない証明書でSSLで公開する(Certificate ManagerとELBを使用)


イントロ

UiPath Orchestrator を構築するにあたって、久しぶりにEC2でSSL証明書を取って環境構築したので、そのときの備忘。

タイトルは UiPath OrchestratorサーバをSSLで公開するってなってますが、実際はOrchestratorに特化した話ではなく一般的なEC2サーバのSSL公開の話って感じです。


前提


  • ドメインを持っている(example1.xyz としました)

  • そのドメインは、AWSのRoute 53で管理している

  • UiPath Orchestratorが、AWS上のEC2で(WindowsサーバのIIS上で)ポート443ですでに動いている

  • 今時点では Orchestratorサーバ(以下Orchサーバ)へは https://[IPアドレス]/ でアクセスしている

  • 保守のためそのEC2サーバへは 443の他RDP(ポート3389)やKibana(ポート5601)も許可している

  • Orchestratorが動くIISサーバは、SSL証明書が自己署名証明書なので、ちゃんとした証明書を用いるようにしたい

  • 監視とか冗長構成とかは、とりあえず今回は省略

記事開始時点を図示するとこんな感じ。

さてさて今回、UiPath Orchestratorを自己署名証明書で構築するところは省略していて、すでに構築済みとしています。そのOrchサーバを自己署名じゃない証明書で公開するのに


  • 証明書を正規に取得して自己署名証明書から置き換え Orchサーバをそのまま外部に「 https://orch.example1.xyz 」などで公開

してもよいのですが、今回は


  • Orchサーバの手前にELB(Elastic Load Balancer)を置いて、AWS上で無料で取得できるSSL証明書を用いる

ことにしました。ELBは特定のネットワークからのポート443への接続のみ許可するモノとします。

図示するとこうです。


ほんとはSSLをほどいてルーティングしたい、、

ELBでSSLをほどいて IISにはHTTPのポート80で流したかった件、、最後に注記しました。


やってみる

さて構築の流れとしては、

すればよさそうです。ついでに同じELBを用いて

も入れてみます。


Certificate ManagerでSSL証明書をあらかじめ取得

AWS Certificate Managerを使って無料でSSL証明書を発行する にまとめました。証明書取得まではそれで行けると思います。


ELBの構築(の前のターゲットグループ作成)

ELBは処理を転送するのに、ターゲットグループというEC2インスタンスのグルーピングを用います。今回 Orchサーバのインスタンスをもつグループ「orch」と、あとで使うElasticsearchサーバのインスタンスをもつ「ela」というグループを作成します。先の図のココです。

EC2 >> ターゲットグループ を表示して「ターゲットグループの作成」をクリック。

今回はELBから、そのままHTTPS(ポート443) で待ち受けているIISサーバに転送するので、プロトコルはHTTPS、ポートは443とします。IISサーバではHTTPで待ち受けている場合は、プロトコルはHTTP、ポートはIISのポート(通常80かな)を設定します。

作成が完了したら「閉じる」をクリック。

つづいてターゲットグループにOrchサーバを登録するため「編集」をクリックします。

Orchestratorサーバを選択して「登録済みに追加」をクリック。待ち受けるポートをインスタンスごとに個別に指定出来ますが、今回はターゲットグループに指定したポートと同じなのでそのままでOK。

上に追加されたので、「保存」をクリック。

保存されました。

同様に、ela のターゲットグループも作ります。違うところは、ELBがHTTPSで受けた後、こちらのターゲットグループにはHTTPでポート5601でルーティングしますので、そのように設定します。

ターゲットグループへのElasticsearchサーバの登録も忘れずに。。

保存できました。

以上で、各ターゲットグループの作成は完了です。


ELBの構築(Application Load Balancerの作成)

つづいて、主役のロードバランサの作成です。

Application Load Balancerを選択。

今回はHTTPSのみを受け付けるので、HTTPS/443を選択。アベイラビリティゾーンはとりあえず、自分が持ってるサブネットを指定しておきましょう。

SSLの設定です。すでにさきほど作成済みであれば、ココに証明書として出てくるはずなのでそれを選択して次へ。

ELBが属するセキュリティグループについて、グループはELB用に新規に作成します。このグループは外部からアクセスされるところになるので慎重に。今回はOrchestratorサーバを構築する記事なのであるIPアドレスたちからのポート443への接続のみを許可する設定としていますが、広く公開する場合は「任意の場所」を選択しましょう。

さて、ルーティングするターゲットグループを指定します。まずはシンプルに、全てのリクエストを「orch」グループにルーティングするように設定します。

のちに「 https://ela.example1.xyz/ 」へのリクエストはSSLをほどいて別のグループ「ela」にルーティングさせますが、あと回しで。

インスタンスとポート番号を確認します。

最終確認。よければ「作成」をクリック。

おお、作成できたようですね。

一覧に戻ってみると、確かにELB001というロードバランサが作成できています。下の詳細にDNS名が表示されていますが、このサーバ名がロードバランサに割り振られたサーバ名になります。あとでもっとわかりやすいエイリアスをつけますが、これでアクセスできるようになったということですね。

ここまででほぼ、ELBの構築は完了です。


ELBのセキュリティグループ → EC2のグループへの通信許可

つづいて上記のセキュリティグループのリンクをクリックして、ELB側でなくEC2インスタンス達側のセキュリティグループの設定を変更します。

このままではELBからの接続が許可されていないことになるので 、ELBのセキュリティグループからEC2側のセキュリティグループへ、HTTPSのためのポート443と、Elasticsearch/Kibanaのためのポート5601 への通信を許可します。また下記のイメージの下から3つめ、元々あったHTTPS/443への直接通信はホントは削除した方がよいでしょう。EC2インスタンス直接アクセスは遮断し、ELBからのアクセスに限定するほうがよいからですね。


いったん疎通確認

さてさてELBからのルーティングやセキュリティグループによる通信設定もできたので、いったんブラウザで https://[長いELBのDNS名]/ へアクセスしてみましょう。

おなじみのUiPath Orchestrator画面が表示されましたねーー。。今のところ、サーバ名が証明書のCommon Nameと不一致のためSSL的にはエラーになってますが、アクセス自体はできるようになりましたね。

いやー記事にすると長くなりました。。


ELBのサーバ名をAWS Route 53(DNSサービス)で名前解決

さてさて、あとすこし。

先ほどの長ーいELBのサーバ名を、たとえば orch.example1.xyz とか ela.example.xyz などでアクセスできるよう、DNSサービスで名前解決します。

Route 53にアクセスして、該当ホストゾーンの設定画面を開き「レコードセットの作成」をクリック。

名前に「orch」、エイリアスを「はい」にするとエイリアス先に、ELBのレコードが選択出来るようになるので、それを選択し「作成」をクリック。

レコードが追加されました。簡単ですね。

さてさて「 https://orch.example1.xyz/ 」 でアクセスしてみましょう。

表示されましたねーー。。

サーバ名がSSL証明書のCommon Name: *.example1.xyz と一致しているため、先ほどのELBのサーバ名の時は発生していた証明書が不正っていうエラーも、今回は出ていない状態になりました!

最後に、ついでに同じ設定で「ela」というサーバ名も追加しておきます。


URL違いでElasticsearchサーバに処理を転送する設定

最後に、Elasticsearchサーバのルーティングと疎通つまり 「 https://ela.example1.xyz へのアクセスは、Elasticsearch/Kibana サーバにHTTPでポート5601へルーティングする」という設定が入ってないのですが、長くなったので別記事にしました。

おつかれさまでした。


ほんとはSSLをほどいてルーティングしたい(後述)

-- 2019/07/07追記 --

ちなみに本当は、ELBでSSLをほどいて IISにはHTTPのポート80で流したかったのですができていません。UiPath OrchestratorのインストーラがIIS上にSSL付きで構築してくれてしまうのと、さらにはURL Rewrite機能を用いて HTTPアクセスをHTTPSにリダイレクトまでしてくれていて、、、、これらをオフってIIS上にHTTPのOrchestratorを構築する手順が明確でなかったからです、、、。バインドを80に替えて、URL RewriteをすべてDisableにすれば行けるのかもしれませんが未検証ですorz。

-- 2019/07/07追記2 --

バインドをポート80を追加して、URL RewriteをOFFにしてみたのですが、

おお、Web画面も動くしなんかうまくいってそうな感じ、、、とおもったら、PC上からのロボットトレイからの接続・切断がNGに、、┐('〜`;)┌。。

検証はまた後日かな、、、。

-- 2019/07/07追記 以上 --

-- 2019/07/08追記 --

うーん、どうしてもELB経由だと、Robotからの接続だけうまくいきませんね、、。というわけで、ロボット接続向けのURLを用意し、それはSSLのままIISにルーティング、それ以外のアクセスはHTTPでルーティング、ってやってみました。これには上記のURLごとに別のサーバへのルーティングする機構を用いてみました。

うまくいきました。

なんかもう、コレジャナイ感がハンパないんですが、、、。

追記追記でクシャクシャになってしまったので、いつか記事にしようかと思います

-- 2019/07/08追記 以上 --

-- 2019/07/15追記 --

記事にしました。

ELB(SSL)の内側に配置したEC2のUiPath Orchestrator(IISサーバ)をポート80で運用したい→ 妥協

-- 2019/07/15追記 以上 --


関連リンク