【CORESERVER】共有SSLの注意点【HTTPS】

かねてから、運営サイトのログイン機能をSSLで運用したいと考えており、本日、CORESERVERの共有SSLの導入に挑戦してみました。

しかし、結論から言うと、失敗に終わりました。
その顛末を覚書しておきます。

失敗した最大の要因は、SSLページと非SSLページ間でのセッションの持ち回しが、ほぼ不可能だったからです。

まず、前提です。例として、運営サイトのURLを下記のようにすると、SSLのURLは次のようになります。(CORESERVERの場合)

http://example.com
https://ss1.coressl.jp/example.com

上記の運用で、ログインページをSSL接続して、認証に成功したら、非SSLページに遷移する方法を採用したかったのですが、駄目でした。

理由は、先にも述べたように、SSLページと非SSLページ間でのセッションの持ち回しが、できなかったからです

なぜ、セッションの持ち回しができないのか?それは、ドメインが異なるため、セッションIDのクッキー(セッションクッキー)が、SSLと非SSLで引き継げないから。

たとえ、SSLページで認証に成功して必要な情報をセッションに格納しても、非SSLページに遷移すると、そのセッションは使うことが出来ず、非SSLページにおける、セッションの中身は、空になっていました。

言語は、PHPを使っていたのですが、そもそもクッキーの利用では、別ドメイン間で使用できなのは、仕様上、仕方ないようです。いわゆるクロスドメイン間のクッキー利用の制限。

この対策として、裏技的に、非SSLページに遷移する際、クッキーのセッションIDを、GETパラメーター等として、送ることも出来ますが、これでは、SSLの意味がなくなってしまいます。むしろ、セッションIDがURLに露見することで、却って、セキュリティ上有害ともいえます。

また、共有のSSLには、共有であるが故に、他の利用者とのクッキーの重複の問題や、なりすまし等の問題も少なからずあるようです。

正当な対策としては、共有や共用でない、独自のSSL証明書を購入して、httpとhttpsでドメインが異ならない運用をするしかないようです。

運営サイトで利益が十分にあれば、独自のSSL証明書の購入もできますが、そうでないと中々難しいですね。いずれにしても、遠くないうちに、独自SSLの導入を果たしたいと思います。

カテゴリー: PHP, WEB, XREA/CORESERVER パーマリンク

広告

コメントを残す

メールアドレスが公開されることはありません。