パーソナルサーバーに独自のオープンIDプロバイダーをセットアップし、Apache構成ファイルにhttpsへのリダイレクトを追加しました。安全な接続を使用していない場合（リダイレクトを無効にした場合）は正常にログインできますが、リダイレクトを使用すると、次のエラーメッセージが表示されてログインできません。
基になる接続が閉じられました：SSL/TLSのセキュリティで保護されたチャネルの信頼関係を確立できませんでした。
これは、自己署名証明書を使用しているためだと思います。
自己署名証明書が問題であるかどうかを誰かが確認できますか？そうでない場合、問題が何であるかについて誰かが何か考えを持っていませんか？
OpenID URL に SSL を使用する主な利点は、DNS が改ざんされているかどうかを検出するメカニズムを依存者に提供することです。証明書利用者は、自己署名証明書を含む OpenID URL が侵害されたかどうかを判断することはできません。
プロバイダーのエンドポイント URL で SSL を使用することで得られるその他の利点 (関連付けの確立が容易で、拡張データの盗聴がない) は、自己署名証明書を使用した場合でも保持されますが、それらは二次的なものと見なします。
OpenIDは、リダイレクト透過的な方法で設計されています。GETまたはPOSTのいずれかによって、必要なキーと値のペアが各リダイレクトで保持されている限り、すべてが正しく動作します。
自己署名証明書を使用しないコンシューマーとの互換性を実現する最も簡単なソリューションは、暗号化されたエンドポイントにメッセージをリダイレクトcheckid_immediateするcheckid_setup暗号化されていないエンドポイントを使用することです。
サーバーコードでこれを行うことは、Webサーバーリダイレクトを使用するよりも簡単です。前者は、コードをまとめながら、POST要求をより簡単に処理できるためです。さらに、適切なチェックが行われている限り、SSLを介して提供する必要があるかどうかに関係なく、同じエンドポイントを使用してすべてのOpenID操作を処理できます。
たとえば、PHPでは、リダイレクトは次のように単純にすることができます。
// Redirect OpenID authentication requests to https:// of same URL
// Assuming valid OpenID operation over GET
if (!isset($_SERVER['HTTPS']) &&
($_GET['openid_mode'] == 'checkid_immediate' ||
$_GET['openid_mode'] == 'checkid_setup'))
http_redirect("https://{$_SERVER['HTTP_HOST']}{$_SERVER['REQUEST_URI']}");
値はプレーンなHTTPエンドポイントに対して生成されたopenid.return_toため、コンシューマーに関する限り、暗号化されていないサーバーのみを処理します。セッションとナンスを使用したOpenID2.0の適切な動作を想定すると、コンシューマーとサーバーの間で受け渡される情報が悪用可能な情報を明らかにすることはありません。悪用可能なブラウザとOpenIDサーバー間の操作（パスワードスヌーピングまたはセッションCookieハイジャック）は、暗号化されたチャネルを介して行われます。
盗聴者を排除する以外に、SSLを介して認証操作を実行することで、secureHTTPcookieフラグを使用できます。checkid_immediateこれにより、必要に応じて、操作をさらに保護するレイヤーが追加されます。
(免責事項: 私は OpenID を初めて使用するので、ここで間違っている可能性があります。) Open ID コンシューマー (例: StackOverflow) と Open ID プロバイダー (サーバー) の間の通信には、HTTPS は必要ありません。HTTPS と同じように機能します。プレーンな HTTP で問題なく安全に使用できます。必要なことは、ログイン ページが表示されたときにのみ HTTPS に切り替えるようにサーバーを構成することです。その場合、ブラウザだけが自己署名証明書に関係する必要があります。証明書を PC にインポートすると、すべてが Verisign 発行の証明書と同じくらい安全になります。
それのように聞こえます。OpenIDサーバーのクライアントは、ルート証明機関を信頼していません。