One of the sites I manage started having a problem recently where if you try to access it via chrome (and apperently opera, and new edge) I get the ERR_SSL_PROTOCOL_ERROR error page. And unfortunantly there is not further information I have been able to find about what the underlying error actually is.
All of the suggestions elsewhere list things wrong on the client side except server clock skew - which existed but was fixed with no effect on the error.
running echo | openssl s_client -servername <site_url> -connect <site_url>:443 on mac gives a successful tlsv1.2 response.
running https https://<site_url> gives a successful HTTP response.
The site works in IE11, Firefox, Edge (old) as well as with openssl commandline.
The site is wordpress running on Ubuntu 14.04 (openssl version 1.0.1f) with PHP 5.6 and nginx 1.6.2
As I said above - I have already corrected the ~3 minute clock skew on the server that could cause ssl failure.
Any help is appreciated.
--Update--
I get the following protocol vulnuablities when checking on SSLLab
SSL labs protocol section
Related
I am running a VM on Ubuntu 18.04 an using a self signed ssl certificate (openssl). I installed the CA AUthority, uploaded it to Chrome. Chrome recognizes the SSL so I am not getting and error there, I do however get a guzzle error in Symfony. I have tried editing php.ini and inputing the cacert.pem there and nothing is working. this is not a duplicate please
I am reaching out to see if anybody has run into this based on the stack above.
Ever since Chrome and Safari started forcing HTTPS redirection on the .dev TLD I've been getting issues connecting to my Laravel Valet sites.
Without knowing that Chrome and Safari had done this, I updated Valet to from 1.2 and not thinking to check in Firefox first (doh! 😖). I've installed the latest stable release of Laravel Valet (2.0.6) on High Sierra (10.13.2), completely removed the running version of homebrew/php/php70 and reinstalled to be sure and have now changed the TLD to .test.
I can ping the domain without suffering any packet loss, however when I run
curl oldabp.test --verbose
I get
* Rebuilt URL to: oldabp.test/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connection failed
* connect to 127.0.0.1 port 80 failed: Connection refused
* Failed to connect to oldabp.test port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to oldabp.test port 80: Connection refused
I've also cleared the dns cache using the command found in this article, restarted valet and rebooted. I retested after each of these steps and the output remains the same.
I found a stack overflow answer for a similar question here that did the trick. During the valet install step I noticed it installed and started nginx and I don't remember it restarting nginx in the numerous times I've called valet restart before despite it telling me that it had restarted successfully. It boils down to very odd behaviour which has been resolved.
I'm trying to fetch the following URL via various libraries and command-line tools, but running into a SSL handshake error.
> curl https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
I've seen here it may be fixed by reducing possible ciphers, but trying this less strict call with restricted ciphers doesn't fix it.
curl -vlkL "https://www.joelosteen.com/Views/RSS/Feed?t=PodcastVideo&ct=CustomList&cst=Podcasts" --ciphers DHE-RSA-AES256-SHA
Any ideas how I can fix this? It's a shared account, ie no root available.
The server supports only TLS version 1.2, i.e. no TLS 1.0 or even SSL 3.0. My guess is that the curl you use is simply too old to use TLS 1.2, but without further details about the version you use this guess can not be verified.
To determine the version of curl use curl --version. If you see it is compiled with OpenSSL than it should show at least version 1.0.1 of OpenSSL to have TLS 1.2 support.
curl -vlkL ... --ciphers DHE-RSA-AES256-SHA
This is not a cipher supported by the server. One of the ciphers supported is AES128-SHA but again, no chance if your curl does not support TLS 1.2.
I am trying to use qtwebsockets but I've got problems with the ssl echoserver and client.
My project is developed in QT 5.3.2 MiniGW windows 8 64 bit, I can succesfully use the non ssl server sample but when i try to use the ssl one this is what I get :
1)Client completely black
2)Server prints three messages:
QIODevice::read: device not open
QIODevice::read device not open
SSL Echo Server listening on port 1234
I think it's a ssl problem but I am not 100% sure, I tried to install the openssl binary without
success, I hope somebody can help me.
cheers
Ok this is the problem:
The error is related to the fact that the sample looks for certificates inside the wrong directory in my system and if you want to make it running you need to go inside sslechoserver.cpp looking for localhost.cert and localhost.key and to let the system point at the correct location inside the sample directory.
I'm having trouble with setting up Sentry server in HTTPS mode. Every now and then, reasonably often while seemingly random, this error message gets written by Raven (Sentry client) into log files:
Unable to reach Sentry log server: <urlopen error [Errno 8] _ssl.c:504: EOF occurred in violation of protocol> (url: https://$(valid_server)/)
Web UI works fine. Vast majority of the messages from Raven are received fine and Sentry processes them into usable output. However, due to these errors, something gets lost from time to time.
I have tried to figure this one out, but dead ends seem to follow another. Basically it seems a lot like this:
Python Requests requests.exceptions.SSLError: [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
But when testing my Sentry server with similar s_client query using TLS 1.2, it leads to a valid session unlike with the example there.
It's also not about this, since SNI isn't used:
python-requests 2.0.0 - [Errno 8] _ssl.c:504: EOF occurred in violation of protocol
I'm not able to reproduce the error coherently. Raven's tests are passed and nothing is acutely wrong, until an error pops up in the log.
My set up is: Raven 4.2.1 in Python 2.7.5, Nginx 1.6.0 as reverse proxy handling HTTPS, and finally Sentry 6.4.4 with default Gunicorn 0.17.4. Nginx configs are pretty much similar to official documentation (http://sentry.readthedocs.org/en/latest/quickstart/nginx.html) with a few alterations due to HTTPS.
I ran into the same issue and got it fixed by installing the following dependencies:
On Ubuntu:
sudo aptitude install libffi-dev
And then via pip:
pip install pyopenssl ndg-httpsclient pyasn1
The problem seems to be that Python 2.X doesn't support SNI (which is needed for TLS) out of the box as explained here.