I'm using Centos 7 with Plesk (1and1 dedicated server) and Apache and we want to secure all our website with let's encrypt where possible, though we have a problem with 2 domain that has been rewritten with Apache rules.
here the code we use to rewrite the domain:
ServerAlias www.traffweb.portsmouth.gov.uk traffweb.portsmouth.gov.uk
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(w{3}\.)?portsmouthtraffweb\.uk [NC]
RewriteRule (.*) http://www.traffweb.portsmouth.gov.uk/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]
and then
/usr/local/psa/admin/sbin/httpdmng --reconfigure-domain portsmouthtraffweb.uk
not really sure if the last command is necessary, I think that the last time I just insert the apache rules and that's it.
In our server we have (and we own) portsmouthtraffweb.uk while traffweb.portsmouth.gov.uk it's own by the client, this subdomain doesn't exist anywhere, it's been redirect on the DNS with an A Record to point to our server IP.
Basically in the server exist portsmouthtraffweb.uk and if enter traffic requests for traffweb.portsmouth.gov.uk it redirect to use the directory of portsmouthtraffweb.uk
I tried to use Let's encrypt in Plesk but when I applied the certificate the rewritten rule is being ignore and the URL displayed is the one on the server not the one we want to display.
How can I secure those domains? A part from me that I use both domain to see the website, everyone else will use just the correct URL traffweb.portsmouth.gov.uk as it will be publicise with this DOMAIN NAME.
I don't mind to do some code on the server as we own the servers so I can connect as a root and as you can see this command was done on the server and not through Plesk, sometimes I just prefer do thing in Plesk because it require less time.
Hey #Sebastiano :wave:
You actually cannot get a cert for a domain you don't control legitimately. I think this might be the problem.
Are you sure they are using an A record (points to IP address) and not a AAAA record or most likely CNAME record or other redirect mechanism?
It would be the .gov.uk administrator job to get a cert for their side if they control the domain. You can use services like https://www.whatsmydns.net/ (google for "check DNS propagation" if that link is dead) to verify that it indeed points to your domain, or server IPs.
If it's a CNAME, then from your side it should just be porsmouthtraffweb.uk so you'd need to ensure that firstly resolves directly to the server you want an SSL for. You'd then also need a separate vhost with the same webroot. https://certbot.eff.org/all-instructions provides an exhaustive list. I use the webroot option for smaller sites, but I've been assured you can even use DNS to secure SSL certificates (so long as you control the DNS).
Here is one for my local linux club which was running Apache 2.2 (since upgraded to Nginx) https://gist.github.com/Lewiscowles1986/dda7382e21a7ec66089730f7945842f0
Certificates should be stored outside of the webroot. Letsencrypt ones live under /etc/letsencrypt. You may also want to generate a dhparams.pem
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096
Once that server resolves and knows portsmouthtraffweb.uk resolves to your servers, you can request a LetsEncrypt cert for that domain only. Similarly if the .gov.uk one resolves to your servers, you can request a certificate for that domain only.
I use the certbot utility, but you may find commercial providers are better suited to secure a government website.
It's Lewis Btw
Related
I'm trying to set up Cloudfront->Application Elastic Load Balancer->Auto Scaling->EC2 AWS stack.
Everything works until it scales to more than 1 EC2 instance, which then causes a redirect loop with the error message "Too many redirects".
Here are the related settings:
I've enabled an ACM SSL certificate and attached it to the CloudFront distribution.
DNS pointed to CloudFront domain name.
Cloudfront 'Origin Protocol Policy' = HTTP Only
ELB Listener 1 = HTTP:80 redirects to HTTPS:443
ELB Listener 2 = HTTPS:443 forwards to the target group of 2 EC2 instances
.htaccess
RewriteEngine On
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
RedirectMatch 302 ^/$ /app.php/
Please help me solve this redirect loop and explain why the current settings are not working.
Any time you spend on this is highly appreciated.
You appear to be using both mod_rewrite and RedirectMatch to perform two different redirects:
This appears to redirect any request starting with app.php to the base website URL:
RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]
This appears to be redirecting any request to / coming in to /app.php/:
RedirectMatch 302 ^/$ /app.php/
These rules seem to be in direct conflict with one another. If you try to request either the root website path /, or /app.php you are going to get into a redirect loop.
This condition tells Apache to track redirects internally in order to prevent a redirect loop:
RewriteCond %{ENV:REDIRECT_STATUS} ^$
However that only works as long as you have one server. When you have multiple load-balanced servers they can't track if a redirect has been issued by another server in the pool.
I suggest taking a look at these redirect rules and only using one of them depending on what your specific needs are.
I was able to resolve this, temporarily, with Mark B's answer.
"You didn't include any info about logging in and user sessions in your question. For the short term, I would enable sticky sessions on the load balancer. Long term I would look into a distributed session store." – Mark B
I have a website www.example.com and it is hosted on elastic-beanstalk. I am using the name.com DNS servers. I have followed the steps in the following blogs to set up https and URL settings:
https://colintoh.com/blog/map-custom-domain-to-elastic-beanstalk-application
https://medium.com/#jbesw/tutorial-adding-https-to-a-custom-domain-on-elastic-beanstalk-29a5617b8842
i.e
Create a CNAME pointing www.example.com to the beanstalk
Add a URL redirect for #.example.com to https://www.example.com
After this, the links www.example.com works, and http://example.com gets redirected to www.example.com.
But for a page inside the site, like www.example.com/about, just typing in http://example.com/about does not work and does not get redirected to www.example.com/about.
Most blogs suggest moving to AWS Route 53. Is that the only option?
The issue, as you've found out, is that DNS-level redirects don't work on a page-specific level. At least, not without some extra magic happening in the background (which some registrars implement.)
Even if that setup did work, you'd still have some SEO issues to deal with. For example, you want the example.com > www.example.com redirect to (In any case I know of) to be a 301 redirect. This let's search engines like Google know "Use only the www version of this page please." Otherwise, you effectively have two pages floating around out there either of which (or both) could be indexed and considered duplicate content of one another.
Using the Route 53 servers is certainly an option but no one you have to use. The issue is that you need to do this on a server-level—not a DNS level.
On a server level, you can specify more complex and granular redirection rules such as "send any non-www, non-https traffic to the www, https version of the page and indicate this is a permanent preference (301)` that redirect (on an Apache server) would look like this:
RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.{HTTP_HOST}%{REQUEST_URI} [R=301,L,NE]
Quick Reference: NC means case-insensitive matching. R specifies the type of redirect (301 here), NE specifies to not escape characters like # or ? which are used in many URL schemes. For a full list of flags used during Apache RewriteRules, read this webpage.
There are different ways to achieve this for Apache, NGINX, and Windows Server. Amazon has a reference article detailing some of the implementation approaches for this. Copying the details of the article here is beyond the scope of your question IMO.
So, to answer your question: Route 53 isn't your only option. You can absolutely use whatever registrar or DNS host you'd like. The issue is that you need to re-think your approach entirely and focus on server-level rules rather than DNS-level rules. I'm no expert and find it annoying to do it this way, so hopefully, someone will jump in with a more insightful approach.
I want to restrict my domain so that no one can do CNAME of my domain.
Suppose, I have my domain(example.com) and someone has another domain(xyz.com).
There is a game application running on example.com.
Nothing is running on xyz.com.
Someone has done CNAME of his domain(xyz.com) to my domain(example.com).Now the xyz.com is pointing to my game application.
How I can restrict people using my domain and I want to restrict it on
a) DNS level
b) Server level
Please help me to sort it out?
Everyone will always be able to create CNAME pointing to your domain. That's something you can't prevent.
On the server level you can check (in .htaccess for example in Apache) which domain is requested and if it does not match yours, redirect the request somewhere else:
RewriteEngine on
RewriteCond %{HTTP_HOST} !example.com$
RewriteRule . http://redirect.page.com [R=301,L]
In Nginx:
if ($host != 'example.com') {
rewrite . http://redirect.page.com permanent;
}
You should also configure CORS so assets like scripts, stylesheets and images load for your domain only.
I was having a really bad time trying to get our drupal site to run in full https behind an AWS load balancer using Apache and mod_rewrite. The ELB is acting as the SSL certificate provider. All traffic to the ELB should be encrypted, then the traffic to the EC2 instances is normal HTTP (pretty standard).
I attempted all sorts of .htaccess and Apache conf.d/*.conf mod_rewrite conditions and rules. When I was able to it to redirect traffic to https, it would break the ELB's health checks, bringing my "unhealthy" EC2 instance out of the pool. If I tried to fix it so the ELB health checks would pass, I'd get an infinite redirect problem.
After a week or so of working on this on and off, I finally found a solution. If you're having the same issue, please look here! It might not work 100% for you, but at least I may be able to shed some light on how to go about fixing it.
Well here's my answer for a site that I want ALL traffic directed to https://example.com. (If you want https://www.example.com, you can make a few tweaks)
First off, Drupal's settings.php file at /sites/default/settings.php:
I have the following in this file:
$base_url = '//example.com';
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('name-of-my-loadbalancer.us-west-2.elb.amazonaws.com');
$conf['reverse_proxy_header'] = 'HTTP_X_CLUSTER_CLIENT_IP';
To be honest, I don't know if the above "reverse_proxy" settings are actually necessary. In fact, I have disabled them and it doesn't seem to affect anything so it might not be. The important part is to make sure you have the $base_url = '//example.com'; in your settings.php file.
The next part is configuring your .htaccess file. Here are the bits that are important:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !=/healthy.html
RewriteRule ^ https://example\.com%{REQUEST_URI} [L,R=301]
For a noob like me, this was tough to figure out at first but here's the breakdown:
RewriteCond %{HTTP:X-Forwarded-Proto} !https This looks at the
protocol being sent by the load balancer. If the protocol is NOT
https, initiate the RewriteRule.
RewriteCond %{HTTPS} off If traffic is headed to the site that is not HTTPS, initiate the RewriteRule
RewriteCond %{REQUEST_URI} !=/healthy.html this is an important bit. I have a simple healthy.html file that contains the word "Success!" within my main drupal webroot directory for Apache. When the healthy.html file is accessed by the ELB, it will bypass our rewrite rule. If it didn't the ELB health check would fail, taking our server(s) offline.
RewriteRule ^ https://example\.com%{REQUEST_URI} [L,R=301] Here is the actual rewrite rule. If all of the above conditions pass then this will rewrite the incoming URL to https://example.com/whatever. By the way, the L stands for "Last," as in "this is the last rule of this set" and the "R=301" stands for "301 Redirect."
The only time this doesn't do a proper redirect is if I manually type in https://www.example.com (with the https at the beginning). I think I can fix that with another simple RewriteCond.
In case anyone like me land over here with Drupal 9 and hosted within AKS cluster, if you are using ingress add following annotation in ingress.
appgw.ingress.kubernetes.io/backend-hostname: "example.com"
after adding this line at ingress and applying it to AKS
echo $_SERVER['HTTP_HOST'];
will print
example.com
as your new host, that should solve Drupal base_url issue.
I'm having trouble with a 301 redirect. I've tried a few but they are not working as I need it.
I have an old website that no longer exists, I would like to forward the entire domain to a landing page on my new website.
So when someone types in www.olddomain.com I want them to go to www.newdomain.com/landingpage.php
The problem is that I want ALL requests on the old domain to go to that landing page. Currently I have the domain forwarded thru GoDaddy, and when someone (or Google) types in www.olddomain.com/whateverpage.htm or forwards it to www.newdomain.com/landingpage.php/whateverpage.htm
This is causing issues with Google indexing.
So I need a redirect that will send ALL requests of ANY page at www.olddomain.com/ to www.newdomain.com/landingpage.php
What should I use?
You can use this rule on DocumentRoot of old site:
RewriteEngine On
RewriteRule ^ http://newdomain.com/landingpage.php? [R=301,L]
Assuming you're using a LAMP stack (linux server, MySQL, PHP) you can use rewrite rules in an .htaccess file to capture all requests to www.newdomain.com/landingpage.php* and redirect them back to landingpage.php. If you're hosting on a Windows server, you can do these sort of redirect rules with the URL Rewrite module in IIS (which can import .htaccess rules).