かねてから、運営サイトのログイン機能を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の導入を果たしたいと思います。