I have two websites running on the same IIS7 instance - let's call them oldname.com and newname.com (the newer one is simply a rebranded version of the old one). Both sites are SSL-enabled. The certificate for oldname.com has expired. I'm trying to set up an HTTP301 'moved permanently' redirect for requests to http://oldname.com to be redirected to https://www.newname.com. That works, but the issue is that visitors to https://oldname.com get the SSL 'certficate expired' warning generated before they reach https://www.newname.com. Is there any way to overcome this without renewing the certificate for oldname.com?
(Note: visitors to http://oldname.com are redirected to https://www.newname.com perfectly, as one would expect).
You could buy a inexpensive SSL Certificate for oldname.com or use a 90 day trial for free. Hopefully after 90 days the oldname.com will no-longer be indexed. You will still have a problem with people using bookmarks that are for oldname.com
Related
I am currently having issues with setting up an HTTPS domain redirect. I have a DNS URL redirect entry that points a few sub-domains to same-server URLs. For example:
docs.kipper-lang.org -> kipper-lang.org/docs/
play.kipper-lang.org -> kipper-lang.org/playground
The issue I am currently experiencing is that when using the subdomains, it mostly works, but it can only use HTTP. If I attempt to use HTTPS (like for example https://docs.kipper-lang.org) the redirect won't work and will get stuck apparently waiting for the HTTPS certificate (I think, but I don't know for sure, since it loads forever and gets a time-out).
So my DNS provider does its job for the most part as I want, but I am not sure how to add the HTTPS encryption to these redirects. Is there maybe even some DNS configuration or even middle-man service for redirects I can use, where these HTTPS encryptions are built-In? Since receiving a "Warning: Insecure connection" every time someone uses the sub-domains is a massive problem for me.
Note though that considering I am hosting on a GitHub Pages server, I am unable to do these redirects on the server side myself, as I can't use any code in this case.
I would greatly appreciate any ideas for fixing this or what I could use to achieve this another way.
Thanks in advance!
I just moved several interrelated sites from a server that does not support TLS 1.2 to one that does to specifically stop chrome's site is insecure message. There a 4 separate websites one of which has 2 pages Demo.aspx and Rater.aspx. All sites use https:// and the server supports TLS 1.2 and has a valid certificate chain. All sites load without any security warning, including Demo.aspx, but Rater.aspx does not (it is the only one).
Rater.aspx is a older and somewhat large one page asp site, so I figured there must be a http:// reference somewhere, and I found a few which I converted to https://.
I have gone over the site many time, and there is nothing I can see that should be causing the insecure flag.
Your Connection to this site is not secure.
Certificate (valid)
Cookies (1 in use)
Is there a tool that will tell me what chrome is picking up on so I can fix it?
If it would be helpful I can provide a link to the page, just did not want to do it here.
Thanks!
As #mason pointed out Chrome's Security Tab in developer tools provides information on what is causing the Not Secure message and ultimately led to the discovery of an unused iframe pointing to a less secure domain.
I found the offending domain name on the Application tab under Local and Session storage (no actual data was being stored). A project search for that name found the iframe.
Of note is that the insecure server was https:// and has a valid SSL certificate but it does not support TLS 1.2.
I have a website where I want to do transaction which has to be done over https, but the https works only without www (due to some issue while taking SSL certificate).
http:/ /www.example.com
https:/ /example. com
I want to set the cookies which are accessible in above of two.
Limitations:
1. https:/ /example. com can not made https:/ /www.example. com, due to SSL certificate is not available for www.example. com)
2. http:/ /www.example. com can not be made http:/ /example. com, because Google has indexed lots of pages with www, so if you remove now, you loose the SEO
Regards,
Prashant
for a cookie to be valid on all Subdomains, you use
.example.com (The dot at the beginning is important!)
I'm not sure about the SSL part though, you might get a warning if the non-secure cookie is being read on the secure domain.
Hope this helps,
Freddy
I have a bunch of programs written in ASP.NET 3.5 and 4. I can load them fine (I'm in England) and so can my England based colleagues. My American colleagues however are suffering redirect loops when trying to load any of the apps. I have tried myself using Hide My Ass and can consistently recreate this issue.
I'm stumped. What could be causing a redirect loop for users in a specific country?!
The apps are hosted on IIS 6 on a dedicated Windows Server 2003. I have restarted IIS with no luck.
Edit
I should have made it clear that unfortunately I do not have access to the machines in the US to run Firefox Firebug/Fiddler. The message I get in Chrome is This webpage has a redirect loop..
When you say "a redirect loop", do you mean a redirect as in an http redirect? Or do you mean you have a TCP/IP routing loop?
A TCP/IP loop can be positively identified by performing a ping from one of the affected client boxes. If you get a "TTL expired" or similar message then this is routing and unlikely to be application related.
If you really meant an http redirect, try running Fiddler, or even better, HttpWatch Pro and looking at both the request headers, and the corresponding responses. Even better - try comparing the request/response headers from non-US working client/servers to the failing US counterparts
you could take a look with Live HTTP Headers in firefox and see what it's trying to redirect to. it could possibly be trying to redirect to a url based on the visitor's lang/country, or perhaps the dns is not fully propagated...
if you want to post the url, i could give you the redirect trace
What could be causing a redirect loop
for users in a specific country?!
Globalization / localization related code
Geo-IP based actions
Using different base URLs in each country, and then redirecting from one to itself. For example, if you used uk.example.com in the UK, and us.example.com in the US, and had us.example.com redirect accidentally to itself for some reason.
Incorrect redirects on 404 Not Found errors.
Spurious meta redirect tags
Incorrect redirects based on authentication errors
Many other reasons
I have tried myself using Hide My Ass
and can consistently recreate this
issue.
I have restarted IIS with no luck.
I do not have access to the machines
in the US to run Firefox
Firebug/Fiddler.
The third statement above don't make sense in light of the other two. If you can restart IIS or access the sites with a proxy, then you can run Fiddler, since it's a client-side application. Looking at the generated HTML and corresponding HTTP headers will be the best way to diagnose your problem.
We are using IIS 6 and ASP.Net, When users make secure page requests using
https://somesite.com/securePage.aspx
the user gets an error:
Error code: ssl error bad cert domain
The certificate was issued to www.somesite.com and indicates that somesite.com uses an invalid security certificate.
I was hoping to be able to catch the request in the Application BeginRequest event but the SSL error occurs before this. In order to invoke the Application BeginRequest event the user needs to click through the certificate error message. Is it possible to redirect in code or does this fix need to occur within IIS?
The only solution is to include the second domain in the certificate with a SubjectAlternativeName. Some certificate authorities will allow you to do this without extra cost.
Everything else would only happen after the ssl connection is established and therefor after the error is encountered by the user.
With HTTPS the ssl connection is negotiated before any of the HTTP headers are sent to the server, including the Host:-header that tells the server for which virtual host the request is actually intended.
I was able to solve this problem using IIS's rewrite feature. Turned out to be really easy to fix and we didn't have to purchase a new cert.
HOP is correct with his answer. Owen also if we had the luxury of using IIS 7 as Rewrite rules similar to the mod_rewrite rule of Apache is now possible from within IIS. After further investigation today together with our Network Admins and our SSL Cert provider applying a SAN to our Certificate is quite possible and at no charge.However due to political issues within the ORG it was decided that DEV (my group) institute a redirect to the registered domain within the Application BeginRequest event. For each request we will check that the URL points to our FQDN. If the request is made to the 'Short Name' then we will point it to the FQDN always by appending the www to the short name that will be returned by the context.Host method.
No doubt this will increase chattiness etc.!
I did some testing on this on one of my servers and here is what I found.
We have a UCC certificate which will work for 5 domains. My 5 domains are
master mydomain.com
sub alt names:
mysite.com
myweb.com
thissite.com
www.thissite.com
The reason it is set up like that is because I didn't quite understand that it wanted www. when I made it.
So,
https://mydomain.com - works
https://www.mydomain.com - works
https://www.mysite.com - ERROR
https://mysite.com - works
https://thissite.com - works
https://www.thissite.com - works.
If you have a UCC cert (it seems you do) add a subject alternate name with the www on the domain in question. It will then work for both.
I went through all the steps of trying to redirect with .htaccess and server side scripting. But, hop is right, it will not do anything if you dont fix the cert.
You will likely have to drop a domain when you rekey your cert. Just remember which one you dropped and get a new cert for that one. I will forever and always REFUSE to buy UCC certs from now on. More problems than they are worth. 1 domain = 1 cert.
If your domain is making money then its worth the money, if your not making any money - do you really need the cert?
Intresting. I have never observed this behavior in any site until I saw this question. Even google has this problem. The url below gives the bad cert error
https://google.com/accounts/
Btw, Most of the sites has a subdomain to which they protect it with a certificate. One vote up for the question.
In Apache this is usually done with mod_rewrite:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]
Google for "rewrite URL IIS", you'll find some equivalents for IIS.