How to redirect to HTTPS when Hunchentoot is behind a reverse proxy - http-headers

I have a Hunchentoot application running on http://localhost:4242. This application uses a non-SSL acceptor (i.e. hunchentoot:easy-acceptor instead of hunchentoot:easy-ssl-acceptor). I set up Nginx as a reverse proxy to serve this application using SSL. This is the Nginx configuration:
server {
listen 443 ssl;
server_name example.test;
ssl_certificate /etc/my-ssl/certs/example.pem;
ssl_certificate_key /etc/my-ssl/private/example.key;
location / {
include /etc/nginx/proxy_params;
proxy_pass http://localhost:4242;
}
}
where /etc/nginx/proxy_params is
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
The problem is that Hunchentoot does not know that the reverse proxy (i.e. Nginx) is actually serving the client using HTTPS. As a result, (hunchentoot:redirect "/some-page/") will redirect to http://example.test/some-page/ instead of https://example.test/some-page/. Hunchentoot does not take into account the X-Forwarded-Proto header.
To solve this problem, I have written an alternative redirect function which I use instead of #'hunchentoot:redirect:
(defun my-redirect (target
&rest args
&key (protocol
(if (string= (hunchentoot:header-in* :x-forwarded-proto)
"https")
:https
:http))
&allow-other-keys)
(apply #'hunchentoot:redirect target :protocol protocol args))
Is this a correct method of solving the problem? Are there better ways?
(Hunchentoot 1.3.0; SBCL 2.2.2; Nginx 1.18.0; Ubuntu 20.04)
EDIT:
In Hunchentoot's issue tracker: Incorrect redirection to HTTP when application is served using HTTPS reverse proxy

An option is to subclass hunchentoot:easy-acceptor and specialize the acceptor-ssl-p method for your acceptor. This would enable you to call hunchentoot:redirect and have the protocol decision happen behind the scenes.
(defclass my-easy-acceptor (hunchentoot:easy-acceptor)
())
(defmethod hunchentoot:acceptor-ssl-p ((acceptor my-easy-acceptor))
(string= (hunchentoot:header-in* :x-forwarded-proto) "https"))
However, it seems to me (from the nginx configuration) that you are always serving HTTPS - so you could omit the logic and always return t.

Related

HTTP/HTTPS redirect problem with nginx and bitnamis dockerized osclass

I'm having a problem with a nginx configuration which I use as a reverse proxy for different containerized applications.
Basically Nginx is listening on port 80 and is redirecting every request to https. On different subdomains I'll then proxy pass to the port of the applications.
For example my gitlab config:
server {
listen 443 ssl; # managed by Certbot
server_name gitlab.foo.de www.gitlab.foo.de;
location /{
proxy_pass http://localhost:1080;
}
I'm redirecting to the gitlab http (not https) port. The systems nginx is taking care of SSL, I don't care if the traffic behind is encrypted or not.
This has been working for every app since yesterday.
I'd like to test https://github.com/bitnami/bitnami-docker-osclass for an honorary association. Same config as above but it is not working as intended.
Ressources are downloaded via https while the main page is getting a redirect to http.
Exmaple: https://osclass.foo.de --> redirect --> http://osclass.foo.de:1234/ (yes with the port in the domain which is very strange)
I don't get why? So I changed the config a little to:
server {
listen 443 ssl; # managed by Certbot
server_name osclass.foo.de www.osclass.foo.de;
location /{
proxy_pass http://localhost:1234;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Now the mainpage is loaded via https and I don't have the port in my domain anymore. But the whole page is broken because no ressources will be loaded due to
"mixed-content warning".
SEC7111: [Mixed-Content] Origin "https://osclass.foo.de" [...] "http://osclass.foo.de/oc-includes/osclass/assets/js/fineuploader/fineuploader.css"
Do I have a conflict with the integrated apache in the docker image or what am I doing wrong?
Any hints are appretiated!
Kind regards from Berlin!
I found a solution to fix the mixed content problem. I just edited the following line in
/opt/bitnami/osclass/config.php
# define('WEB_PATH', 'http://osclass.foo.de/');
define('WEB_PATH', 'https://osclass.foo.de/'); # with https

GoLang HTTPS API

I have a server in windows using Plesk.
I have a domain (example.com), also I bought a SSL certificate for this domain.
I just installed successfully and configure the domain and ssl in my server. So now I can join to my web using https://www.example.com or example.com and will be redirect to https://....
Until that everything works fine.
But now I have been developed an API in GoLang which can’t start to listen at 443 port for some reason. (I thought that maybe because is being already used ?) So I changed to 8081 port. Now when I want to make a request to my API I have to use https://www.example.com:8081/api/v1/users for example.
The problem is that some applications show me a error “Certificate invalid” which I think is because the port is not 443. Is there any way that I can run go in 443?
The code in GO is this: (The crt and key are the ones provided by GoDaddy, is where I bought the SSL)
func main() {
router := NewRouter()
handler := cors.AllowAll().Handler(router)
log.Fatal(http.ListenAndServeTLS(":8081", "tls.crt", "tls.key", handler))
}
Run the whole Golang application behind nginx (reverse proxy):
Create a Virtual Host Server Block in Nginx using your domain.
https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04
Setup your SSL certs
Point that domain to your Golang App
server {
server_name example.com;
location / {
proxy_pass http://localhost:8081;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
proxy_pass_request_headers on;
proxy_read_timeout 150;
}
ssl_certificate /path/to/chainfile/example.com/abcd.pem;
ssl_certificate_key /path/to/privatekeyfile/example.com/abcd.pem;
if ($scheme != "https") {
return 301 https://$host$request_uri;
}
}

If I'm using a reverse proxy on Nginx do I need an SSL certificate for the reverse proxy and the server?

so I'm starting to learn about nginx and reverse proxy's and I have a question about SSL, the thing is that I have a reverse proxy server like this:
upstream vnoApp {
server vyno.mx:81;
}
server {
listen 80;
server_name app.vno.mx;
location / {
proxy_pass http://vnoApp/;
proxy_set_header X-Real-IP $remote_addr; # http://wiki.nginx.org/HttpProxyModule
proxy_set_header Host $host; # pass the host header - http://wiki.nginx.org/HttpProxyModule#proxy_pass
proxy_http_version 1.1; # recommended with keepalive connections - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}
}
what this is doing as you might expect is to listen to http://app.vno.mx and it 'reverse proxys'' it to http://vyno.mx:81, and everything works just fine, but now I want to add SSL support for the site and my question is if I have to add an SSL certificate to both vyno.mx and app.vno.mx (wildcard *vno.mx), or if I just add it to app.vno.mx it will work fine, thanks to all in advance!
No problem, you just need a certificate for the user-facing host.
As a side note, unless circumstances justify, it is generally ill-advised to forward anything to a publicly available port and host.
So that - unless there is a reason not to do so - you should firewall port 81 on vyno.mx to accept connections only from the app.vno.mx server.
If they are the same server, that's it, or perhaps using 127.0.0.1 is even better.
If they are distant, however, you might wish to encrypt the internal connection as well, you can just do that with a snakeoil (self-signed) certificate.

How do I force Ghost's admin page to be server over SSL when ghost is installed in a subdirectory?

I am using Ghost as a blogging platform and nginx as a reverse proxy for ghost as detailed in the documentation. Ghost is installed in a subdirectory and is served over the domain http://example.com/blog whereas the static website is served over example.com
I have set up SSL on my server and want to serve the ghost login page (example.com/blog/ghost) over SSL while serving the rest of the pages over normal HTTP. However if I use forceAdminSSL:true and try to go to http://example.com/blog/ghost it should automatically redirect me to https://example.com/blog/ghost. Instead I'm redirected to https://example.com/ghost and end up with 404 error. The only work around I have found that works is to use foreAdminSSL:{redirect:false} which is clumsy because then I have to manually type https in the address bar instead of http.
How do I server Ghost Admin panel over ssl while ghost is installed in a subdirectory? I guess this has something to do with configuration in nginx.
My nginx config block
server {
listen 80;
listen 443 ;
server_name *.example.com;
server_name example.com;
ssl on;
ssl_certificate /etc/nginx/ssl/certificate.crt;
ssl_certificate_key /etc/nginx/ssl/key.key;
location ^~/blog {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
proxy_set_header X-NginX-Proxy true;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:2786;
proxy_redirect off;
}
location / {
root "/home/ubuntu/somedirectory/";
index index.html;
}
I think you haven't entered the config URL while setting up Ghost correctly.
You can do this by running the following commands:
ghost config URL https://my-domain.com/blog/
ghost restart
If this doesn't solve the problem, you can check out a detailed tutorial, solving this issue, on my blog here

Nginx as Reverse Proxy - Double Proxy Pass ? is this possible?

I have common problem anyone can encounter when you run nginx as a reverse proxy server for apache, i want to add double proxy_pass variables to the nginx conf. file but this doesn't seems to be allowed by nginx.
For example situations i have is
In my website i have chat engine runs by openfire, which runs on port 5280 with Jetty and i have set the apache proxy pass directive set as
ProxyPass /member-chat http://xyx.com:5280/http-bind
ProxyPassreverse /member-chat http://xyx.com:5280/http-bind
ProxyRequests Off
but i want to pass anything that comes to the "/member-chat" send directly to the chat-server rather than the apache, because then what apache would do is again proxy pass that to the openfire (member-chat), which takes more time and useless loading for apache.
when i add the nginx as the proxy server i want to add like this below but this didn't work, for some reason, it cant find the location gives me 404 error.
location / {
proxy_pass http://85.xxx.yyy.2x2:7080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
access_log off;
}
location ~ ^/member-chat {
proxy_pass http://85.xxx.yyy.2x2:5280;
proxy_connect_timeout 300;
}
I believe you missed out on specifying the URI for the Jetty service. With your current configuration, the request that will land up on Jetty port would be:
http://85.xxx.yyy.2x2:5280/member-chat
This is as per the proxy_pass documentation.
If proxy_pass is specified without a URI, the request URI is passed to the server in the same form as sent by a client when the original request is processed, or the full normalized request URI is passed when processing the changed URI
I don't think that is what you expect looking at your Apache configuration for the same. Try configuring the URI for proxy_pass directive as you have done for Apache.
location ~ ^/member-chat {
proxy_pass http://85.xxx.yyy.2x2:5280/http-bind;
proxy_connect_timeout 300;
}