2016-07-31 48 views
0

我一直在嘗試與我的託管服務提供商進行一個多月的溝通,但我99%確定他們甚至不讀取門票並響應隨機生成的字符串話。共享主機帳戶上的SSL握手錯誤

我搜索了幾個星期的答案,我看到一些關於更新Java或修改我無權訪問的文件的提及。現在,這是對我來說發生的事情。如果我嘗試驗證我的域名與W3C或嘗試驗證Twitter的卡,我不斷收到SSL握手錯誤:

ERROR: Fetching the page failed because SSL handshake error.

我從Comodo通配符SSL。 如果我刪除的.htaccess W3C只會驗證這些線路,但Twitter卡不:

RewriteCond %{HTTPS} !=on 
RewriteCond %{HTTP_HOST} ^www.iadb.com$ [OR] 
RewriteCond %{HTTP_HOST} ^iadb.com$ 
RewriteRule^https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] 

不幸的是,如果我改變這種情況,HTTPS是不以任何方式強制執行,更何況,它並沒有解決Twitter問題。同樣,由於它是共享主機,因此我無法訪問除.htaccess之外的任何配置 - 我將不勝感激任何幫助或提示,即使它只是告訴我我是SOL。

+0

你究竟在哪裏得到錯誤?假設那是你的網站,https://iadb.com/似乎工作正常。 –

回答

0

openssl s_client和數據包捕獲一些測試顯示,您的服務器級別的警告,如果你訪問該主機爲iadb.com但使用www.iadb.com如hostname當TLS警報不會發生返回TLS警報unregognized_name。但是由於您從https://www.iadb.com重定向到http://iadb.com,您最終會收到包含此TLS警報的連接。

儘管TLS警報級別僅警告某些實現(openssl 0.9.8,Java)將其解釋爲導致握手失敗的錯誤。這就是你所看到的,例如與W3C驗證:

IO Error: handshake alert: unrecognized_name 

雖然這個客戶端軟件的行爲顯然錯了,它也很糟糕,服務器在所有發送此TLS警報。我的猜測是,這是由於服務器僅配置爲主機名www.iadb.com而不是iadb.com,但您明確使用後者的名稱。自行解決問題的一種方法是僅使用www.iadb.com。另一種方法是修復根據您的描述只能由託管服務提供商完成的服務器配置。

+0

我想這是總的感覺。由於SSL具有通配符,因此可能未配置爲正確處理裸域。我強迫www。使用htaccess來代替。這可能會對搜索引擎造成問題,但應該從長遠來看付出代價。謝謝Steffen – user2706469