I host my website "baffleplates.com" in my house on a server I wrote using 50 lines of GO.
In 2019 I got certbot running with help from your community. (My notes say your support was terse but effective). Happily I updated my cert/key every 90 days and updated the DNS record at my registrar.,.. godaddy (sudo certbot certonly --duplicate --manual --preferred-challenges DNS)
Now I am retiring my development machine, now also my webserver, running Solus linux (a Dell 9020 8Mb ram 500Gb HD) as first Solus and more recently firefox no longer autoUpdate.
I am setting up replacement (Dell 9020 8Mb 250GB SSD) running Latest Fedora workstation and decided to get the latest certbot.
What is the best way to get the current version ? I read your documentation but it seems to be aimed at more complex needs.
I can use su and sudo on the server I am setting up; I dont need to use ssh
I use vi to manage my site.. currently GO and HTML; in the future likely C and HTML.
All help much appreciated. My website is currently down and my current certificate expires in a few days which is why I have not used the current one.. (Also the wood heating season draws to its end and interest will drop until the autumn.
As an aside, I would still advise against using your home machine as a web server other people connect to.
You are paying at least $2.58-$10 per month for the electricity and you can get an AWS lightsail instance for similar cost (or many other hosting options). If you're site is static there are quite a few free static site hosts (cloudflare pages etc).
[Edit: I'm not suggesting $cost is the issue, I'm suggesting security of your personal machine is the cost ,which you can alleviate with low $cost hosting]
Glad you got it working. You shouldn't wait until the 90th day to renew. Let's Encrypt recommends renewing with 1/3 of its life left. If you have confidence in your manual method and are diligent perhaps you can wait a bit. But, there can be outages of many kinds that can prevent renewal. We've seen backbone network problems interfere with renewal that have taken days to resolve. Sure, these are rare but do happen.
Another is that cert lifetimes are shortening across the industry. Moving to an automated method is highly recommended. With a single domain name and your own server using an HTTP Challenge should be easy to automate. In any case, be aware of this timeline which will require more frequent renewals: Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt
I realize my initial comment came across as being about the cost, that was an incidental, the real issue is that your home server can theoretically be compromised by the first bot that knows the right vulnerability to exploit.
I'm totally just assuming that you are hosting on a machine you use (or its on the same network) you may indeed have it all secure. You can just ignore my comment, totally off topic.
Thanks for your thoughts Mike and for the 45 day news. I read the link and subscribed. All will become clearer in future
I also have to update the DNS data at my domain name registrar. Possibly I could get them to supply a certificate and forget about doing things myself.
Here in Australia spring is here so demand for woodheater baffleplates is minimal; this gives me a few months to rework my website.
.
There appear to be changes in how SEO works. Searches from a computer still rank me well, from a phone I doubt anyone will find my site now.
In the 80s I wrote an efficient multiuser database and software for stock control. Obviously Legacy stuff. When my best site needed 8 terminals I moved to SCO Unix. The compiler I used was not compatible with Linux and my attempt to write a compiler years ago failed.
So I hope to write a minimal stock control system for my own use using C and HTML in the next few months.
Todate I have setup a new server and recovered the original website and started testing the replacement programs. An SSD means the replacement server boots much faster.
Next to develop a better system linked to a database with good visibility from mobile phones.
Sure, understood. But, what I was suggesting was to use an HTTP Challenge rather than a DNS Challenge to get your cert. The overview is here: Challenge Types - Let's Encrypt
Using Certbot your command would be something like:
Where PATH is some path accessible to your custom server. When testing add --dry-run to that command to use the LE Staging system rather than production.
That command has Certbot placing the auth token in that PATH (actually a subdirectory). The Let's Encrypt server sends an HTTP request on port 80 to your domain requesting that token. There will be multiple identical requests from various points in the world (today 5). These requests have the format of below so your server just returns the token in reply to those requests
Once you get a cert Certbot saves the request options in a renewal config file. You setup a cronjob or systemd timer to run Certbot at least daily with this command
certbot renew
And you should have automated certs "forever"
Way easier than any manual method and will automatically adapt the shorter lifetimes. Certbot uses ARI for renewal signals from LE so also renews in case of LE-initiated revocation events (rare but do happen)
Your server already responds to HTTP requests so should have no trouble replying with the token instead. You may need to add flexibility for the acme-challenge path but that seems well within your skills.
I assume that if I use --dry-run on my development system with the HTTP method then my production system using certbot supplied keys previously will continue to function normally.
You people normally get things right but it seemed sensible to check.
You can safely use --dry-run on either machine. Certbot sets up an account unique to the Staging system alongside any other accounts (alongside accounts for other CA even).
Further, --dry-run does not save the Staging cert to your system. The --dry-run is ideal for testing that challenges behave correctly. It is also useful as sudo certbot renew --dry-run to test all renewals with staging. You just have the one but it works for any number.
There is also a --test-cert option but much care is required. It uses Staging system too but will save the issued cert in the same location as if --test-cert was not used. This can clobber production certs. Staging certs are not trusted by browsers or other clients.
Security is a concern. I try to code tightly and avoid using external products whose quality I cannot control. Linux I have to trust and I will probably look at Harmony down the track. Back in the 80s I decided it was impossible to get sub-second transaction response times from the microsoft environment so I went elsewhere.
I log unexpected traffic to stdout and there has been an increase in the last few days possibly because I mentioned my website in my post here.
Hacks can always happen but I am not aware of being hacked.
My OS stopped updating when support for the GUI I used was discontinued. I clicked the button to upgrade to a supported GUI and the upgrade failed. At this point both Firefox and OS upgrades stopped working. Likely not a hacking problem.
Paying $3-5 for a VPS, or $0 for a small AWS EC2 gives you peace of mind that an 0day doesnt take your home box and home net and instead an easily tgz'ed web server and a cert youd revoke and get a new one - with assumerd
nothing else of value lost.
A VPS will also let you run your own DNS so you dont have to rely on your provider and can cron the updates.
Im surprised the SCO copiler wasnt compatable with Linux since all SCO boxes were x86 and unixbased, but my knowledge is limited - its either from one of Stevens books or Raymonds or possibly Knuths.
Id get a firewall on there asap, something very easy like the following would have stopped 45.249.244.55 - twice.
First as their maxconns is > 6, second they had more then 5 conns within 20 seconds.
iptables -A INPUT -p tcp --dport ${PORT} -m conntrack --ctstate NEW -m recent --rcheck --seconds ${WITHIN_N_SECONDS} --hitcount ${MAXCONNS_WITHIN_N} --name ${BRUTE_FULE_NAME} -j DROP
iptables -A INPUT -p tcp --dport ${PORT} -m conntrack --ctstate NEW -m recent --set --name ${BRUTE_FULE_NAME}
iptables -A INPUT -p tcp --dport ${PORT} -m conntrack --ctstate NEW -j ACCEPT
I would very much not like to see those bytes. Also is /sitemap1.txt to /swagger.json "I log unexpected traffic to stdout" ? I hope for your sake its not.
"Hacks can always happen but I am not aware of being hacked."
You woudnt be most of the time.
