NGINX acting as a caching proxy encounters problems when fetching content from CloudFront server over HTTPS:
This is the extract from the NGINX's error log:
2014/08/14 16:08:26 [error] 27534#0: *11560993 SSL_do_handshake() failed (SSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) while SSL handshaking to upstream, client: 82.33.49.135, server: localhost, request: "GET /static/images/media-logos/best.png HTTP/1.1", upstream: "https://x.x.x.x:443/static/images/media-logos/best.png",
I tried different proxy setting like proxy_ssl_protocols and proxy_ssl_ciphers but no combination worked.
Any ideas?
I had the exactly same problem and spent a couple of hours...
I guess you are using older version of nginx (lower than 1.7)?
In nginx 1.7 you can use this directive:
proxy_ssl_server_name on;
This will force nginx to use SNI
Also, you should set the SSL protocols:
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
For earlier versions you may be able to use this patch (but I can't verify that that is working):
http://trac.nginx.org/nginx/ticket/229
2019 Update: You should avoid TLSv1 and TLSv1.1 and disable them if possible. I'll leave them in the answer as they are still valid for SNI.
Related
i use Library autocert in my application for generate ssl certificate, problem is 30% of users have problem with my application, my current code is :
fmt.Println("Starting server on " + this.Params.Bind)
if this.Params.SSL {
fmt.Println("SSL Enabled")
m := autocert.Manager{
Prompt: autocert.AcceptTOS,
HostPolicy: autocert.HostWhitelist(this.Params.HostsWhitelist...),
Cache: autocert.DirCache(this.Params.CertCache),
}
log.Fatal(autotls.RunWithManager(r, &m))
} else {
r.Run(this.Params.Bind)
}
the errors is :
2018/12/03 12:37:33 http: TLS handshake error from 68.71.48.249:55885: acme/autocert: missing server name
2018/12/03 12:37:33 http: TLS handshake error from 209.213.121.223:38284: acme/autocert: missing server name
2018/12/03 12:37:33 http: TLS handshake error from 209.213.121.223:38283: acme/autocert: missing server name
2018/12/03 12:37:33 http: TLS handshake error from 68.71.48.249:55887: acme/autocert: missing server name
2018/12/03 12:37:33 http: TLS handshake error from 68.71.48.249:55888: acme/autocert: missing server name
2018/12/03 12:37:33 http: TLS handshake error from 209.237.150.145:56842: acme/autocert: missing server name
how i can fix error missing server name ?
Maybe my blog will help you find a difference in your code vs the code I show in my blog.
https://marcofranssen.nl/build-a-go-webserver-on-http-2-using-letsencrypt/
Furthermore I figured out there is a much better library available to manage certificates via Letsencrypt.
https://marcofranssen.nl/use-the-acme-dns-challenge-to-get-a-tls-certificate/
In this second blog I utilize https://go-acme.github.io/lego/ which is supporting more of the ACME challenges. It ships with a cli, but can also be used as a lib in your webserver. In fact it is used in Traefik as well the Caddy webserver project.
You also should NOT use the SNI challenge anymore as it is considered insecure. Instead use the ALPN challenge.
I am trying to solve my white screen problem. Currently, I'm unable to login to one of my staging servers. I'm running Laravel 5.2 / php 7.1-fpm. After doing a repository update(via Forge), I hit the white screen view.
Based on my domain error log, I think that fixing the php7.1-fpm.sock failure will solve my white screen error.
I've tried just about every suggestion from various forums; I've tried suggestions from several similar related stack-overflow threads.
I still haven't found a solution. Can anyone offer suggestions?
Below is the error.log contents:
2018/08/12 21:16:09 [crit] 949#949: *28 SSL_do_handshake() failed
(SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported
protocol) while SSL handshaking, client: 23.27.154.95, server:
0.0.0.0:443
2018/08/13 00:43:46 [crit] 949#949: *47 SSL_do_handshake() failed (SSL: error:1417D102:SSL
routines:tls_process_client_hello:unsupported protocol) while SSL
handshaking, client: 220.181.132.198, server: 0.0.0.0:443
2018/08/13 00:43:46 [crit] 949#949: *48 SSL_do_handshake() failed (SSL:
error:1417D18C:SSL routines:tls_process_client_hello:version too low)
while SSL handshaking, client: 220.181.132.198, server: 0.0.0.0:443
2018/08/13 00:43:47 [crit] 949#949: *49 SSL_do_handshake() failed
(SSL: error:1417D102:SSL routines:tls_process_client_hello:unsupported
protocol) while SSL handshaking, client: 220.181.132.198, server:
0.0.0.0:443
Below is my site's error log contents:
2018/08/11 17:48:31 [crit] 934#934: *1 connect() to
unix:/var/run/php/php7.1-fpm.sock failed (2: No such file or
directory) while connecting to upstream, client: 73.106.222.129,
server: blabs.goteachersintouch.com, request: "GET / HTTP/2.0",
upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock:", host:
"blabs.goteachersintouch.com"
2018/08/11 17:48:35 [crit] 1266#1266: *1 connect() to unix:/var/run/php/php7.1-fpm.sock failed (2: No such file
or directory) while connecting to upstream, client: 73.106.222.129,
server: blabs.goteachersintouch.com, request: "GET /img/body-bg.png
HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock:",
host: "blabs.goteachersintouch.com", referrer:
"https://blabs.goteachersintouch.com/build/css/app-5aaeb8644f.css"
Before I did the Repository Uninstall with Laravel Forge, my build was working fine. Apparently setting my server to it's original PHP state is not in alignment with some configuration (there's something I'm missing, I just can't see it).
My codebase is still running on Laravel 5.2 library. But even still, can anyone offer suggestions to fix this white screen issue.
I have tried the permissions adjustments--that hasn't worked.
Thank you!
Turns out I was missing a bower file. The file was angular-sanitize#1.6.1
I ran:"bower install angular-sanitize#1.6.1" and was up and running again.
I've been setting up couchdb to run on SSL following the instructions from couch docs. Its pretty straight forward, you make 3 adjustments to local.ini:
httpsd = {chttpd, start_link, [https]}
cert_file = absolute/path/to/cert.pem
key_file = absolute/path/to/key.pem
I've made the key and certificate with openssl no problem, but whenever I ping port 6984 on the localhost (the port its supposed to run on by default) I just get a non active port:
==> curl https://127.0.0.1:6984/
curl: (7) Failed to connect to 127.0.0.1 port 6984: Connection refused
I've inspected the port, nothing is running there. I can put a node.js server on the port and it works fine too. I can't find a similar situation to this anywhere. I'm running the mac OSX couchdb application (v 2.1.2). It appears that the ssl server daemon is just straight up not running at all. Everything else in couch is working fine. Maybe I have to tweak the local.ini file to turn the daemon on? No idea really. Any suggestions are appreciated.
Not sure if this will ever be a very popular question but just thought I'd point out that a very popular way to set up SSL with couchdb is to use a proxy like haproxy due to annoyances with ssl and erlang (which couchdb is written in).
That being said, I solved my problem by setting up SSL termination at haproxy that then forwards traffic to couchdb on an internal port. For use on a mac OSX machine the steps were pretty easy.
1) Install haproxy with brew brew install haproxy
2) Create a self signed certificate with openssl that haproxy needs for ssl configuration (it's really just a concatenated file of your key and certificate):
openssl genrsa -out key.key 1024
openssl req -new -key key.key -out cert.csr
openssl x509 -req -days 365 -in cert.csr -signkey key.key -out certificate.crt
cat ./certificate.crt ./key.key | tee combined.pem
3) create haproxy configuration file (haproxy.cfg), this is just a pretty naive first implementation, but is a good starting point. Note that "/absolute/path/to/combined.pem" would be changed to wherever the combined.pem file is actually located.
global
maxconn 512
spread-checks 5
defaults
mode http
log global
monitor-uri /_haproxy_health_check
option log-health-checks
option httplog
balance roundrobin
option forwardfor
option redispatch
retries 4
option http-server-close
timeout client 150000
timeout server 3600000
timeout connect 500
stats enable
stats uri /_haproxy_stats
# stats auth admin:admin # Uncomment for basic auth
frontend http-in
# bind *:$HAPROXY_PORT
bind *:443 ssl crt /absolute/path/to/combined.pem no-tls-tickets ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-GCM-SHA384:AES128-SHA256:AES128-SHA:AES256-SHA256:AES256-SHA:!MD5:!aNULL:!DH:!RC4
#Add these lines beneath bind, still within http-in
reqadd X-Forwarded-Proto:\ https
# Distinguish between secure and insecure requests
acl secure dst_port eq 8000
# Mark all cookies as secure if sent over SSL
rsprep ^Set-Cookie:\ (.*) Set-Cookie:\ \1;\ Secure if secure
# Add the HSTS header with a 1 year max-age
rspadd Strict-Transport-Security:\ max-age=31536000 if secure
# Redirect HTTP to HTTPS
redirect scheme https code 301 if !{ ssl_fc }
default_backend couchdbs
backend couchdbs
option httpchk GET /_up
http-check disable-on-404
server couchdb1 127.0.0.1:5984 check inter 5s
4) Run couchdb, run haproxy via changing directory to the directory housing the above haproxy.cfg file and running with that configuration: haproxy -f haproxy.cfg.
This is a simple point to start from. This set up can handle load balancing of multiple couchdbs, and in production would need a valid certificate from some authority. For anyone interested in, or having difficulty with ssl and couchdb in a mac OSX development environment, this is a decent solution that I found to work quite nicely.
I've got a Ruby Gemserver running via Geminabox over http on port 9392.
It's behind an HAProxy load balancer which is enforcing https and doing SSL termination. Here's the relevant chunk(s) of my haproxy.cfg:
global
daemon
maxconn 256
user nobody
tune.ssl.default-dh-param 2048
defaults
mode http
timeout connect 5000ms
timeout client 50000ms
timeout server 50000ms
option httpclose
frontend http-in
bind *:80
reqadd X-Forwarded-Proto:\ http
redirect scheme https if !{ ssl_fc }
frontend www-https
reqadd X-Forwarded-Proto:\ https
bind *:443 ssl crt /usr/local/etc/haproxy/***********.pem
default_backend home_server
acl is_gems hdr(host) -i gems.example.com
use_backend gems if is_gems
backend gems
server gems1 192.168.100.102:9392 ssl verify none
When I try to add my gemserver from any other machine:
Error fetching https://gems.example.com:
SSL_connect returned=1 errno=0 state=error: certificate verify failed (https://gems.boynton.io/specs.4.8.gz)
What's interesting is this remains true whether the gemserver is running or not, leading me to believe my local ruby gem client is rejecting the cert out of the gate. (Otherwise I'd have stuck this question in ServerFault)
The cert is a Comodo PositiveSSL Wildcard cert, not a self-signed. I've confirmed the CA cert is in my local trust store (I'm on OS X El Cap, so it's been added to my keychain). It seems like maybe the gem command isn't using my system trust store.
I've googled around on this for two or three days to no avail -- everything I can find relates to rubygems.org and suggests gem update --system (I'm running the latest rubygems) or switching to http, both of which are rubygems.org-specific fixes.
How can I get gem to use my local trust store or take an additional cert?
Everything I try and connect to via https fails. Bellow is a curl output, but it does this with git mongo and everything. darwin just doesn't like https.
About to connect() to github.com port 443 (#0)
Trying 207.97.227.239... connected
Connected to github.com (207.97.227.239) port 443 (#0)
successfully set certificate verify locations:
CAfile: /usr/share/curl/curl-ca-bundle.crt
CApath: none
SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS alert, Server hello (2):
SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
You might say not a problem just change https to http, yes this is fine when you only have
1 url like git clone but on rvm install about 50 of the required things fails to install because of this. I don't want to go into rvm and change all occurrences of https to http.
Take a look at this post, slightly different, but i think it will answer you questions:
SSL certificate rejected trying to access GitHub over HTTPS behind firewall
You can essentially have OSX ignore the SSL Cert Verify, and accept the connection.
It turned out that my version of curl was using an old certificate to validate https.
I cam across this issue on git for cURL under Leopard:
https://github.com/mxcl/homebrew/issues/11947
And the error went away and I am now able to download https files from cURL.
This looks like an issue with curl itself, rather than OSX. What version are you using? If it's particularly old, then the reference here to a "severely outdated CA file" probably applies.
Try installing up-to-date versions of curl and git from macports.