Only some (not all) users are receiving ERR_SSL_PROTOCOL_ERROR in Chrome when attempting to visit my express site. I am not receiving this error, so it is proving a pain to debug.
I am creating a https server using a PFX file I downloaded from my provider (1&1):
var options = {
pfx: fs.readFileSync('./mysite_private_key.pfx'),
passphrase: 'MYPASSPHRASE',
};
https.createServer(options, app).listen(443);
https://whatsmychaincert.com tells me that the chain is correct but complains about the handshake:
[mysite] has the correct chain.
[mysite]: TLS handshake error:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error SSL Labs might be able to tell you what went wrong
I've googled this with no success, does anyone know what the problem could be? Ty.
In the end I ditched 1&1 and used GoDaddy's CA service and the problem went away.
A possible source of failed handshake could be the lack of an intermediate certificate, ca option of tls.createSecureContext. It should by public on your provider's website.
Hope this helps.
nowadays , when our server (e.g. 1&1) is securely configured , only tls v1.2 and tls v1.3 are supported ..
so how you debug this:
scan your site with SSL Labs Test too see which ciphers are supported , or alternately see in our nginx/apache config
tail -f the server logs , especially the catchall/other_vhosts log files,since ssl protocol errors might be in the site logs and the generic catchall log when the server cannot decide on the name
try to update the users chrome to support at least tls 1.2
chrome has the some command line switches to change its cipher behaviour:
--ssl-version-max Specifies the maximum SSL/TLS version ("tls1.2" or "tls1.3"). ↪
--ssl-version-min Specifies the minimum SSL/TLS version ("tls1", "tls1.1", "tls1.2", or "tls1.3"). ↪
DANGER ZONE:
as last resort you could try to accept legacy ciphers in your nginx-config ( ssl_ciphers directive) like socat OR (very last resort) socat23 to check which version your clients support,
remember to disable everything below tls v1.2 in production environment
Related
I would like to get the recommendation on how to configure Squid (latest version) with client SSL termination.
The requirement is to provide proxy access to the internet for the client who has no ability to install a custom CA certificate.
Following the documentation here, it is possible to use HTTPS for the browser-proxy connection the same way as HTTP.
However, the only way to achieve that is to use SSL Interception with self-signed CA certificate, which cannot work in my case.
Can someone please advise?
If I understand you correctly you want to replace the client-to-server encryption offered by HTTPS with client-to-proxy-encryption followed by proxy-to-server encryption without a client needing to trust the proxy. If this would work it would make HTTPS fundamentally insecure since every man-in-the-middle attacker could just do this. So fortunately it will not work.
I have a server with public IP and hold a website on it. I don't have a domain and my web server is IIS, then I created a self signed certificate in the server and bind it to my website. When I want to access to my website using a link like http://.../test. I can access to the website with https in localhost in the server. but I can't access to the website from a client browser with httpsand I get this error in client browser:ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Your server most likely doesn't support TLS (v1.0 or higher) but only SSLv3. That's a common cause for this error. SSLv3 is blocked in most browsers because of the POODLE vulnerability (CVE-2014-3566). You should review your server settings and upgrade them accordingly.
You can test your website at the awesome SSL Test from SSL Labs. This will point out errors like these and it helps you create a secure config. Please keep in mind that any score below A is in urgent need of improvement.
I found out to solve it. Port 443 was closed in the server.
We have a web server (IBM HTTP Server 6.1) connected using HTTPS (using SSL certificates - SSLv3) to an application server (IBM WebSphere Application Server 6.1), the application that is hosted on the app server is not upgradable, so we cannot update WebSphere on both layers to later versions.
I'm trying to enable TLS instead of SSLv3, the steps I followed:
On the web server's http.conf file, SSLv2 and SSLv3 and their cipher suites directives were removed, and TLS cipher suites were added (2F, 35b).
On the app server, QoP were changed to TLS (also tried TLSv1) instead of SSL_TLS, removed RC4 cipher suites by creating a customer list.
When opening the website URL from browser, Internal Server Error appears (means that the web is unable to communicate with the app server). When selecting the SSL_TLS again in the app server's QoP settings (keeping the SSLv2 and 3 disabled on the web server level), the website opens properly!
Is it possible the application is not compatible with TLS, pls advise?
Thank you.
The WAS Plugin tries TLS1.0 by default in 6.1.0.31 and later. To debug whatever's going on with your system, you'll have to actually watch the handshake in a packet capture and that will tell you which side to focus on.
Running 6.1 is ill advised, but running 6.1 without the latest maintenance is borderline negligent.
I am using the following web2py slice in attempt to use https for a service worker function in a page.
http://www.web2pyslices.com/slice/show/1507/generate-ssl-self-signed-certificate-and-key-enable-https-encryption-in-web2py
I have tried opening web2py with the following line (with and without [-i IP and -p PORT]):
python web2py.py -c myPath/ssl_certificate.crt -k myPath/ssl_self_signed.key -i 127.0.0.1 -p 8000
but https is declared 'not private' and is crossed out. Because of this, I am getting a SSL certificate error when the registration of the service worker is attempted.
Please indicate what is going wrong or whether more information is needed
You mention "https is declared 'not private' and is crossed out". This has to do with browsers disliking not trusted (self-signed) certificates, because that's what trust is all about. If any hacker could just make up a certificate and the https client wouldn't respond with at least a frown, you could still be hacked or sniffed without noticing. Since you don't mention any other error, I assume you get otherwise valid results from the web2py server?
If so, you have setup your self-signed certificate well. If you don't get any valid html response (outside your browsers complaint, of course), you still have an issue with the setup.
If your service worker won't accept the certificate, what you can do (in a test environment at least) is import the self-signed certificate into the machine or service worker certificate repository. The process differs per OS and version.
Hope this helps. If it doesn't, please provide more detail.
The best way to use ssl with web2py is use of the deployment recipes with prodution-grade webservers like apache, nginx or Lighttpd.
Any of the mentioned scripts create a self-signed certificate, and then, you have to fix the generated server config files to a real certificate.
You can buy a real ssl certificate from any of many resellers or get for free from Let's Encript, if you have a real IP, like in a VPS or server.
A simple way to fix the config files is create a simbolic link from the real certificate to the one mentioned in the server config file.
To just test your service worker in your machine or a internal test server, just use a non-ssl port, or like Remco sugested, import the self-signed certificate to client environment.
I have an IBM HTTP Server and Server [X] ,
I need to create secure connection [SSL] :
by creating KDB file : ibmhttpserverkey.kdb in IBM HTTP Server using iKeyman utility and importing Server[X]'s certificates [cert.PEM] or [cert.der] in ibmhttpserverkey.kdb
it's do-able or not?
I have tried a lot and every time it returns "Error Handshake, no certificate found" even if i installed it using certification manager!
You should be able to import certificates from other key file types such as a p12 database or another kdb. After doing the import check the personal certificates using IKEYMAN to see if the certificate is there. If you then see the "Error Handshake, no certificate found" in the IHS error log it may be you have not specified the certificate to be the default. Also check the VirtualHost entry for port 443 (or whatever ssl port is used) and see if an SSLServerCert directive is defined. This directive can be used to point at a label that identifies the needed certificate. The no certificate found message means that IHS opened the kdb defined by the keyfile directive and could not find either a default certificate or one that is specified using the SSLServerCert directive.
Guide to setting up SSL within IHS:
http://www-01.ibm.com/support/docview.wss?uid=swg21179559