I’ve set up a simple mitm reverse proxy on Ubuntu: mitmproxy --mode reverse:http://host.example.com/ --set block_global=false --set listen_port=80
The listen_port is being ignored; I get RSTs back for requests sent on 80 (8080 is still in play). What I really want the reverse proxy to listen on both 80 and 443.
Separately, but related, I'm struggling to find up-to-date and accurate documentation - https://mitmproxy.readthedocs.io/en/v2.0.2/ is not the answer -; what are people using?
Regarding documentation - on project's website there's Docs -> v4 (latest release).
Related
Im trying to enable HTTPS using this guide (https://thingsboard.io/docs/user-guide/install/pe/add-haproxy-ubuntu/#step-10-refresh-haproxy-configuration) but i got stuck on step 9 i believe.
sudo certbot-certonly --domain your_domain --email your_email
I get the following error
certbot: error: unrecognized arguments: --tls-sni-01-port 8443
As far as i can tell, lets encrypt no longer supports this argument (tls-sni-01-port) or using ports other than 80 and 443. I got this from (https://serverfault.com/questions/805666/certbot-letsencrypt-on-different-port-than-443).
I am uncertain as how to solve this problem.
Here is my docker-compose.yml for Thingsboard + HTTPS through Nginx reverse proxy with automatic Let's Encrypt certificates: https://github.com/michalfapso/thingsboard_docker_https/
It uses linuxserver/swag which takes care of the certificates and is kept in sync with Let's Encrypt requirements by the linuxserver.io community.
I've just done a fresh install of Ubuntu 20.04 and followed the Digital Ocean instructions to get my apache server up and running:
https://www.digitalocean.com/community/tutorials/how-to-install-linux-apache-mysql-php-lamp-stack-on-ubuntu-20-04
Which worked fine for HTTP traffic, then I used the Digital Ocean instructions (which I knew, but followed them anyway) to set up for SSL (https) access:
https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-20-04
I selected the option to redirect all traffic to https. I opened my firewall using sudo ufw allow 'Apache Full'.
But I am unable to see my sites - the browsers just timeout. I have tried disabling ufw just to see, and nope, nothing.
SSL Labs just gives me an "Assessment failed: Unable to connect to the server" error.
I also ran https://check-your-website.server-daten.de/?q=juglugs.com
and it timed out:
I have deleted the letsencrypt stuff and ran through it again three times with the same result, and now I'm stuck...
Everything I've searched points to a firewall error, but as I've said, I've disabled that and have the same result. The router settings have not been changed since I did my fresh Ubuntu install.
Any help gratefully received.
Thanks in advance.
on8tom answered this one for me - In setting up the new build of Ubuntu, my local IP address for the apache server had changed, and my Virgin Media Hub only had port 443 open to the old IP address.
Many thanks for pointing me at that (but I should have checked that before posting this - kicking myself!)
The Valhalla maps server docs assume that the server is always running on "http://[hostname]:8002"
(see https://github.com/valhalla/valhalla)
How can the server be configured to listen via SSL/https instead?
Is there any detailed documentation on how to do this?
Thnx.
To answer my own question:
After much reading & research I came to the conclusion that a practical way to achieve this is simply to hide the Valhalla port (port 8002) behind my Linux firewall and to expose port 443 (SSL) instead and have Nginx running on that port. Nginx then port-forwards the Valhalla request obj to the internal port 8002 and proxies the response back to the caller for the return journey on the encrypted channel.
Setting up Nginx to achieve this is fairly straightforward and the procedure is documented on many websites.
Has anyone been successful with using Letsencrypt SSL with a default jetty install? I can't seem to get it right.
More info:
OS: Ubuntu 16.04
Jetty Path: /opt/jetty
Only thing adjusted is enabling http on port 80 in start.ini.
Problems I have run into:
When I input --module-ssl into the start ini, I get the error
No default protocol for ServerConnector#48aca48b{null,[]}{0.0.0.0:8443}`
starting jetty and it fails.
I have tried inputting the SSL info into the ini, as well as editing the .xml files with the info.
I know this is an older question, but in-case people stumble across it on Google with a similar issue:
The SSL module in Jetty is just the base cryptographic functionality. You need to do something with it - i.e. also enable the https or http2 modules.
In other words, for standard https you actually need:
java -jar start.jar --add-to-startd=ssl,https
So it's not the best of error messages, but:
No default protocol for ServerConnector
Means just that - it didn't previously have a protocol (implementation) to use the ssl module with, because the https (or http2) modules hadn't been loaded.
The default installation instructions show how to set up a server on port 80 using HTTP and WS (i.e. unencrypted).
The agent installation shows that TLS enabled servers are possible (I'l link here, but I'm not allowed).
The server configuration options show that DRONE_SERVER_CERT and DRONE_SERVER_KEY are available http://readme.drone.io/0.5/install/server-configuration/
Are there any fuller instructions to set this up? e.g. have port 80 forward to port 443 and have all agents talking to the server over encrypted channels.
If you were using certificates with drone 0.4 it will be the same configuration, although the names perhaps changed slightly. You will need to pass the following variables to your container:
DRONE_SERVER_CERT=/path/to/drone.cert
DRONE_SERVER_KEY=/path/to/drone.key
These certificates will exist on your host machine, which means their paths need to be mounted into your drone server:
--volume=/path/to/drone.cert:/path/to/drone.cert
--volume=/path/to/drone.key:/path/to/drone.key
You can also instruct Docker to expose 443 and forward to drone's default port 8000
-p 443:8000
When you configure the agent, you will of course need to update the configuration to use wss. You can read more in the agent docs, but essentially something like this:
DRONE_SERVER=wss://drone.server.com/ws/broker
And finally, if you get cert errors I recommend including the cert chain in your bundle. Bottom line, drone does not parse certs. Drone uses http.ListenAndServeTLS(cert, key). So any cert issues are coming from the standard library directly, and questions should therefore be directed to the Go support channels.