I've been trying to communicate with my hosting provider for over a month now, but I'm 99% sure they don't even read the tickets and respond with randomly generated string of words.
I searched for weeks for the answer to this, and I see some mentions in regards to updating Java or modifying files that I don't have access to. Now, this is what happens for me. If I try to validate my domain name with W3C or try to validate a Twitter Card, I keep getting the SSL Handshake Error:
ERROR: Fetching the page failed because SSL handshake error.
I have a wildcard SSL from Comodo.
If I remove these lines from .htaccess W3C validates, but Twitter Card doesn't:
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_HOST} ^www.iadb.com$ [OR]
RewriteCond %{HTTP_HOST} ^iadb.com$
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Unfortunately if I change this, https is not enforced in any way, not to mention that it doesn't fix the Twitter issue. Again, since it's a shared host, I don't have access to any configuration other than .htaccess - I would appreciate any help or hints, even if it's just to tell me that I'm SOL.
Some tests with openssl s_client and packet captures reveal that your server returns a TLS alert unregognized_name with level warning if you access the host as iadb.com but that the TLS alert does not happen when using www.iadb.com as hostname. But since you redirect from https://www.iadb.com to http://iadb.com you end up with a connection containing this TLS alert.
Although the TLS alert level is warning only some implementations (openssl 0.9.8, Java) interpret it as error which causes the handshake to fail. This is what you see for example with the W3C validator:
IO Error: handshake alert: unrecognized_name
While this client software obviously behaves wrong it is also bad that the server sends this TLS alert at all. My guess is that this is caused because the server is only configured for the hostname www.iadb.com but not for iadb.com but you explicitly use the latter name. One way to work around the problem by yourself is to use only www.iadb.com. Another way is to fix the server configuration which according to your description only can be done by the hosting provider.
Related
I've been trying to setup client certificate authentication for almost three days now but to no avail.
I've signed up for a free domain at heliohost and have installed a free ssl certificate issued by Let's encrypt.
My plan is to have self signed certificates and check them against the database later(for user authentication) therefore I set my SSLVerifyClient to optional_no_ca in the htaccess file. I installed several self signed certificates generated by openssl but no matter which browser I try(Chrome, Firefox or IE) I get no prompts to choose a certificate except when i tried to access it on my phone via Chrome, in this case it offers to install a certificate since I don't have any on the phone.
This is the content of my .htaccess file:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
SSLOptions +StdEnvVars
SSLRequireSSL
SSLVerifyDepth 1
SSLVerifyClient optional_no_ca
I would really appreciate any feedback pertaining the issue, this is my first time trying to implement this and I'm not sure weather the issue is with my setup or chrome.
also I'm using chrome 59
Kriss
You have omitted the part of the ssl certificate authorities configuration. it is needed to configure the CA certificate that signs your client certificates ( see this
SSLCACertificateFile "conf/ssl.crt/ca.crt"
The server is not sending the root CA, then since you have set SSLVerifyClient to optional_no_ca, the browser automatically performs the connection because it can not find any suitable certificate (see below TLS1.2 note)
Since you have set optional_no_ca in your server, it accepts the connection even if no certificate is presented. It you set require you will find that the connection fails with Chrome.
SSLCACertificateFile is not configurable in .htaccess. Since you can not customize chrome, i am afraid you need to configure this parameter to force certificate prompt
When the certificate list is empty, the behavior between browsers may vary because the TLS specification allows it
See TLS1.2 RFC
7.4.4. Certificate Request
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
7.4.6. Client Certificate
[...]
If the client does not send any certificates, the
server MAY at its discretion either continue the handshake without
client authentication, or respond with a fatal handshake_failure
alert.
The issue was due to chrome, I have unfortunately not been able to pinpoint it but managed to get it working and prompting me for the certificate on firefox.
Thank you for the answers.
So I am an absolute beginner at Socket.IO, but I have a pre built application that needs to be secured in two ways: It needs to be transmitted over HTTPS and it needs to be restricted to only server data to a specific domain.
This is the code for the emitter thus far: https://github.com/Bitzz/Pokemon-Go-Coords/blob/master/discord-bot/index.js
How do I go about securing it?
I assume something along the lines of
io.set('origins', 'https://example.com:*');
on line 156 would restrict it to one domain...
Could I maybe blacklist only specific domains instead?
Beyond that, how do I make it emit over https via wss?
Currently the console shows:
I think I can figure out how to configure the web sided reader to look for the over https websocket, but getting it to send is not something I know how to figure out.
Please use simple words I am not a smart cookie. :(
To restrict Socket.IO to multiple domain, I believe you only need to separate each domain by one space.
io.set('origins', 'https://example.com:* https://anotherdomain.com:*');
About the SSL connection, there are several ways to archive that:
Config Socket.IO to use ssl (wss:// instead of ws://) in NodeJS, there is an answer here: node.js, socket.io with SSL
Create a reverse proxy with Nginx, there is a guide here: https://www.exratione.com/2013/06/websockets-over-ssl-with-nodejs-and-nginx/
Use reverse proxy from 3rd service like https://www.cloudflare.com
The third option is the easiest way to archive. You only need to point your domain CloudFlare and config an a record to your ws server, CloudFlare will provide ssl for websocket for free and automatically do SSL termination to your origin websocket server.
I found the solution.
In the apache2 site config file for the secure config (*:443), add the following:
#This enables polling over https. Painfully inefficient but a good fallback
SSLProxyEngine on
ProxyPass /socket.io http://127.0.0.1:49002/socket.io/
ProxyPassReverse /socket.io http://127.0.0.1:49002/socket.io/
#This upgrades and rewrites the ws to wss
RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://localhost:49002%{REQUEST_URI} [P]
Over the course of the last year a site I maintain with a payment gateway has stopped taking payments or collecting any user information. Seeing an opportunity to save a few bucks, we let the SSL certificate lapse.
The problem I am facing now is that Google and other sites have linked to the https version of my site. Whenever any of these links are visited you, rightly, get a security warning.
I added the following to my .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
But I'm still hitting the warning page every time I visit the site via an https link.
How can I get around this? In my head, for it to be failing the .htaccess file is being read after you visit the site, but Chrome is blocking the page before that stage – is that correct? If not, it may just be that I have a typo in my htaccess file.
Any kind of redirection is done after the TLS handshake, this means you get the warnings before the browser even gets the information that it should redirect.
And to anticipate a typical follow-up question: fiddling with DNS (i.e. CNAME etc) will not help either.
That means that you either accept the warnings about the broken certificate or you get a new certificate for your site.
I'm using the following in my .htaccess to force https on;
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R,L]
However this seems to cause SagePay to throw a 5003 error and a 500 http error.
The site has a valid SSL and was just installed yesterday and if I comment out these lines it works correctly with SagePay. MY callback pages are linked as https so SagePay redirects back to my site with https on so it's not as if SagePay is looking at the address and sees that it's being changed.
I don't have to force https, it won't be the end of the world, but I want to do so for the obvious benefits of https. Am I doing anything wrong, is there something I can do to fix this problem and keep forcing https?
After contacting SagePay support directly and looking at their logs for an example transaction I was able to see that our callback url (that was sent along with the post request to SagePay before the user even got to the SagePay payment portal) was manually set to be http rather than https.
This meant that when SagePay tried to post back to our website to see what to do next it was using an http url which would then have been redirected via our htaccess rules.
I can only assume SagePay's security considered this as tampering or something like that and considered that the transaction was not safe.
After manually changing our callback url to https, everything works as expected.
5003 Sage Pay Error Code
ERROR : Internal server error.
Explanation: If you receive this message, a code related error has occurred on the Sage Pay systems. This could have been caused by the information posted to the Sage Pay server or by an issue with the Sage Pay server.
Solution: Please reveiw the information your server is posting to the Sage Pay server. If you are using FORM integration, ensure the encryption password is correct and casing correct as this error can be returned if incorrect. If you are unable to identify the cause, can you provide the TxID so Sage Pay can view the transaction logs? Transaction logs are to be less than 72 hours old.
We have our site setup and would like to have a secure members area. (e.g.: https://www.abc.com/members/).
Our host provides us an SSL URL to use for free though it isn't very pretty (www1234.sslurl.com/abc/members/).
Is it possible to use https://www1234.sslurl.com/abc/members/ and rewrite the URL to read as https://www.abc.com/members? If so, I'd appreciate some help with the rule to do this.
Note: This is NOT for a shopping cart and we aren't storing credit cards, or social security numbers or anything sensitive like that. We just want to provide users with a secure browser connection when logging in. Is rewriting the URL unethical?
Added details since someone voted to close my question though I'm not sure why. This is a valid question and is tagged appropriately.
================== SOME CODE I'VE BEGUN WORKING WITH==================
RewriteCond %{HTTP_HOST} abc.com
RewriteCond %{REQUEST_URI} !abc/
RewriteRule ^(.*)$ abc/$1 [L]
Does this look right?
Even if there was a way to do this (and I don't believe that you Apache supports such a redirect), the browser would likely complain anyway. Typically SSL certificates only work for domain.com and www.domain.com. If you try to access that certificate using a different URL, your browser will give an error about the certificate not being trusted.