IPアドレスx.x.x.xのサーバーにcURLリクエストを送信しようとしています。これは、ヘルスモニタリングシステムの一部です。サーバーで、ポート80と443の両方でsubdomain.example.comの仮想ホストを構成しました。ssl証明書には、このサーバーで使用する* .example.comワイルドカード証明書といくつかのサーバーを使用しています。
カールしようとするとhttp://x.x.x.x
適切に応答を取得します。しかし、私がhttps://x.x.x.x
次の証明書エラーが発生します:
curl:(51)SSL:証明書のサブジェクト名 '* .example.com'がターゲットホスト名 'x.x.x.x'と一致しません
これは、証明書がドメイン名に固有であり、IPアドレスを使用してリクエストを送信しようとしているためです。しかし、私が言ったように、これは私が持っている制限です(ラックスペースロードバランサーのヘルスモニタリング)。
回避策はありますか?
まったく違う方向に進んでいるので、これを新しい答えにします。実際、それは提起された質問に答えるものではありませんが、おそらくOPが見ているべき方向です。
ロードバランサーを使用する場合の通常の構成は、SSL証明書がWebサーバー上にまったく存在せず、SSLがロードバランサーに渡されるというものです。
エンドユーザーがロードバランサーにHTTPSリクエストを送信します。ロードバランサーはSSLをラップ解除し、暗号化されていないHTTP経由でWebサーバーに要求を転送します。ヘッダーには、元の要求が暗号化されたことをWebサーバーに通知します。 (応答にURLを埋め込むため、およびhttp経由で安全なコンテンツが提供されないようにするために重要です)。
通常どおりドメイン名を使用できますが、次のようにリゾルバをオーバーライドします。
curl -v --resolve subdomain.example.com:443:x.x.x.x https://subdomain.example.com/
しかし、そのようなマッピングをたくさん維持するのは面倒かもしれません。証明書の不一致を無視することをお勧めします。
curl --insecure https://subdomain.example.com/
必要に応じて、--insecure --verbose
を使用してメッセージを解析し、証明書が予期されたドメインのものであることを確認できますが、--resolve
を使用するよりも多くの作業が必要です。