While setting up SSL reverse proxy using lets encrypt and nginx i had a few troubles with testing via googles Chrome browser.
Chrome caches some SSL responses which can be cleared by deleting your browsing data via settings or Ctrl+Shift+Del.
Chrome also caches http -> https redirects, you can see these by going to chrome://net-internals and select “HSTS” from the drop down. Enter the domain name under “Delete domain” and press the Delete button
The easiest thing to do during testing is use incognito mode. You will not need to clear the cache every time you change config or re-issue certificates.
I’ve been a fan of HTTP and caching since my dial-up modem.
Skip to today where google returns HTTPS sites higher in its search results. Its could also be possible that you cannot trust a man in the middle HTTP cache any longer either right? :)
SSL certs have traditionally been expensive, but say welcome to lets encrypt which provides a free way of securing all of your websites. If you haven’t heard of it check it out here – https://letsencrypt.org/
As always i’ve implemented my LetsEncrypt trial via docker. The container image i have been using has been put together by the linuxserver guys – https://hub.docker.com/r/linuxserver/letsencrypt/
(i use a few of their container images, they seem legit)
This container image comes ready to roll with Nginx built in which can act as a reverse proxy to your unsecured websites at the back-end. I’ll be testing it for the next few days to see how it stacks up, but so far so good. Nginx is fast, so a good transition if only to offload all my SSL traffic. If all goes well it will be the end of my squid reverse proxy which i have used happily for many years.
In the past http had the performance, certs were too difficult (but are they?) and expensive to implement and i was a fan of my sites being cached. New times are here, SSL (TLS) rules supreme.
On another note, HTTP 1 sites are dwindling, SPDY didnt last long but apparently some of that has been built into HTTP/2 – exciting!
Things you’ll need; (basic instructions)
SSH – either Linux or Open SSH for windows (set this up first and ensure its working!). I have only used Linux, so i do not know the details of setting up a Open SSH box on windows (good luck).
Router with pinhole or port forwarding abilities. — forward your external 443 port to internal 22 on your SSH box
Putty.exe – use this to test your SSH connection locally (you should be able to connect on port 22 locally or 443 externally)
Your home IP – setup a dyndns account on one of the free services available on the web (either use your router if it has it or get a dyndns client that runs on your ssh box) — i use dyndns.org
Putty is the client side device that you will use when you are not local to your network. If you are connecting to your SSH box from external (i.e. at work) then you’ll need to configure a SSH connection profile to connect on port 443. If you have a proxy at work (which you will most probably have) you need to ensure you have filled out your proxy address and authentication details — select HTTP then enter your username / password. Then try to connect.
When you can successfully connect to your SSH box from work via 443 you can then create SSH tunnels. Under SSH on putty there is a tunnels option. This is where you can forward local ports to your remote ports… for example – 127.0.0.1:82 –> 192.168.0.10:3389. Then if you fire up RDC you can connect to your remote machine via 127.0.0.1:82
Simple? — if i haven’t made a specific part clear please ask any questions and i’ll try to make it easier to follow