eijiです。私はいま現在はその形態で構築できています。
ソースも改修していません。
http://lv8737.subhost.jp/

> 共有SSLとホスティングされてるサーバが同一の場合の環境下

共有SSLのURL（https〜）と、80番ポートのURL（http〜）とで、参照先が同じホスト内であれば可能です。

レス、ありがとうございます。
すみません、言葉足らずでした。
「自前の専用ドメインで」共有SSLとホスティングされてるサーバが同一の場合の環境下
と言うつもりで、書き込んだのですが「専用ドメイン」が抜けてました。<m(__)m>

このスレでも指摘されてますし、他のスレ（http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=1897&forum=2&post_id=6624#forumpost6624）
でも上がってますが、恐らくEC-CUBEユーザの中の相当数の方が以下のような共有SSLを想定し、利用できることを希望されてると思い、質問したしだいです。

http://xoops.ec-cube.net/modules/mylinks/singlelink.php?cid=1&lid=1423
↑ここで紹介されてるのは、相当いじってあるのでしょうが、これが正規版でそのまま実現できれば、完璧なんですけど、現実はそんなにあまくなさそうですね。

eijiです。

お知らせいただいた作成事例（　http://xoops.ec-cube.net/modules/mylinks/singlelink.php?cid=1&lid=1423　）を拝見しました。
「カートへ入れる」ボタンをマウスオーバーすると「http:」でクリックするとリダイレクトされて「https:」にいくようですね。
事例紹介の文章にもありますように、カートから確認画面へ遷移する際に共有SSLへpostしているように思います。

> 「自前の専用ドメインで」共有SSLとホスティングされてるサーバが同一の場合の環境下

こちらは普通に独自ドメイン＋共有SSLのことだと思いますが、私の構築した環境の「subhost.jp」をご自身の独自ドメインに読み替えていただければと思います。

以下、私の環境で必要箇所を抜粋させていただきます。

[SUB HOST]
DOMAIN lv8737.subhost.jp
URL http://lv8737.trialserver.jp/~eiji/lv8737.subhost.jp/
Alias http://lv8737.subhost.jp/
SSL https://lv8737.securesites.net/~eiji/lv8737.subhost.jp/
※「http://」でも接続可能
PATH /home/eiji/www/lv8737.subhost.jp/

[ECCUBE Directory]
HTML /home/eiji/www/lv8737.subhost.jp/
DATA /home/eiji/www/data/
Admin https://lv8737.securesites.net/~eiji/lv8737.subhost.jp/admin/

[Apache Configure]
### MainHost Configure ###
UserDir enable
UserDir www
### VirtualHost Configure ###
<VirtualHost aaa.bbb.ccc.ddd:80>
SSLEngine off
ServerName lv8737.subhost.jp
DocumentRoot /home/eiji/www/lv8737.subhost.jp
ScriptAlias /cgi-bin/ "/home/eiji/www/cgi-bin/"
</VirtualHost>
<VirtualHost aaa.bbb.ccc.ddd:443>
SSLEngine on
ServerName lv8737.subhost.jp
DocumentRoot /home/eiji/www/lv8737.subhost.jp
</VirtualHost>

http://lv8737.subhost.jp/
にアクセスして商品をカゴに入れたのですが、
かごが空の状態になるのですが、私だけでしょうか？

当方でも空になりました。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

開発もとの説明では、以下の設定を実行するようになってますよね。

管理画面＞基本情報＞パラメータ管理で
「SESSION_KEEP_METHOD」を"useRequest"に変更し、
html/.htaccessで
php_flag session.use_trans_sid 1

それで、ご指摘のサイトでは、上記の設定がされてないのでは？

確かに、仮想ドメイン側で買物かごに入れた商品は、ホスティング先に
移動して、httpsになったとたんに空っぽになりますね。
その後、https側のドメインで再度買物かごに入れた商品からは、
正常に機能するようです。

mod_rewrite とかで、初回アクセスからリダイレクトさせたら? と思うけど。

ちなみに、上記のサイトでは、リダイレクト先も http なようですが…

ドメインが変わっているという事で、テスト的にはそれで良いのか??

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

今更ですが...

空になるのは　install.php で設定しているDOMAIN_NAMEと共有SSLのドメイン名が異なる事が原因です。

しかし、ここを共有SSLのドメイン名にすると、今度はhttpでアクセスした時にカートに入らなくなります。

この状態を回避するためには
・DOMAIN_NAMEを共有SSLにする
・共有SSLのカートに商品を入れるように改造する
必要があります。

この件についての解決済みの方いらっしゃいましたら是非お聞かせい頂きたいのですが・・・

現在coreserverで構築テストを行っています。
問題点は既に上がってますが、

1.共有SSLの場合のドメインにつないだ場合リバースプロクシが
　本来のサーバにHTTPで繋ぎにいく為、各サーバ変数が
　HTTPの場合のものと同じになってしまって画像やリンクのパスが
　正しくないもので出力される
2.セッションIDをクッキーで持たせる場合共有SSLのページと
　ドメインが違う為注文完了ページへ遷移する時に
　かごの中身がカラになる

といったところです。1.についてはinstall.phpの中に
リモートアドレスがリバースプロクシのIPだった場合に
サーバ変数、環境変数を書き換える処理を組み込むことで対応できます。
今のところREMOTE_ADDR,REQUEST_URI,SCRIPT_NAME,PHP_SELF,SERVER_PORT,HTTPS,SERVER_NAME,HTTP_HOST
を書き換えてやればこの問題は解消されています。
(書き換える権限を設定する為にphp.iniにsafe_mode_allowed_env_varsという設定を追記しておく必要があります)
2.についてはHTTPからHTTPSへ遷移する際に一時的にセッションIDを
GETやPOSTのパラメータで持たせて遷移先で受け取ったらセッションIDを書き換えて、
GETならばリクエストされたURIからセッションIDのパラメータだけを削って、
すぐに同じページにリダイレクトしなおすという処理で
HTTPとHTTPSのセッションを共有させることで動作しています。
(この処理はSC_SessionFactory_UseCookie.phpに組み込んでいます)
しかし、ここにきてセッションハイジャックの脆弱性の可能性がある事が分かり、
ログイン時にセッションを作り直してから再度クッキー共有する方法を考えている状態です。

すべて問題なく動けば、手順を整理して公開したいと思っています。