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.
Related
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.
I am using the Python requests module (requests (2.7.0)) and tracking URL requests.
Most of these URL's are supposed to trigger a 301 redirect however for some the domain changes as well. These URL's where the 301 is causing a domain name change i.e. x.y.com ends up as a.b.com I get a certificate verify failed. However I have checked and the cert on that site is valid and it is not a self signed cert.
For the others where the domain remains the same I do not get any errors so it does not seem to be linked to SSL directly else the others would fail as well.
Also what is interesting is that if I run the same script using curl instead of requests I do not get any errors.
I know I can suppress the request errors by setting verify=False but I am wondering why the failure occurs only when there is a domain name change.
Regards,
AB
This seems to work now. I believe the issue was linked to an old version of openssl. Once I upgraded even the 301 for a different domain goes through with no errors and that was with verify set to True.
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 just inherited a new site but messed up the SSL cert by losing the private key.
The url would have been https for anyone using the site meaning right now they are clicking on a broken site, or an SSL error to be more clear.
Is there any way around this for now, ideally just a redirect to a holding page would suit me fine.
I cant redirect to http using htaccess as I think htaccess doesnt even get a chance to kick in at that stage
Thank you
In short: What you want is not possible.
Details: HTTPS is HTTP inside a SSL tunnel. The redirect is done with HTTP. Since you messed up the establishment of the SSL tunnel it will not be able to start with HTTP (inside the non-existing tunnel) and thus cannot do a redirect.
I've got a website where on the majority of computers it works absolutely fine, redirecting users to the correct pages using the .htaccess file.
However, some computers seem to be ignoring the rules in the .htaccess file (maybe even the .htaccess file completely).
RewriteEngine On
RewriteBase /
RewriteRule ^procyon$ /procyon.php [L]
When a user visits http://www.blackroc-technology.com/procyon it redirects them to a product page. However, for some users they get a 404 error.
Someone in the same building as me (same internet connection) is suffering from this problem - I've tried both IE and Chrome and neither work so it doesn't appear to be a browser issue.
There's also a handful of customers on other internet connections to ours which have reported the problem.
Any thoughts on this? It's seems very odd to me and hard to debug!
If you can reproduce both cases, working and not working, then do an client side HTTP capture, e.g. using Fiddler.
You can then diff the successful/unsuccessful request to try to narrow down the issue e.g. if bad requests always fail and good requests always succeed, when re-requested from Fiddler, regardless of which network, computer they are issued, then it is likely a server side issue (.htaccess or httpd.conf setting sensitive to one of the request attributes).
At the very least you will have a better idea of exactly what is transpiring vs just the end result of a 404.
You can also similarly enable logging on the server side (ideally in a staging enviroment, not production) e.g
RewriteLogLevel 9
to get more details on why bad requests result in a 404