I am not really surprised at this result :
n0# ./certbot-auto --verbose --dry-run --apache certonly
./certbot-auto: OLD_VENV_PATH=/root/.local/share/letsencrypt: is not an identifier
So this is an Oracle Solaris 10 server on SPARC and I can run everything needed from
the command line. Full ssh access and root level and the console too. However the
certbot of course fails. Is there a way to just run openssl and create the CSR and then
move along with normal Apache config here ?
Hi @genunix,
For that OS I would give a try to acme.sh it is a shell script and uses just a few common utilities like wget or curl, openssl, socat…
Cheers,
sahsanu
I just tried that and acme fails also … it assumes some things that do not exist in a strict posix system environment.
n0# curl https://get.acme.sh | /usr/local/bin/bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 705 100 705 0 0 743 0 --:–:-- --:–:-- --:–:-- 760
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 148k 100 148k 0 0 237k 0 --:–:-- --:–:-- --:–:-- 286k
[Fri Sep 22 18:21:46 GMT 2017] Installing from online archive.
[Fri Sep 22 18:21:46 GMT 2017] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz
[Fri Sep 22 18:21:47 GMT 2017] Extracting master.tar.gz
tar: z: unknown function modifier
Usage: tar {c|r|t|u|x}[BDeEFhilmnopPqTvw@[0-7]][bfk][X…] [blocksize] [tarfile] [size] [exclude-file…] {file | -I include-file | -C directory file}…
sh[16]: gtar: not found
[Fri Sep 22 18:21:47 GMT 2017] Extraction error.
n0# ./acme.sh --install
[Fri Sep 22 18:22:25 GMT 2017] It is recommended to install socat first.
[Fri Sep 22 18:22:25 GMT 2017] We use socat for standalone server if you use standalone mode.
[Fri Sep 22 18:22:25 GMT 2017] If you don’t use standalone mode, just ignore this warning.
[Fri Sep 22 18:22:25 GMT 2017] Installing to /root/.acme.sh
[Fri Sep 22 18:22:26 GMT 2017] Installed to /root/.acme.sh/acme.sh
[Fri Sep 22 18:22:26 GMT 2017] Installing alias to ‘/root/.profile’
[Fri Sep 22 18:22:26 GMT 2017] OK, Close and reopen your terminal to start using acme.sh
[Fri Sep 22 18:22:26 GMT 2017] Installing cron job
./acme.sh[2]: %s % 60: syntax error
0 * * * “/root/.acme.sh”/acme.sh --cron --home “/root/.acme.sh” > /dev/null
crontab: error on previous line; unexpected character found in line.
crontab: errors detected in input, no crontab file generated.
[Fri Sep 22 18:22:26 GMT 2017] Install cron job failed. You need to manually renew your certs.
[Fri Sep 22 18:22:26 GMT 2017] Or you can add cronjob by yourself:
[Fri Sep 22 18:22:26 GMT 2017] “/root/.acme.sh”/acme.sh --cron --home “/root/.acme.sh” > /dev/null
[Fri Sep 22 18:22:26 GMT 2017] Good, bash is found, so change the shebang to use bash as preferred.
[Fri Sep 22 18:22:26 GMT 2017] OK
n0#
So just one failure after another here. I have curl and openssl and the basics but the scripts don’t look into /usr/local/bin or /usr/local/ssl/bin which is actually a very standard location. I just have to make the CSR manually and that is fine.
I am working on it. Just going to go over the script now and see where I can do something useful here. This may be just a trivial issue with locating a few tools needed.
Let's see if @Neilpang can help you to solve these issues because in his page it claims SunOs Solaris as a tested OS but maybe it relies on GNU utilities instead of the ones provided by the OS.
Yes, you can create your private key and the CSR (Certificate Signin Request) but you need to send it to Let's Encrypt so it can validate the domains in your CSR and once done, give to you the signed certificate and it is not trivial.
If you can't run any client directly on that OS, you could run a client from other system using a manual process. The manual process could be create a specified file into an specified dir in your web server or create an specific TXT DNS record to validate your domains. In case you followed all the manual process, the certificate will be located in that other machine and you will need to move it to your Solaris machine.
You can also have another option, using an online service as the client.
For example:
It is indeed a javascript that you can run on your own machine.
It has a complete wizard that will guide during the entire process.
The pain, certificates are valid for 90 days so will need to repeat this manual process every 90 days or less (recommended).
If you can't finally run a client from your Solaris machine, I would recommend the DNS challenge, if your DNS provider has an API to modify/create/delete records, then it should be "easy" to run the client on another machine and then move the certificate to the Solaris machine, using ftp, scp, whatever.
You have options, but the ideal is to be able to run the client from the same machine of course ;).
Good luck,
sahsanu
We run our own DNS servers as one would expect. There are a set of ISC Bind daemons running in a few datacenters. This has been a bit experimental and I may just go back to Veritas or whatever. I would prefer to donate to the letencrypt side of life however as it is socially responsible.
Sorry for the problem.
It seems that your tar command doesn’t support -z option.
Please download or clone the source code from github: https://github.com/Neilpang/acme.sh
And then install from local extracted sourecode:
./acme.sh --install
if it still has problem, please add debug info:
./acme.sh --install --debug 2
If the problem is just a tar that doesn’t know about -z, you can also try gzip -d on the tar.gz file first, and then extracting with tar -xvf. (If you have gzip 
)
At the moment I am fine with manually creating the CSR and doing the required openssl commands. I have no idea how this became so complex to just get a SSL cert into apache.
It became "so complex" because the point of Let's Encrypt is to automate issuance and renewal of the certificates. If that's not something you want to do, perhaps a different CA would meet your needs better.
And if you're comfortable using CSRs and getting certificates manually, the web-based clients that @sahsanu mentioned above should work pretty well for you (they allow you to provide your own CSR and then give you an experience akin to a traditional DV CA, but without a payment step). Just remember that Let's Encrypt certificates are only valid for 90 days.
A far better approach is to work with acme.sh and to see if it is possible to make it work in a really bare bones stripped down environment wherein all the usual XPG4 and POSIX type rules exist but nothing more. I am always amazed at what can be done with sed/awk/grep and some pipes.
That would be great!
Another shell script client with minimal dependencies is dehydrated. I’m not sure if it would work better, but it might be worth trying. It works well for me, but that’s on Linux.
Thank you. That looks to be excellent. I have a few projects on the go but I really want to put a bit of time into getting these to work. I think that the “dehydrated” script should work but I will let you know. Getting “acme” working would be a really great idea as it looks to be a comfortable entry point in the unix/linux world and it also should “just work” but it doesn’t either. This is not the fault of good and determined authors. This is the fault of the Linux world which has long since drifted away from well established standards. That is to say, there are vast extensions and gnu-isms tossed into simple commands and these are the defacto standard these days in spite of the fact that “tar” does not do compression and never has. Ever. The situation with GCC is even more desperate. We now have gnu C type things that have no place in C99 and so code gets written all the time that simply doesnot “grok” in some industrial iron. The gnu tar may actually do great stuff ( which it does! ) but the output may not be portable. At least not the POSIX tar file format. Then again the output could be perfect POSIX.1-2001 spec compliant and then compressed and this is what the gnu tar extension really does. Nice. However it can not be processed everywhere with a simple tar. There are a million examples of this from “grep” to a simple “ls” with odd ball options. No one is to blame. Good work is being done by good people and they allow us to stand on the top of mount Everest with the world laid out before our feet. However there are thousands of bodies that litter the mountain over the years and many people have worked endlessly and tirelessly to allow the average user today to simply boot up Debian 9 and whammo they have everything. That is what “certbot” is like. It is the star trek transporter that allows the user to instantly arrive where they want to be. Awesome. It should be left alone to do what it does and not messed with. It is not “portable” in that any system anywhere with basic standards compliance can run it. Those type of systems are very rare but they exist all over the industrial world. Oxymoron? Not really. I am labouring on here a bit but simply wanted to say that great work is being done all over the place by many people and the result is nearly pure magic to the average user. Everyone should be thankful. I know that I surely am. However portable software and portable solutions are really stuck dealing with strict compliance rules and they are no fun to work within usually. So here we are in 2017 standing on the top of the highest mountains with every tool we could dream of and yet we are also stuck with horrific situations like POSIXLY_CORRECT=1 and POSIX_ME_HARDER=1.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.