My web server is not a standard Apache server, so the certbot software won’t work. However the SSL certs used are Apache format. And I can generate a CSR from my server. That’s what I do when purchasing SSL certs from GoDaddy.
I know I need to manually redo this every so often with Let’s Encrypt until I figure out how to automate it. But in the meantime, is there some way I can manually submit my SSL request and get a cert in return? I can authenticate with files uploaded to my server as needed.
Like @martin-s said, this error is likely because your echo is adding a newline in the signature. Be sure to either use echo -n or printf when piping the body into openssl.
For example, with certbot certonly --webroot (if you can serve static files with your existing non-Apache web server) or certbot certonly --standalone (if you can stop your existing web server temporarily).
I didn’t realize this. I will give it a try. If it’s possible to do with simple shell commands like that, maybe that’s also a guide to help me integrate certbot into my server so it can do it automatically later on. I’ll give it a try and report back. Thanks.
There’s also different browser ACME client called ZeroSSL that might also help you. Unlike gethttpsforfree, it doesn’t require running any openssl commands. If you have an ancient OpenSSL verison (like 0.9.8), that could explain your earlier signing error.
Yes, yes, I know we probably should have started with Ubuntu 10.04 and then regular upgrades would have been easier. But now it’s a nightmare.
I will try ZeroSSL for now. This is just a dev server I’m trying it on. But I have like 30 other servers, all with the same distro, but up-to-date kernels.
The ZeroSSL site looked so simple! Much less steps.
Unfortunately at the very last step it reported an “unexpected error” even though I was able to confirm that the /.well-known/acme-challenge link worked and showed the correct text.
In this case, some other software on your system is likely to have known and exploitable vulnerabilities. For example, a majority of the non-kernel vulnerabilities at https://usn.ubuntu.com/ that were reported after the Maverick EOL in April 2012 may still apply to your system.
I thought at first the problem might have been that our non-standard’s web server hadn’t been upgraded to the newest version in quite a while, so the TLS version was old. So I upgraded that. That should be upgraded anyway.
It still wasn’t working, so I decided to let ZeroSSL generate the CSR instead of having my server do it. That worked right away, and my site is showing a nice “locked” icon when I visit. Yay!
One odd thing this last time. For the very last try I was not asked to update the /.well-known/acme-challenge file.
Anyway, it worked.
Thanks everybody!
Our next step is to somehow automate this with our non-standard server so we can do this for all our sites!
Although I am glad to hear you got a cert, that is a very manual method.
Perhaps you can update the wget only.
Or use curl to download it.
Or grab that (certbot-auto) file on another system and move it in via any other method available to you.
Certbot-auto should still work (even with openssl 0.9.8)
[I can't say for how long - but it should work today]
I doubt you’ll have much luck with certbot-auto – if it even knows how to handle 10.10, it installs Python packages from PyPI, which coincidentally uses the same CDN and same modern TLS configuration as https://dl.eff.org/.
Doug, do you have any other (more updated) system on that same network?
If so, you may be able to use it to get the cert or even better:
To proxy* all your service requests.
[which could breathe some life into that old system - providing it modern TLS connections and security]
*Given that the service can be proxied.
For that I would look into NGINX - it seems to proxy just about anything these days!
Yeah, a general problem with using an operating system which has reached end-of-life from the OS vendor, apart from the likely presence of security vulnerabilities, is that lots of software is no longer available for that system. So Certbot uses lots of dependencies which may not be officially available for 10.10, even apart from the issue that @mnordhoff pointed out that 10.10 may itself not be able to understand how to interact with the servers from which the dependencies would be downloaded!
The Ubuntu folks have tried to make this easier by making LTS releases which are individually supported for longer—the most recent LTS release is officially supported for 10 years, whereas the non-LTS releases are now officially supported for less than 1 year apiece!
On the same network (different IP address, different host machine) I do have other servers running more updated versions of Ubuntu.
My web server itself, the “non-standard” server that uses the Apache-compatible certs, does use modern TLS connections and security. We do regularly update the OpenSSL package it uses, and it supports all the latest TLS security.
It’s just the host server machine itself.
The web server software does provide modern TLS connections though. Otherwise all the web browsers and APIs we connect to would complain.