I am trying to connect to wss://mydomain.com/ws from electron app (render process), but:
events.js:177 Uncaught Error: unable to verify the first certificate
at TLSSocket.onConnectSecure (_tls_wrap.js:1317)
at TLSSocket.emit (events.js:200)
at TLSSocket._finishInit (_tls_wrap.js:792)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:606)
I am using same code which works from plain Chrome and Firefox browsers
const WebSocket = require('isomorphic-ws')
const ws = new WebSocket('wss://mydomain.com/',
[],
{
headers: {
Cookie: cookie.serialize('X-Authorization', bearerToken),
},
},
);
I used https://www.ssllabs.com/ssltest/analyze.html?d=mydomain.com
to check certificate and it says:
Protocols
TLS 1.3 No
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
For TLS 1.3 tests, we only support RFC 8446.
However I can't see request in electron devtools, so can't verify tls version
Using https://www.ssllabs.com/ssltest/ I discovered
Chain issues.........Incomplete
So I fixed it on nginx side, before I used:
ssl_certificate /www/xx/certs/mydomain_com.crt;
ssl_certificate_key /www/xx/certs/live_server.key;
Now I did:
cat mydomain-com.crt mydomain-com.ca-bundle > mydomain_com.ca-bundle.crt
And changed in nginx:
ssl_certificate /www/xx/certs/mydomain_com.ca-bundle.crt;
ssl_certificate_key /www/xx/certs/live_server.key;
Related
I Have a simple back-end Kotlin application that runs a Netty server on a Google cloud virtual machine. It receives websocket connections and sends some simple messages to clients. I also have nginx server running on same machine, it listens to 443 port and redirects requests to my application (127.0.0.1:8080). Here is nginx configuration:
server {
listen 443 ssl;
server_name www.mydomain.com;
ssl_certificate /etc/nginx/certs/my-cert.crt;
ssl_certificate_key /etc/nginx/certs/my-key.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_read_timeout 86400;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $http_host;
}
}
Ssl certificate in config is valid and certified by real CA.
Now I'm trying to write a simple front-end Angular app that connects to my proxy:
return webSocket({
url: `wss://www.mydomain.com/${path}`,
closeObserver: {
next: (event: CloseEvent) => { console.log(event) }
}
}).multiplex(() => {}, () => {}, () => true)
I am subscribing to an Observable returned by this method and printing incoming messages.
All this works fine in every browser except Google Chrome. (I tried Firefox, Opera, Chromium, Edge). Also everything works in chrome extension Smart Websocket Client. It even works fine in Chrome's incognito mode, but fails in ragular mode.
On chrome I get
WebSocket connection to 'wss://mydomain.com/something' failed.
CloseEvent that I log isn't very helpful, it just says that the code is 1006, the field reason is empty.
When I bypass the proxy and connect directly to my app with ws://www.mydomain.com:8080/something, it works fine on chrome.
I guess something is wrong in my nginx config, buy I cant really tell what. All the guides for configuring nginx for websockets say that this is how it should be configured.
I spent 2 days searching for information about this and didn't find any real answers to why this is happening and what can I do to fix it.
Does anyone have any ideas why is this happening?
UPDATE
Here is another interesting thing. I wrote a simple script that connects to my proxy, just like my Angular app, but using standard api.
let ws = new WebSocket("wss://mydomain.com/something");
ws.onmessage = (ev) => {
console.log(ev.data);
document.getElementById("result").innerHTML += ev.data
};
ws.onerror = (err) => {
console.log(err)
}
When I just open this file in chrome using file://, everything works. It connects to my ws server and prints incoming messages on screen. But when I run local Apache server and serve the same file on localhost:80, I get the same error as before in Chrome. (Other browsers and Incognito mode still work fine when the file is accessed through localhost)
So this issue doesn't have much to do with Angular.
You mentioned that in private/incognito mode it works, have you tried to disable all extensions and connect to websocket?
I've been trying to set up a webserver on localhost which supports HTTP/3. I've successfully run an caddy server run in docker which answers to GET requests with this header:
alt-svc: h3-27=":443"; ma=2592000
content-encoding: gzip
content-length: 1521
content-type: text/html; charset=utf-8
date: Thu, 07 May 2020 07:27:44 GMT
server: Caddy
status: 200
vary: Accept-Encoding
X-DNS-Prefetch-Control: off
Even though the alt-scv header was received I couldn't detect any h3-27 requests in the network logs of the developer tools.
Also created a CA, which I added to chrome, and signed the certificate of the server which Chrome accepts. I ran Chrome with the flags --enable-quic --quic-version="h3-27", as suggested in this article. I've tried the same with an nginx server based on this image and couldn't make it work as well.
What am I missing?
Caddyfile:
{
experimental_http3
}
localhost {
root * /usr/share/caddy/
encode zstd gzip
templates
file_server
tls /etc/caddy/certs/localhost.crt /etc/caddy/certs/localhost.key
}
Caddy Output:
2020/05/07 07:23:50.939 INFO using provided configuration {"config_file": "/etc/caddy/Caddyfile", "config_adapter": "caddyfile"}
2020/05/07 07:23:51.252 INFO admin admin endpoint started {"address": "tcp/localhost:2019", "enforce_origin": false, "origins": ["127.0.0.1:2019", "localhost:2019", "[::1]:2019"]}
2020/05/07 07:23:51 [INFO][cache:0xc00088da90] Started certificate maintenance routine
2020/05/07 07:23:51 [WARNING] Stapling OCSP: no OCSP stapling for [localhost bar.localhost]: no OCSP server specified in certificate
2020/05/07 07:23:51.254 INFO http skipping automatic certificate management because one or more matching certificates are already loaded {"domain": "localhost", "server_name": "srv0"}
2020/05/07 07:23:51.254 INFO http enabling automatic HTTP->HTTPS redirects {"server_name": "srv0"}
2020/05/07 07:23:51.255 INFO tls cleaned up storage units
2020/05/07 07:23:51.256 INFO http enabling experimental HTTP/3 listener {"addr": ":443"}
2020/05/07 07:23:51.257 INFO autosaved config {"file": "/config/caddy/autosave.json"}
2020/05/07 07:23:51.257 INFO serving initial configuration
Found the reason myself. The current version of Chrome (Version 81.0.4044.138) does not support this version of Quic (h3-27). It could be fixed by using using chrome-dev (Version 84.0.4136.5).
I has configed my nginx for a http2 service
worker_processes 2;
events {
worker_connections 1024;
multi_accept on;
use epoll;
}
http {
sendfile on;
server {
listen 80;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl http2;
ssl_certificate /usr/cer/server.cer;
ssl_certificate_key /usr/cer/server.key;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
}
and with log message
Chrome 51.0.2704.84
Safari 9.1.1
Firefox 47.0
reason:
To address this, Google developed a new transport layer named SPDY. SPDY was accessed over SSL/TLS, and Google developed an SSL/TLS modification called Next Protocol Negotiation (NPN) that allows clients to upgrade their SSL/TLS connections from HTTP/1 to HTTP/2. Major web servers (such as NGINX) implemented SPDY; OpenSSL and other SSL/TLS stacks implemented NPN.
solution
Recompile NGINX from source and use a private build with OpenSSL 1.0.2
I'm attempting to configure HAProxy to serve an RSA or ECC certificate depending on the client's browser. I initially am trying to get ECC certificates configured, and I noticed that the latest version of Chrome does not support them. Wondering if anyone else is having this problem? I am using OS X 10.11.4 with the following versions:
Chrome (50.0.2661.94) (64-bit) [doesn't work]
Firefox (46.0) (64-bit) [works]
Safari (9.1 11601.5.17.1) (64-bit) [works]
cURL (7.43.0 (x86_64-apple-darwin15.0) libcurl/7.43.0 SecureTransport zlib/1.2.5) [works]
The cURL command I call via curl --ciphers ecdhe_ecdsa_aes_128_sha --ssl --head --tlsv1.2 https://<url> and it returns 200 OK.
And I am using Ubuntu Xenial 16.04 LTS on the server side with the following versions:
[root#haproxy-server]: /etc/haproxy # haproxy -vv
HA-Proxy version 1.6.4 2016/03/13
Copyright 2000-2016 Willy Tarreau <willy#haproxy.org>
Build options :
TARGET = linux2628
CPU = generic
CC = gcc
CFLAGS = -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
OPTIONS = USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
Default settings :
maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2g 1 Mar 2016
Running on OpenSSL version : OpenSSL 1.0.2g-fips 1 Mar 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.38 2015-11-23
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.1
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Here's the screenshot of the exact problem: http://imgur.com/wlmQbIi
Here's the screenshot of the same website with Safari: http://imgur.com/FEwmmj9
And finally, my haproxy.cfg file:
global
log /dev/log local0
log /dev/log local1 notice
user haproxy
group haproxy
chroot /var/lib/haproxy
daemon
stats socket /run/haproxy/admin.sock level admin
maxconn 15000
spread-checks 5
tune.ssl.default-dh-param 2048
tune.ssl.maxrecord 1400
tune.idletimer 1000
ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
ssl-default-server-ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
ssl-default-server-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets
defaults
log global
mode http
retries 3
balance roundrobin
hash-type map-based
option httplog
option dontlognull
option forwardfor
option http-server-close
option redispatch
option abortonclose
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 30s
timeout http-keep-alive 10s
timeout check 10s
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend http-frontend
bind *:80 accept-proxy
reqadd X-Forwarded-Proto:\ http
use_backend %[req.hdr(host),lower,map_sub(/etc/haproxy/backend.map,test-backend)]
frontend https-frontend
bind *:443 accept-proxy ssl crt /etc/ssl/pem/ecc alpn http/1.1
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r\ ssl_version:%sslv\ ssl_cipher:%sslc\ %[ssl_fc_sni]\ %[ssl_fc_npn]
rspadd Strict-Transport-Security:\ max-age=31536000;\ includeSubdomains;\ preload
rspadd X-Frame-Options:\ DENY
reqadd X-Forwarded-Proto:\ https
use_backend %[req.hdr(host),lower,map_sub(/etc/haproxy/backend.map,test-backend)]
backend test-backend
balance leastconn
redirect scheme https code 301 if !{ ssl_fc }
server test-server 10.10.10.40:80 check
I know this post is not in the right seciton of StackExchange (sorry!) but I wanted to post a potential solution. I think the problem is the elliptic curves support in Chrome vs. Firefox vs. Safari. From the SSLLabs website:
Safari 9 / OS X 10.11: secp256r1, secp384r1, secp521r1
Firefox 44 / OS X: secp256r1, secp384r1, secp521r1
Chrome 48 / OS X: secp256r1, secp384r1
The problem is the private key for the ECC certificate I was testing was generated with secp521r1 (http://imgur.com/dbrJQuW), which the latest version of Chrome on OS X 10.11 doesn't support.
See this issue: https://security.stackexchange.com/questions/100991/why-is-secp521r1-no-longer-supported-in-chrome-others
It seems that only the following two cipher suite are supported by your web server:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
I suppose that missing some cipher suite (at least TLS_RSA_WITH_AES_128_CBC_SHA) is the reason of your problem.
The cipher suite TLS_RSA_WITH_AES_128_CBC_SHA must be supported in TLS 1.2 (see the section 9 Mandatory Cipher Suites or RFC5246). In the same way I would you recommend to see forward and to include protocols
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
and the suites
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
are strictly recommended too. See TLS 1.3 specification. You use Nginx web server, which should support TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, which are very good because of combination the security and the performance. I'd recommend you to include all the Cipher Suites.
I'd recommend you additionally to use or at least to examine carefully the recommendation of Nginx setting for modern or intermediate web browsers by Mozilla SSL Configuration Generator. You can read more about the suites here.
OS: Ubuntu 12.04 64-bit
PHP version: 5.4.6-2~precise+1
When I test an https page I am writing through the built-in webserver (php5 -S localhost:8000), Firefox (16.0.1) says "Problem loading: The connection was interrupted", while the terminal tells me "::1:37026 Invalid request (Unsupported SSL request)".
phpinfo() tells me:
Registered Stream Socket Transports: tcp, udp, unix, udg, ssl, sslv3,
tls
[curl] SSL: Yes
SSL Version: OpenSSL/1.0.1
openssl:
OpenSSL support: enabled
OpenSSL Library Version OpenSSL 1.0.1 14 Mar 2012
OpenSSL Header Version OpenSSL 1.0.1 14 Mar 2012
Yes, http pages work just fine.
Any ideas?
See the manual section on the built-in webserver shim:
http://php.net/manual/en/features.commandline.webserver.php
It doesn't support SSL encryption. It's for plain HTTP requests. The openssl extension and function support is unrelated. It does not accept requests or send responses over the stream wrappers.
If you want SSL to run over it, try a stunnel wrapper:
php -S localhost:8000 &
stunnel3 -d 443 -r 8080
It's just for toying anyway.
It's been three years since the last update; here's how I got it working in 2021 on macOS (as an extension to mario's answer):
# Install stunnel
brew install stunnel
# Find the configuration directory
cd /usr/local/etc/stunnel
# Copy the sample conf file to actual conf file
cp stunnel.conf-sample stunnel.conf
# Edit conf
vim stunnel.conf
Modify stunnel.conf so it looks like this:
(all other options can be deleted)
; **************************************************************************
; * Global options *
; **************************************************************************
; Debugging stuff (may be useful for troubleshooting)
; Enable foreground = yes to make stunnel work with Homebrew services
foreground = yes
debug = info
output = /usr/local/var/log/stunnel.log
; **************************************************************************
; * Service definitions (remove all services for inetd mode) *
; **************************************************************************
; ***************************************** Example TLS server mode services
; TLS front-end to a web server
[https]
accept = 443
connect = 8000
cert = /usr/local/etc/stunnel/stunnel.pem
; "TIMEOUTclose = 0" is a workaround for a design flaw in Microsoft SChannel
; Microsoft implementations do not use TLS close-notify alert and thus they
; are vulnerable to truncation attacks
;TIMEOUTclose = 0
This accepts HTTPS / SSL at port 443 and connects to a local webserver running at port 8000, using stunnel's default bogus cert at /usr/local/etc/stunnel/stunnel.pem. Log level is info and log outputs are written to /usr/local/var/log/stunnel.log.
Start stunnel:
brew services start stunnel # Different for Linux
Start the webserver:
php -S localhost:8000
Now you can visit https://localhost:443 to visit your webserver: screenshot
There should be a cert error and you'll have to click through a browser warning but that gets you to the point where you can hit your localhost with HTTPS requests, for development.
I've been learning nginx and Laravel recently, and this error has came up many times. It's hard to diagnose because you need to align nginx with Laravel and also the SSL settings in your operating system at the same time (assuming you are making a self-signed cert).
If you are on Windows, it is even more difficult because you have to fight unix carriage returns when dealing with SSL certs. Sometimes you can go through the steps correctly, but you get ruined by cert validation issues. I find the trick is to make the certs in Ubuntu or Mac and email them to yourself, or use the linux subsystem.
In my case, I kept running into an issue where I declare HTTPS somewhere but php artisan serve only works on HTTP.
I just caused this Invalid request (Unsupported SSL request) error again after SSL was hooked up fine. It turned out to be that I was using Axios to make a POST request to https://. Changing it to POST http:// fixed it.
My recommendation to anyone would be to take a look at where and how HTTP/HTTPS is being used.
The textbook definition is probably something like php artisan serve only works over HTTP but requires underlying SSL layer.
Use Ngrok
Expose your server's port like so:
ngrok http <server port>
Browse with the ngrok's secure public address (the one with https).
Note: Though it works like a charm, it seems an overkill since it requires internet and would appreciate better recommendations.