Raspberry Pi compatibility


#8

Yes it does tell you that:

Make sure your web server displays the following content at
http://hostname.example.com/.well-known/acme-challenge/challenge-key before continuing:

{“header”: {“alg”: “RS256”, “jwk”: {“e”: “AQAB”, “kty”: “RSA”,…

So ensure you have the generated challenge file visible on the webserver on the pi (& obviously test it in a browser) & when its there just hit enter.

You’ll note it’s expecting it on port 80!


#9

but the webserver doesnt have to be the pi does it? I mean LE checks whether the challenge is on the pi or some other server as long as it’s on the domain


#10

It should be on the webserver, although for the challenge to work it might be enough. I’ve not tried it that way.


#11

but the webserver technically doesnt have to be the pi, right?

especially if LE wants to run without root then LE cannot use port 80 on itself anyway (or any other port >1024)


#12

It needs to run as root, even in manual mode as it creates config under /etc/letsencrypt even in manual mode. I’m not certain if there’s a command line parameter to allow that to be elsewhere.


#13

well it was said that they at the very least WANT it to run without root, since not everyone has a server with root access for his domain.

or rather it can do that:
Quote from FAQ


#14

I have succesfully used LE on Raspberry PI 2 running Ubuntu. Haven’t tried on Raspbian yet, but should be no problem either.


#15

A bit off topic, but come 16 November, will the client be aware of the OS it’s running on, or will I have to manually edit the script?

I’m just wondering as I’m on FreeBSD 10.2 and I need the client to create its config under /usr/local/etc/letsencrypt (I haven’t played with the client yet so I’m not sure how aware it is).


#16

Correct, the traffic just must be routed to the device where the file is saved. Basically that can be done if the webserver and the Pi have the same IP. (behind a NAT)


#17

The general answer about Raspberry Pi compatibility is easy:

The client is written in Python. So everywhere where Python can be executed you can run the client and therefore get a certificate. Of course that’s possible on a Raspberry Pi.

The only things I can image which could prevent this are some incompatibilities to other software (webserver), which would prevent the automated installation and in some cases renewal of the certificates. However that’s very unlikely if you speak about the hardware you choose (Raspberry Pi), because you can install almost all important Linux software on all Linux devices, so what matters much more is the software you use.


#18

do the webserver and the pi really need the same IP?

imagine this:

I have some hosting where I dont have SSH but wanna have LE so I try to use my Pi (which is at a completely different IP) so it should go like this (manual mode in theory)
Pi contacts LE server and requests and account for example.com
LE Server tells Pi the challenge (in this case webrrot)
Pi shows the user the challenge
User puts challenge on server
User tells Pi to tell LE that the challenge has been completed and can be verified
LE goes at example.com/challenge-url to check the challenge
LE tells the Pi whether it was successful or not.

I dont see any reason why the Pi and the LE client have to be in the same network or even need the same public IP

I dont really wanna take a site down for a while (DNS TTLs can be awfully long when you dont want it) just to make a cert and it doesnt really make sense to do so.

also I said often enough manual mode since the Pi is just the means for the purpose (like having a server without SSH or a windows webserver)

so with python it is more or less like with PHP or javascript, so as long as I have a proper interpreter the architecture doesnt matter? that’s nice.


#19

At first it of course depends on the verification mode and there are a few different currently.

The second thing is: No it does not really have to be the same IP. I just told it because it was the easiest solution/use case I could see.
Generally (when using a non-DNS-based verification method) you just have to get the traffic from the LE server to your Raspi which you want to verify. So It’s all about this step:

How you do this is your thing. BGB routing can be manipulated quite easily, but… eh… no that’s more an attackers scenario. :wink:
Other things you could do include temporarily changing the DNS record or just using another challenge method like DNS-based verification.

So you see: It depends…


#20

how ofte am I writing that I am talking about the manual mode?

but why?
cant I just push the challenge I got from the raspi to the server and LE gets the challenge from that server so I dont have to take my website offline?


#21

In manual mode you still have all verification methods. Have a look at the specification at https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7 for more details.

The LE server has to access your server like any normal visitor. And he has to use the normal domain (example.com) for this. The reason is that this is one easy way to verify that you are really the owner of the domain - that’s the aim of every validation challenge. That’s why you cannot push the LE server a different IP/domain to connect to, because the thing it wants to verify is not that you own a (random) server,/domain but that you own exactly the server/domain for which you want to get a certificate.
As I already said another method is to use DNS validation where this challenge does not happen at the server level, but before that.
This method and the webroot domain verification method are AFAIK the only ones, which you can currently use without restarting the server.

Apart from that you can just run the LE client on the real server (and IMHO it would also be the easiest way) instead of doing this on some other server.
Maybe it would be a good idea for you to tell us why you actually want to use the Raspi and not the real server and we can look for more specific solutions than commenting on general things like this. Especially as this discussion at the end is not really much related to the topic implied by the headline and mentioned in the first post.


#22

I dont mean a random sever but I have a serverr that is acting a the webserver for the domain and that is not in the same network etc as the raspi. like my raspi is at home and the server is at some hoster. I get the challenge from the raspi copy ot to the server LW checks the domain (lands at the server) sees the challenge and finish. why shouldnt that work?


#23

It always depends on how you describe it. This is much more detailed, so I can say: Yes it should work.

Of course you can manually create the challenge on your Raspi and copy it to the real server. At the time when it’s on the real server it’s all okay, as the LE server can access the domain.
I just know no reason why such a complicated step would be necessary as you can just run the LE client on the real server, but yes it’s possible…


#24

I have at least 2 scenarios where it doesnt work: A) windows. b) Server without SSH, like, your average webhosting


#25


Without root access you have no way to configure your server to use a HTTPS at all.
There may be hosting providers supporting it…


…or - if your hoster provides another way to add the TLS certificates - you may be able to use the webroot authentication method: Using the webroot domain verification method

But before I’m talking rubbish - as I’m not really sure whether the webroot method would work in this case - I’ve created a new topic to discuss this independently from a Raspberry Pi:

Edit: Webroot method is not suitable for shared-hosting.


#26

You can buy a Intel compute stick and install Ubuntu on it. It don’t have a ARM CPU ran a server very good. That’s what I am doing with mine.

-Raymond Day


#27

okay I just got my beta and ran LE which worked rather easy even with manual mode, I thought it was a lot harder, I just got that insecure SSL stuff which was fixed by 3 lines in the le-auto, wo no big problem, next I try to check on CSR usage, but that’s another topic.