[英]Crossbar SSL/TLS configuration with intermediate and cross-signed certificates
使用最新版本的Crossbar （0.13，從Ubuntu 14.04上的apt-get安裝），我無法使用SSL和中間證書建立連接。
如果我在tls鍵中設置的服務器沒有ca_certificates屬性，則服務器可以正常運行，並且可以通過wss協議使用Google Chrome瀏覽器建立連接。 但是，嘗試通過直通建立連接失敗，並顯示以下錯誤：
無法連接：無法完成SSL / TLS握手：stream_socket_enable_crypto（）：SSL操作失敗，代碼為1。OpenSSL錯誤消息：錯誤：14094410：SSL例程：ssl3_read_bytes：sslv3警報握手失敗
與Thruway團隊交談的似乎是證書問題-在我們的實時站點上，我們使用了來自Gandi的中間交叉簽名證書 ，某些瀏覽器因而需要一些open-ssl實施所需。
看起來，盡管瀏覽器很樂意僅通過密鑰和證書建立TLS連接，但Thruway需要鏈條。 然而下面使用由甘地提供的兩個證書或者 Chrome或高速公路不起作用的配置。 Chrome顯示錯誤：
失敗：WebSocket打開握手已取消
使用下面的.crossbar/config.json文件時。 那么，這是我的配置，我的證書還是Open-SSL堆棧的其他部分的問題？
（下面的文件已被更改，以刪除任何潛在的敏感信息，因此可能由於其他原因而無法使用。如果連接有效，則基本身份驗證和其他組件均能正常工作，因此請保留有關TLS實現的答案/評論。注釋不是有效的JSON，但包含在內，因此讀者可以看到正在使用的證書文件）
{
"version": 2,
"controller": {},
"workers": [
{
"type": "router",
"realms": [
{
"name": "test",
"roles": [
{
"name": "web",
"authorizer": "test.utils.permissions",
"disclose": {
"caller": true,
"publisher": true
}
},
{
"name": "no",
"permissions": []
}
]
}
],
"transports": [
{
"type": "websocket",
"endpoint": {
"type": "tcp",
"port": 9001,
"interface": "127.0.0.1"
},
"auth": {
"wampcra": {
"type": "static",
"users": {
"authenticator": {
"secret": "authenticator-REDACTED",
"role": "authenticator"
}
}
}
}
},
{
"type": "web",
"endpoint": {
"type": "tcp",
"port": 8089,
"tls": {
"key": "../ssl/key.pem",
"certificate": "../ssl/cert.pem",
"ca_certificates": [
"../ssl/gandi.pem", // https://www.gandi.net/static/CAs/GandiProSSLCA2.pem
"../ssl/gandi-cross-signed.pem" // https://wiki.gandi.net/en/ssl/intermediate#comodo_cross-signed_certificate
],
"dhparam": "../ssl/dhparam.pem"
}
},
"paths": {
"/": {
"type": "static",
"directory": "../web"
},
"ws": {
"type": "websocket",
"url": "wss://OUR-DOMAIN.com:8089/ws",
"auth": {
"wampcra": {
"type": "dynamic",
"authenticator": "test.utils.authenticate"
}
}
}
}
}
]
},
{
"type": "guest",
"executable": "/usr/bin/env",
"arguments": [
"php",
"../test.php",
"ws://127.0.0.1:9001",
"test",
"authenticator",
"authenticator-REDACTED"
]
}
]
}
還有其他問題可以解決與此this @類似的問題
這不是Crossbar的問題。 這似乎是WAMP客戶端-Thruway的問題。 Davidwdan是Thruway Github回購協議的所有者，他說：
“ Thruway的Ratchet傳輸提供程序不直接支持SSL。您需要在其前面放置某種代理。”
您可以在https://github.com/voryx/Thruway/issues/163上找到有關Davidwdan和其他人對此有何評論的更多信息。
現在開始解決。 請注意，以下內容僅適用於Apache用戶。 如果您在Nginx上運行，則想法幾乎相同。
在開始之前，需要注意幾件事。
您要做的第一件事是創建一個新的虛擬主機。 我為該虛擬主機選擇了端口4043，但是您可以選擇任何想要的端口。 該虛擬主機將用於每個通過wss：//（使用SSL）連接沒有問題的WAMP庫。 這是WAMP客戶端的完整列表： http ://wamp-proto.org/implementations/。 確保ProxyPass指令和ProxyPassReverse指令的IP地址指向CROSSBAR路由器所在的計算機。 就我而言，因為Apache和Crossbar在同一台計算機上運行，所以我只使用127.0.0.1。 另外，還要確保ProxyPass指令和ProxyPassReverse指令中使用的端口與您在.crossbar / config.json中定義的端口完全相同！ 您還將還需要在此虛擬主機上設置SSL證書，您可以看到我已在Proxy指令下面添加了SSL證書。
Listen 4043
<VirtualHost *:4043>
ServerName example.org
ProxyRequests off
SSLProxyEngine on
ProxyPass /ws/ ws://127.0.0.1:8000/
ProxyPassReverse /ws/ ws://127.0.0.1:8000/
## Custom fragment
SSLEngine on
SSLCertificateFile /path/to/server_cert.pem
SSLCertificateKeyFile /path/to/server_key.pem
SSLCertificateChainFile /path/to/server_ca.pem
</VirtualHost>
接下來，請確保您的Crossbar路由器未設置SSL！ 這是非常重要的。 如果您將路由器配置為使用SSL，則Thruway或任何其他無法通過SSL連接的庫將無法使用路由器！ 下面是一個可以使用的Crossbar config.json工作文件。
{
"version": 2,
"controller": {},
"workers": [
{
"type": "router",
"realms": [
{
"name": "production_realm",
"roles": [
{
"name": "production_role",
"permissions": [
{
"uri": "",
"match": "prefix",
"allow": {
"call": true,
"register": true,
"publish": true,
"subscribe": true
}
}
]
}
]
}
],
"transports": [
{
"type": "websocket",
"endpoint": {
"type": "tcp",
"port": 8000
},
"options": {
"allowed_origins": ["http://*","https://*"]
},
"auth": {
"ticket": {
"type": "static",
"principals": {
"production_user": {
"ticket": "tSjlwueuireladgte",
"role": "production_role"
}
}
}
}
}
]
}
]
}
注意上面定義的端口號如何與虛擬主機中定義的端口號匹配。
./crossbar/config.json：
"endpoint": {
"type": "tcp",
"port": 8000
},
虛擬主機：
ProxyPass /ws/ ws://127.0.0.1:8000/
ProxyPassReverse /ws/ ws://127.0.0.1:8000/
另外，如果您閱讀其他教程，某些人會告訴您確保您在虛擬主機文件中使用ProxyPreserveHost指令。 不要聽他們！ 這會產生很多意想不到的結果。 啟用此指令后，此選項會將Host：行從傳入請求傳遞到代理主機，而不是ProxyPass行中指定的主機名！ 甚至Apache也表示要遠離此指令https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypreservehost 。 如果確實啟用了它，您將收到類似於以下的錯誤：
failing WebSocket opening handshake ('missing port in HTTP Host header
'example.org' and server runs on non-standard port 8000 (wss =
False)')
最后但並非最不重要的一點，請確保已安裝並啟用以下所有Apache庫。 在最近的Apache安裝中，默認情況下會安裝以下所有庫，只需啟用它們即可：
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2enmod proxy_balancer
$ sudo a2enmod lbmethod_byrequests
$ sudo a2enmod proxy_wstunnel
確保打開您的虛擬主機文件正在偵聽的端口以及交叉開關路由器正在偵聽的端口。 就我而言：
$ sudo ufw allow 4043
$ sudo ufw allow 8000
最后重啟Apache，使所有更改生效。
$ sudo service apache2 restart
最后但並非最不重要的一點是，我想快速解釋為什么必須完成所有這些操作：
好吧...。這就是所有人！ 我知道我需要給這個問題一個詳細的答案，因為花了我5天的時間才能解決所有問題！
@ Tay-Bae的答案已經非常有用。 但這對我不起作用，客戶得到200 OK響應。 我要做的就是將WSS通信轉發到不支持WSS（Thruway）的內部WS客戶端。 在論壇上查看后，我偶然發現了這個答案： https ://serverfault.com/a/846936。 他們添加了一個重寫部分，似乎是重新路由請求所必需的。 我以為ProxyPassReverse應該這樣做，但事實並非如此。 所以這是我的工作配置：
Listen 4043
<VirtualHost *:4043>
ServerName mydomain.net
ProxyRequests off
SSLProxyEngine on
ProxyPass /ws/ ws://127.0.0.1:8080/
ProxyPassReverse /ws/ ws://127.0.0.1:8080/
## Custom fragment
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mydomaine.net/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mydomain.net/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mydomain.net/chain.pem
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
RewriteRule .* ws://localhost:8080%{REQUEST_URI} [P]
</IfModule>
LogLevel debug
ErrorLog ${APACHE_LOG_DIR}/error_thruway.log
CustomLog ${APACHE_LOG_DIR}/access_thruway.log combined
</VirtualHost>
通過交叉開關WAMP路由器使用Lets Encrypt SSL證書（0.13）
[英]Using Lets Encrypt SSL certificates with crossbar WAMP router (0.13)
在 iOS 13 上為 WebSocket over TLS 信任自簽名證書
[英]Trust self-signed certificates on iOS 13 for WebSocket over TLS
如何使用自簽名證書從Javascript連接到SSL Server？
[英]How to connect to SSL Server from Javascript, using self-signed certificates?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.