This may look like a duplicate, but I can't find anything else to try.
The Wildcard SSL (Only 1 month old) was installed fine and everything was going swimmingly until today I noticed it was redirecting to HTTP. Any attempts to remove HTTP bindings or force to HTTPS have only drawn a server not found.
This is happening for the stock domain and also the subdomains.
Nothing's changed. The server has been restarted during the period prior to the issue, the cert seems fine, it's also apparently fine in the server setup. I did not drag and drop the cert between stores. The Azure endpoint is in place. Firewall is good. Any ideas?
Related
I have 2 Windows 2012r2 Servers (Dev and Production) both running IIS 8. Both were configured identically as far I as know. I am in the process of installing wildcard certs on both of them.
I installed the cert on my Dev server and it's working. One thing that surprised me though was that I didn't have to add any additional bindings to any of my site configs (eg: I didn't add https/443) and just simply changing http to https in the browser is working, and showing the cert. Why is that?
My main question though is that on my Production server, before importing the wildcard cert, I tried simply changing the url for a couple of the domains I host from http to https in a browser to see what the result would be. When I do this I'm getting a redirect loop for all https tests. ???
I don't have any https URL Rewrites configured so I don't know what the cause of the redirect loop is. It does it for all sites on this server when trying to load it using https.
example:
http://mydomain.example.com (works)
https://mydomain.example.com (redirect loop)
Safari says, "...redirected you too many times. ERR_TOO_MANY_REDIRECTS"
Chrome says, "Too many redirects occurred..."
Additionally, if I load http://localhost on the server itself it works. If I load https://localhost I get an error, "Not Found - HTTP Error 404".
I should add that this Production server is behind an F5 Load Balancer so that could be playing into this behavior as well.
The cause of the redirect loop for all sites on the Production server was an irule on the F5 LB, that shouldn't have been there, that was looping port 443 back to itself. HTTPS for all sites worked after the irule was removed.
With regards to the Dev server and https sites working without having to add a binding. I also discovered that the F5 was configured to handle certs with a wildcard cert so local certs weren't even required. The data center team didn't communicate to me that the LB was configured to handle certs for these servers.
I have read a few answers to try and find a solution to a ridiculous problem.
I dont have access to a server that I can log on to access phpmyadmin,
What is supposed to happen is that the web url is supposed to be viewed via https, and in most cases this happens.
Except for a particular PC I have at home and it never seems to open in https. Why this is happening on this given machine is completely unknown.
Is there a way I can set up a rule on my local machine that will ALWAYS convert http://pathtomysite.com to https://pathtomysecuresite.com, (possibly via the 'hosts' entry (and yes it is a windows machine running win10).
I could do this on the web server itself, I know how to do this, but the problem is, I don't have, nor am I allowed to have, access to the database server to update the .htaccess or webconfig.xml on the server. (I am 99% sure its Apache, not nginx or IIS).
Any help is allows gratefully received.
Recently, I made a setup where I pointed some websites to a redirect server. The redirect server in return served the website requests using ProxyPass directive of Apache2. It worked like a charm without even a single problem for my websites.
So, based on that I have got an idea to access internet via Apache2. Please note that this is because I do not have access to fast internet and every internet provider is so lousy and lame here to provide better connection speeds even for the lot of money I pay to them.
Now, https as better speends than VPN.
So, the idea is to get rid of VPN and SSH tunnel redirects and instead, resolve every domain on my Mac to a single server IP address which should be a redirect server and which can in turn bring me back every web request made from my Mac. Possible? This will make me to always use https to my own redirect server. https has better speed than VPN for me whenever I try and when I am on VPN things are too slow for me, may be because of level of encryption. Please note that I do not want solution using PPTP, L2TP and anything else which are lighter than OpenVPN (using Pritunl).
Please let me know if anything like that is possible and if yes then how.
Even though if it does not work, my mind always gets this idea every time. I just want someone to shed light on this and shut down my idea if its the worst by far. Thanks in advance.
Also, I have also seen some proxy sites where I put any website link on their website and their website works like a browser as if I am surfing on their remote server itself. May be something like that can be useful and speedy for me. But, I do not want to use them because I do not trust those sites for security. No way.
Got a solution myself without any kind of VPN.
Actually I needed to make my DNS secure and connections to my server Apps secure. So, for that I tried DNSCrypt-Proxy and its working great and resolving my DNS queries on HTTPS (443).
And, I am using an Addon on Chrome for "Always https" connections. I am blocking every request on http for Chrome using that Addon. Perfect!!!
So, now all surfing traffic on my Mac is going on HTTPS and is perfectly safe from hackers. I do not care for any other connections made by my other Mac Apps. I just care for security of my Apps while I am surfing them OR any payments I am making for shopping.
DNSCrypt-Proxy:
Please go to https://dnscrypt.org/#dnscrypt-osx and you will find all help there to how to install and run it on your Mac.
brew install dnscrypt-proxy --with-plugins
sudo dnscrypt-proxy --ephemeral-keys --resolver-name=cisco
^ You can find the resolver name in excel sheet that comes with this package.
And, just add an entry in your Network interfaces for DNS to point to 127.0.0.1, Please note that remove all other entries.
"Always HTTPS for Chrome":
https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp?hl=en
Enjoy perfect security on your Mac, if you do not care about IP address anonymity. Always use legal stuff!!!
I've been using Azure to host my Web Apps for a while now and they've had my own wildcard cert attached to various ones with no problem. Recently, however, one of my clients has wanted a certain degree of uptime/performance (not that there have been any problems so far but they are willing to pay for it and who am I to turn down money) so I've set up mirrored sites and am using traffic manager to route between them.
It works like a charm but for one problem: I have a cname pointing a friendly url to the traffic manager address and, if I try to connect via https, it craps out and wants to use its own *.azurewebsites.com cert no matter what I try.
So my question is: am I missing something here? How to I use my own custom *.mycompany.com cert in this case?
Or, for that matter, is there a better way of doing what I'm ultimately trying to accomplish here?
Here is my set up:
Endpoint 1: MyWebApp-East (type - Azure Endpoint, ssl installed and proper host info added)
Endpoint 2: MyWebApp-West (type - Azure Endpoint, ssl installed and proper host info added)
Traffic Manager: Routing Type - Performance
UPDATE
Oddly enough, I got it to work. I must have had something wrong somewhere. I did a scorched earth approach to it by deleting EVERYTHING (sites, traffic manager, dns entries, etc) and starting over. It works perfectly now!
Posted this in the top part but so as not to leave this open, I'll repost the solution I found:
Oddly enough, I got it to work. I must have had something wrong somewhere. I did a scorched earth approach to it by deleting EVERYTHING (sites, traffic manager, dns entries, etc) and starting over. It works perfectly now.
Sometimes to go forwards, you have to destroy everything.
I've got a fairly simple app deployed on OpenShift that uses CloudFlare as a DNS provider, since they support CNAME records for the root domain, which our current domain provider does not.
The issue with this setup is somewhere along the line https is not working. I believe this is an OpenShift issue because it's the same kind of issue you get when you've mapped the domain name to your app but haven't added the proper aliases yet - you get a timeout essentially.
We've got two aliases - with www and without. There's no option to specify https or anything with OpenShift aliases from what I can see. There aren't any SSL certificates assigned to these aliases as we do not need or use https - we're on the Free plan.
The main URL to access the site is http://www.jcuri.com - notice this works as expected, however https://www.jcuri.com times out.
Initially we were thinking of using CloudFlare page rules to auto-redirect to a non-https URL however this is locked down behind a paywall which we're hoping to avoid, as we don't need any of the Pro features.
Is there something I'm missing here? It seems that OpenShift is just denying any https connections purely because we don't have certificates assigned to the aliases. I wouldn't even mind if there were certificate errors, at least that would give us a chance to do a redirect on the actual NodeJS application, but we don't even reach that point.
Can anyone offer some advice on this?
Since those domains are not pointed directly at openshift via CNAME, but are seemingly redirected via another service (from what i can tell from the dns) it is hard to say whether it is OpenShift that is causing the https issues. If you do not have a custom ssl certificate installed on openshift, you will just get an invalid certificate error, but since you are using a redirect service, maybe it is possible that the service is checking the certificate first, seeing an error, and then not working?
Since the https page rules you stated above are behind a paywall, this actually makes a lot of sense that they are blocking it, not OpenShift. Godaddy provided a forwarding service that would allow you to point both www and naked domain to openshift correctly using cnames, i have used it before.