LetsEncrypt on Raspbian - Port 80/443 Redirected to another Server so Challenges Do Not Pass

Hello,

I decided to experiment with hosting my server on the freshest version of Raspbian as an experiment of practicality. As I am building the perfect software suite, I am also carefully documenting the steps on an open wiki so that it is reproducible for others wanting to try the same thing. This server virtualhosts seven low traffic sites using Apache2.4.10. My current system is hosted on a 64-bit Intel-based netbook and seems to be working fine in Ubuntu Server.

I have found there to be little information on how to get LetsEncrypt to work on a Raspbian based machine, spare a few abstract documents, such as:

https://daplie.com/articles/lets-encrypt-on-raspberry-pi/

which is too indecisive and vague to be of much help and the document:

https://letsencrypt.readthedocs.io/en/latest/using.html#installation

which provided almost no information I could use (or make sense of).

For this, LetsEncrypt is an interesting alternative, but when I followed these steps:

$ mkdir letsencrypt ; cd letsencrypt/
$ git clone https://github.com/letsencrypt/letsencrypt
$ pushd letsencrypt/
$ ./letsencrypt-auto

It ended in error. You can see the typescript at:

http://timothylegg.com/letsencrypt.txt

I don’t know what it all means… The errors aren’t clear. What do I need to do? Did doing 7 domains exceed some sort of limit that was built into the software? I’ve tried running this as root too. There is no Raspbian package for LetsEncrypt, but I’m not afraid to install from source since that’s they way I used to install all software until package dependencies became cleaned up a few years ago. Could it be that there is a limitation in hardware, architecture or in licensing that makes it non-feasible for a package to exist?

I have to admit that I know very little about encryption and in the past, self-signed certificates worked great until the web-browser big-wigs came down on us and made it scary for ordinary people to use our sites (No coincidence this happened as the prices of keys went through the roof. Simply can’t afford paying for all those).

What should I do?

Thanks.

Hi @timothylegg,

This error means that there is an existing web server listening to HTTPS for these domain names, and Certbot attempted to reconfigure it temporarily in order to prove your control over the domain names, yet the attempted reconfiguration did not succeed in changing what the certificate authority saw when connecting to the domain names by HTTPS.

I just went to look at some of these sites, and they seem to have working Let's Encrypt certificates that you issued back in March (so, not ones that you managed to issue today). There are lots of things we could look at to try to figure out why Certbot didn't work, but here are two preliminary questions:

① How did you originally get and install those certificates back in March?
② Is the server that currently hosts all of these domain names the same physical server that you're running Certbot on now? I was confused by your reference to Raspbian and so on and I wonder if it's possible that you have two different servers, a working one running Ubuntu and one that you're trying to set up running Raspbian? If so, that's the explanation of the error: certbot --apache is meant to run directly on the web server that is currently hosting the domain names because it will need to make changes to that server in order to prove to the certificate authority that you control the domain names and hence are entitled to certificates for them.

I'm sorry that many people have had trouble with obtaining certificates and with browser policies, but I have to disagree with you on both points:

  • Self-signed certificates only defend against passive attacks, not active attacks. While active attacks are clearly much, much rarer, they are extremely easy to perform and there are widely available tools that can let someone carry one out. I don't think it would be the ideal path for the Internet to switch from defending against neither class of attack to defending against only one, when we may have the option to defend against both (especially if we can get tools that make it very convenient—and we seem to have been moving quickly in that direction).
  • I'm positive that browsers' treatment of self-signed certificates is motivated by the browsers' security teams advocacy for end-user security, and not by commercial interest on the browsers' part or by a desire to enrich certificate authorities. In any case, the existence of Let's Encrypt is specifically meant to guarantee that everyone can get certificates without having to pay for them.
3 Likes

I should qualify that and say “if people whose computing environment you don’t supervise or control use your service…”. If you’re the only user, or other people whose computers you administer are the only users, self-signed certificates can be perfect and provide excellent protection against all sorts of attacks.

Thank you for the information. Apologies for the rambling e-mail yesterday (sleep deprived and 7 hours off from my home time zone – I’m not usually like that.)

You are right. The machine I am installing on currently is separate from the machine presently hosting. Currently the router directs all port 80/443 traffic to the older machine. I had no idea that LetsEncrypt required that level of communication/accessibility. I will write that into the wiki for sure.

My solution for now would be to direct ports 80/443 to the new machine (the PI) and leave the old machine (the Netbook) to collect e-mail for now. Then repeat the execution of the script. If there is any problem anybody can forsee with this approach, please do let me know.

With great appreciation, Timothy D. Legg

For other cases where you can't run directly on the server, there are at least three options:

  • An HTTP 301 redirect from the server to the machine where you're running the client, for the path /.well-known/acme-challenge (the verifier will follow this redirect)
  • The DNS-01 challenge, where you prove you control the domain by updating a DNS record, rather than by receiving an incoming connection (which is currently best-supposed by other clients like acme.sh)
  • Manual modes (like certbot --manual) where the client tells what configuration change needs to be made and then pauses until the user claims to have completed making this change

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.