Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is: dogod.com
I ran this command:
via cron: "/home/matthew/.acme.sh"/acme.sh --cron --home "/home/matthew/.acme.sh"
It produced this output:
Yet to try, but I know it will be the wrong format
My web server is (include version):
The operating system my web server runs on is (include version):Busybox
My hosting provider, if applicable, is:Me
I can login to a root shell on my machine (yes or no, or I don't know): Yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): acme.sh v3.0.8
Hello!
I have 3 domains that I host for silly things and I wanted to get ssl certs for them as some browsers have refused to open non encrypted sites and the rest make noise about it being dangerous. Urg. So I got acme.sh working and got certs (and promptly managed to delete them, but that is another story). I have all 3 sites working with the certs now, though I have some questions that hopefully I can get some answers on.
I chose, rather than dicking around moving the certs to another place, I found it easier to just point the browsers to where acme.sh puts the certs by defaiult. Is this bad form? It just seems a lot easier.
Most of the webroots live on an USB stick that is mounted RO. I had to umount it and mount it RW to do the webroot authentication. Am I going to have to do that again for the renewal or is my system now "trusted"?
I need the certs in pem format. It was easy enough to cat the files together, but that was a step I had to do. Apparently there is a --cert-file and a --fullchain-file option that can be used to create pem files directly in the request. How would one add that option to the --cron option? Perhaps in acme.sh.env?
Or, would I be better off coming up with my own command lines and run them out of cron on my own, and scrap the --cron option.
The certs are in PEM format. "Cert and key in the same file" is not PEM format; it's simply convention that some web server software uses.
Use the --install-cert command to put the files where you want them, and then --reloadcmd to do the concatenation. Something like acme.sh --install-cert -d whatever . . . --reloadcmd "cat fullchain_file privkey_file > combined_file && service whatever reload. Once that's finished, it will update the various acme.sh config files to do this at every renewal.
Thank you all for the advice. The web server is living in such a small space, it really does not have a "better" place for the certs, but I can make one that is not the ajax.sh default. I have some stuff to think about.
One more question, will it upset anybody, or just not happen if I fire off the renew scripting when I think I am done with it? I saw someplace there is a second server that has more relaxed rate limits, would that be advantageous to use to get the bugs out?
Thank you for the clarification! This is all new to me. Oddly enough I looked up how to turn cer files into pem files and got an answer that involved doing some manipulation with openssl, and that did now work, and after that I saw people saying just cat the two files together, and that worked.
It is very helpful when testing the issue command as that actually gets fresh certs. There are various rate limits on the production system one of which can lock you out for a week (see docs here). The staging system is much more tolerant.
The install-cert and deploy commands act on existing certs on your system so staging system is not needed. You are basically just copying your own files around with these (and restarting services and such).
That makes sense. In this case though there is a bit more that has to happen when the certs are issued. the usb sticks the web root is mounted on needs to be unmounted, and re mounted read write while it does the exchange..Once the script ends, it needs to be unmounted again and re mounted read only. I also looked for any dot files left over from fetching the certs in the webroot and did not see any. I have some work cut out for me getting all the odd little pieces lined up, but it is coming along.
I have a couple more questions,,
Based on the acme.sh suggestion that the certs no be used where they land because that is subject to change, am I reading between the lines in thinking that the protocol may change and a new version of the script may be necessary, and this perhaps is not the best thing to use in a small canned system? It would seem the file locations would stay put as long as the script does not change, and there is no reason to change the script if it is working, unless the underlying protocol changes,
If I back up the real certs I have from the production server, if I point at the test server and get certs from that, just to make sure my pieces all line up, and as much as I would like to think it is all going to go right on the first crack I know better. So if I get certs from the other server for testing, and I get it all working, is there an issue with pitting the real certs I backed up back in place and letting them live their lives out until they are renewed?
I would like to thank everybody here for their input and ideas.
That makes sense.
But you have to ensure that acme.sh doesn't automatically update itself [which I think is the default installation action - not 100% sure on that].
If it does auto-update, all you need to do is run a deploy hook to copy the cert files from wherever acme.sh currently stores them to a location you specify.
The increase in used space is one additional cert and key [copy].
How tight is your free space now?
It depends on how much you backup/restore.
I don't know exactly how acme.sh functions, but I'm sure it ties in more than just the cert files themselves into the renewal settings. If those "settings" are not backed up and restored [to the liking of the program], you may have to issue a new cert to get it into the renewal cycle.
I have been reading manuals, lots of them, The question is which manual, and the internet is chock full of things that are contradictory and or downright wrong. Also when I said "backed up the certs" I tarred up the entire dogod.com_ecc directory which also has the "pem" file I made by catting the cert and the key file, and a bunch of other stuff,
The acme.sh script has an update command line option so I do not think that it is going to update itself. My concern about updating goes beyond the location of the files it fetches. I also have to worry about it either using a more advanced option in any system program it calls, or if it calls another system program that it did not call before. The vast majority of the system programs I have are from busybox and as a rule are watered down versions that do not support the full array of command line switches the "real" versions do. I currently have those dependencies met, but an upgrade could break them,
As far as space, the OS with a few things, the web server, and all the certs etc have to live on a 128MB SSD, so quarters are somewhat tight. Sometimes breaking a convention is not bad, as long as you are aware of why the convention exists and the ramifications of going against it. One of the more humorous cases of that is the DontBlameSendmail argument to sendmail.
Again, thank you for your help, it really is appreciated.
Another option is to use a DNS Challenge and just copy the cert and privkey files to your web server. The DNS Challenge could be run from any machine. To automate requires your DNS provider to support an API. See the acme.sh github for all the DNS providers it supports (which is many). A manual method is possible but tedious every 60 days so best avoided.
This would allow you to keep acme.sh itself current and the two cert files are pretty small especially with the current default shorter chain.
I will have a look and see if they support my DNS provider, though that approach seems to have even more moving parts. Stil it is worth looking at. Thank you for the tip.
