web-dev-qa-db-ja.com

分散トラフィックのある複数のApacheサーバーにLetsEncryptSSLを使用する

2つの異なるサーバーにセットアップされ、HAProxyを介してトラフィックが分散されているいくつかのWebサイトのLet'sEncryptのセットアップで問題が発生しています。

サーバーには多数のVHost /ドメインがあり、そのすべてにSSL証明書が必要です。この投稿のために、次のように言ってみましょう。

  1. foo.some-site.com
  2. bar.some-site.com

これらのAレコードは両方とも2つのIPアドレスで設定されています。 nwtools.comまたはnslookupを使用して、Aレコードの両方foo.some-site.comとbar.some-site.comが同じ2つのIPを解決することを確認できます。アドレス。また、Let's Encryptでは、ルックアップを実行できるように、vhostで有効なレコードを使用する必要があることを知っています。

すべてのvhostに対して両方のサーバーでLetsEncryptセットアップを実行することを計画し、一方のサーバーでは正常に機能しましたが、2番目のサーバーに移動すると、エラーが発生しました。

[root@server httpd]# /opt/letsencrypt/letsencrypt-auto --Apache -d foo.some-site.com
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --Apache -d foo.some-site.com
Failed authorization procedure. foo.some-site.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to Host for DVSNI challenge

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: foo.some-site.com
   Type:   connection
   Detail: Failed to connect to Host for DVSNI challenge

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

これは、ルックアップを実行しているか、カールしようとしているためである可能性がありますfoo.some-site.com、他のサーバーに転送されている可能性がありますか？ LetsEncryptが実際に接続をリッスンしていない限り、両方に同じVHostがあるため、それが実際にどのように重要になるかはわかりません...

私を失望させているのは、そのうちの1つでは問題なく機能したことです（たとえば、bar.some-site.com）。 ？

2つの異なるサーバー上の同じvhostに対してLetsEncryptをセットアップする方法を誰かが知っている場合は、助けていただければ幸いです。

centosapache-2.4haproxycentos7lets-encrypt
2
Justin

これは、ルックアップを実行しているか、foo.some-site.comをカールさせようとしていて、他のサーバーに転送されている可能性があるためでしょうか。

はい、間違いなく。

LEは、ドメイン検証チャレンジ/レスポンスプロセスの一環として、LEクライアントを実行しているサーバーに接続し直す必要があります。詳細に立ち入ることなく、LEクライアントは実際に、ドメインの所有権を確認するためにLEサーバーが使用できる必要がある特定のファイルを一時的にWebサーバーで使用できるようにします。

すべてのバックエンドサーバーでこのコマンドを実行することは、不必要で面倒です。一度実行してから、キーと証明書チェーンを残りのバックエンドサーバーにコピーします。

何が私を失望させますか？それはそれらの1つ（たとえばbar.some-site.com）でうまく機能したのに、なぜそれは1つのサイトでは機能するのに、まったく同じ設定の別のサイトでは失敗するのでしょうか？

ラッキーだったから？ :)ロードバランサーがLEリクエストを正しい場所に一度送信したが、2回目は送信しなかった可能性があります。

5
EEAA

複数のWeb /アプリサーバー/ロードバランサーを含むシナリオには、いくつかのアプローチがあります。大規模な環境の場合は、 Official Let's Encrypt Integration Guide でそれらのいくつかについて読むことができます。

それを行うには、次のようないくつかのきちんとした方法があります。

  • すべての検証リクエストを単一の検証ホスト/ホストプールにリダイレクトする
  • すべての証明書管理をオフラインで実行する（つまり、Webサーバーではなく、管理ホストからキーを要求、更新、および配布する）

何が理にかなっているのかは、好みやさまざまな環境固有の要件によって異なります。

1
Josh Richards