Having a bit of a learning curve issue here. Trying to do a site migration.
We have and old website say website.co.uk that we are closing down.
We also have an existing website say website.com.
I have been able to map all the urls from the first website to the second one using mapping in nginx i.e.
/page-1 /new-page-1;
Then I have the follow server block.
`server {
server_name www.website.co.uk website.co.uk;
# Old website redirect
if ($redirect_uri) {
return 301 https://website.com$redirect_uri;
}
}`
This seems to work fine.
However trying to visit the top level domain www.website.co.uk I get a message that "Your connection is not private" and "This server could not prove that it is www.website.co.uk; its security certificate is from website.com. This may be caused by a misconfiguration or an attacker intercepting your connection".
All the redirects worked except visiting website.co.uk going to website.com.
Do I need another SSL cert?
Thanks!
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!
My domain is managed by Cloudflare, and I want example.com/he/whatevs to point to an IP where WP is hosted, eg 11.2222.12.12/whatevs
For that I have example.com pointing to a worker script that redirects /he to the aforementioned IP.
For this to work on WP end, I changed to DB record of the root URL to example.com/he, since this is the "user facing" URL.
The problem is, when I try to login to WP, there's a redirect mechanism in there that seems to be built-in to WP, and that causes an infinite redirect loop that eventually errors out.
Any ideas how to walk around that?
Or maybe my entire approach is off?
The problem was with cloudflare's default SSL setting, which is "flexible".
Once I changed it to "full strict" it started working.
So I know this seems like a question many people have asked before but I wasn't able to find an answer yet so I'll ask anyway.
I have a few websites set up on one IP address, which means I need to use SNI - one of said subdomains is mail.domain.tld, which works perfectly fine and another is cloud.domain.tld, which unfortunately doesn't.
cloud.domain.tld redirects to www.domain.tld when it is up.
manually typing 'cloud.domain.tld/login' works even when other websites are up but I haven't been able to make the subdomain append /login automatically, which is what I want to do.
when I change the name of cloud.domain.tld to mail.domain.tld, leaving the entire config the same, it works.
when I added clou.domain.tld and clouds.domain.tld to my DNS settings and set the website to those it works too.
So I changed the location / block from
rewrite ^ /index.php$uri; - as default in owncloud configuration
to
return 301 /index.php$uri;
and now this problem has been resolved, however logging out now returns a CSRF error.
I've got an asp.net website (let's say http://cdn.mysite.com) hosted on IIS and sat behind an Amazon CloudFront Distribution (using a CNAME to access the cdn.* url above, let's say the distribution URL is http://mysite.cloudfront.net).
If a user hits a folder/directory url without a trailing slash, the server will issue a redirect to the origin cdn url, so if a user navigates to http://mysite.cloudfront.net/thanks, they'll end up on http://cdn.mysite.com/thanks/ instead of http://mysite.cloudfront.net/thanks/
Any suggestions of how to fix this in asp.net / iis / cloudfront?
You're right - and rather than fighting it - have you configured CloudFront to whitelist host headers?
For each behaviour > Forward Headers > Select 'Whitelist' > Select 'Host' from the list and hit Add.
This setting ensures that the host header (mysite.cloudfront.net) is included in requests back to the origin (so make sure you've added mysite.cloudfront.net to your site bindings). I'd expect the redirect issued by IIS will use the correct domain name once this configuration is in place.
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.