I just want a certificate

Okey, have been waiting for letsencrypt since forever…
Finally in beta, but I cant get it to work.
I just want a cert file. No fancy auto-installers. Just a cert.

I’m using “certonly” + “webroot”

The server could not connect to the client for DV :: Could not connect to http://*****.se/.well-known/acme-challenge/-ZGs*******VxsINcbcI

So whats up?!?
Does the machine I run this from need to be open/port forwarded?
It also asked for root password, wtf?! I’m reverting the VM im running this in immediatly.
I really looked forward to this, but at the moment it’s just a mess.

I can’s answer everything for you but the reason it needs root is because it needs to be able to edit apache/nginx config files, which anyone would need root permissions (either as root user or through running sudo) for to do. As for the rest, could you post the command you ran (with like example.com as domain name for security reasons)?

well when you use webroot you essentially have to put a file at a certain url (or let LE do that for you) and you should check whether you can access this url via browser, because if not webroot fails…

Thanks guys.

I have no public webserver running on this machine, I only want to use it to get certs.
I guess what I need to use is “manual” mode then. It was “hidden” away here:

I tried “certonly” but that one still wants to bind to port 80…

Thanks for the fast feedback.

I’m just using this machine to get certs, its firewalled and a ouside service wont be able to reach it.
I tried to use “certonly”, but that one still seems to try to bind to port 80.
(Guess it defaults back to the ‘standalone’ mode…)

I think “manual” mode is what I need, as described here:

But now I also see that 90 days is all I get? Thats kind of useless anyways, I can’t be doing a manual refresh of like 20 certs every 3 months and then move them to their target machines/services…

I guess I misunderstood this service (letsencrypt)… I have no need of any installer or automation, I just want to replace all my self signed with free certs.

The client is intended to streamline the process of proving ownership of the domain you are requesting the cert for. It would be irresponsible for LE to sign certificates for any domain. If your domain points to that VM you would need 443 open. If you don’t currently have a webserver on it you can use the clients webserver to handle LE’s challenge.

Let’s say you own example.com; LE could issue a challenge to you to serve a file at https://example.com/ABC containing 123 to prove this.

Well, what if as in my scenario, the domain points to a FTP-server? (On which I can't run the client).
Then I'm all out of luck?

This is why I want wildcard, then I could run the client on the webserver xyz.com, get the xyz.com wildcard cert, and then place the cert on the ftp.xyz.com-machine... (or on my mumble install, my router, my api-server, NAS, and so on...)

But as I said in earlier replies (Which doesn't show up, is there some sort of approval/moderation here?):
Since it seems to be only 90 days, it's useless anyways, I cant create & move around new certs every 90 days...
My hope was, since it's free, that I could request a 5 year (or ever more) cert...
(Or well, I guess LE have to follow the new 39 months rule..)

Guess I just have to stop being a cheap*ss and pay up for a 3 yr wildcard cert.

Just to make it clear (as I wrote on the other posts that disappeared):
I just want a free cert, no automation. But that seems really hard?

I think that "manual" mode is what I want to use?

I haven’t had a chance to do this yet but I plan to setup a cron job to get a cert out of their client (or maybe using something like https://github.com/diafygi/letsencrypt-nosudo) and then scp (or ftp) it to the server(s) that need it. Is it okay for your FTP server to run a webserver long enough for validation of your domain? Or can you have the FTP server forward all 443 traffic to another machine that can run one?

If you can only ever run an FTP server on your target machine; you could repoint the DNS record to a server you have full control over and have that machine forward all FTP traffic to your FTP server and handle the 443 https stuff. But this has a few big downsides: all FTP traffic will be proxied through the second server using its its bandwidth and creating another failure point…

Even if you pay for a cert, the certificate authority will have a process to verify domain ownership. Often they allow you to just add a DNS txt record.

LE does plan to implement verification by txt record: https://letsencrypt.org/howitworks/technology/

With alternative clients you don’t need root. But from what I understand having just set up a few LE certificates on a VPS, when verifying ownership of the domain Let’s Encrypt will look for certain challenge files served via HTTP on port 80 on the IP address that your domain resolves to. So beware of that. The official tool resolves this by modifying your config files or running a standalone webserver, both require root to achieve. With alternative clients you have a bit more control, but the process is still the same (having to serve challenge files on port 80 to verify domain ownership).

The alternative tools I used where letsencrypt-nosudo and acme-tiny (as the former doesn’t do automated renewals I also tried the latter, both work fine and are simple tools to use).

You don’t need root with the normal letsencrypt-auto if you just want to create a cert that you can manually install yourself. I have a very complicated setup where I didn’t want letsencrypt to touch any config at all, just to create the certs and I configure them myself. I did this without root using the following syntax (this can be on your local host or any server, doesn’t matter if its the one hosting the domain or not):
letsencrypt-auto certonly --manual -d foo.bar

This command will then stop and give you instructions for creating a file that should be served under the domain you want the cert for (it tells you the exact URL it wants the file at). You can then create that file in another shell or text editor and FTP or whatever you need. When the file is in place and accessible via the required URL, you go back to the shell where the letsencrypt command is running and hit ENTER, it will then create your certs in /etc/letsencrypt/live/DOMAIN/ and you can copy them onto your server.

I still think I need to use “manual” mode… Haven’t had time to try that one out.
I cant be installning/portforwarding port 80 and/or 443 to every machine/service/subdomain that I want a certificate for.

Best would have been a * cert, then I could just do the cert+renewal on the web-machine, and then just distribute to the target machines.
Guess that it might work with that option that would allow me to specify multiple subdomains, no idea how to do that tho.

Last time (like 4 months ago) i bought a cert from namecheap.com, all I had to do was to send a CSR from IIS 8, and for verification they sent me an email with a link/code to a “predifined” adress, I think it was webmaster@mydomain.com.

Why 90 days? Explained here
Seems like they will be keeping 90 days. I understand their point, but there’s not a chance in h*ll that I can go into the web-interface of the FTP-server (yeah, and every other service I run, and all the unsecure/selfsigned services I was thinking about fixing for my friends) and update the certs every 60-90 days :stuck_out_tongue:

I can just as well stop trying to “fix” this now, not a chance that I will take on the overhead / extra-point-of-failure of having to replace all certs every 90 days :stuck_out_tongue: That will cost way more time (=money) than to just buy 1,2 or 3 year certs :stuck_out_tongue: (I even think 3 years is too little, just give me a 100-year cert, fire-and-forget!!)

Gah this is like the biggest anticlimax of the year! letsencrypt was actually the coolest tech-thingy I looked forward to during 2015 but now it just totally derailed in a couple of minutes, haha.

Really appreciate your help guys, you saved me lots of time!
Take care, happy holidays! <3

Yeah, as @Aran explained it, thats how I expected it to work :stuck_out_tongue: The single method that makes MOST sense to a techie-guy, was the most well hidden one. But yeah, guess that has to do with the 90 days thingy, they want it to be automated. Too bad for every service except web-servers :stuck_out_tongue:

Actually the --manual method described above can work fine for renewal if the letsencrypt command is run on the same server so the certs can be directly referred to by the web-server (or via symlink). If the letsencrypt command is run on a regular basis, say monthy, then the certs will stay up to date.

1 Like

Yep, that's one method to verify ownership. LE doesn't support that method yet. Maybe later on in the beta process.

Very bad for security. What if someone owned chase.com (currently a domain of a very large major US bank) and got a 50 year certificate for it? Even after the bank owns the domain, that certificate is still valid. The holder of the certificate can now impersonate the current owner of chase.com.

All indications are that the CA/Browser Forum will restrict maximum lifetime even more in future revisions of their guidelines because of situations like this and the lingering SHA-1 certificate issues.

Just in case you don’t understand the short lifespan of the certificate yet, the reason is that shorter certificates allow them to be revoked sooner so that malicious use can be stopped sooner. The goal of LE is not just to supply free HTTPS access for everyone but to do it automatically without having to change the current system of authority trees. With an automatic distribution tool, there is no need for a long lifespan for the certificate.

So, to be clear, the current Beta should be an Alpha, since it doesn’t provide the envisioned automatic tools yet. You should not use LE at all for the situation where you wish to replace self-signed certificates in a real-world website, since the burden would be on you to renew your certificates manually. I don’t know why these facts are not currently made clear in the Beta announcement.

Im not talking about banks, or even production systems here.

I'm just tired of seeing the webbrowser warning about self signed certs in my hobby-projects. Where I dont want to spend lots of dollars, and take on lots of maintencene...
I just wanted free valid/green HTTPS (=encryption, not authentication) for my hobby projects :stuck_out_tongue:

Yeah, I get it. I guess it's not right for me then.
My question back to you: How do I automate the renewal every ~3 months for the certificate on my asus router? Or my ftp server? Or my mumble server? Plex server? NAS?
I can't clone the git-repo and run python or whatever on these devices :stuck_out_tongue:
Several of these machines are also firewalled/routed, without http/https port forwards... So even if I managed to run the LE software, I would still be out of luck since LE-servers wont be able to connect to them.

The problem with the whole "LE" ecosystem at the moment, is that the machine/service/whatever that needs the certificate, more or less has to be a linux-machine with ports open/forwarded to the Internets, right?

So more or less, LE is for webservers capable of running crontabbed custom scripts?

Yeah, the documentation is really bad at the moment.

Not sure why would you need certs from LE for machines not on the internet though. Self-signed fit the bill there.
Now 5 minutes for every machine every 3 months does not seem that much though.

They are connected to the internet, but only has ports for their respective services opened up (FTP and so on).
Also in lots of cases these ports are geo-ip blocked. On all those machines/firewalls, I would have to open up another port for the LE communication, right?

5 minutes? That depends, I'm the "go-to" it guy. Over the last 10 years, I have helped non-techie-friends set up at least 200 servers/services with self signed certs...
So I have to either teach them LE, or let them continue to run their (probably by now expired) self signed certs. Not a good solution, but a self signed cert is still better than running unencrypted in my opinion.

But no need to argue anymore. I stand corrected. You are right, I'm wrong.
I thought LE was meant to be an easy solution to secure all non-SSL machines, and/or replace self signed certs.
Not an improvement for the current cert-system.
You don't need to convince me. I just wanted an easy way to replace self-signed certs, and LE is not that solution for me.

As you are the “go-to” IT guy, if up for a little bit of script writing, then you could write a script for updating all those other devices ( FTP server, NAS etc). It’s what I’ve done. I have a main domain server that is openly accessible from the internet, can get certs for whatever sub domains I define for the internal devices. I can then copy those certs onto the various internal devices ( NAS etc) with a script. It just requires a little work on your side to set it up - as there is not an existing script that knows about all your equipment and your specific setup to do that.

Bassebus, “I thought LE was meant to be an easy solution to secure all non-SSL machines, and/or replace self signed certs. Not an improvement for the current cert-system.”

In a sense it is meant to be both. It will provide automatic security for the Web, something that could have been designed in it from the beginning but was not, because there were not very many malicious users in the beginning and also because run-time efficiency was more important with yesterday’s hardware and encryption software. It is about time that the current security system was improved.

“LE is not that solution for me.”

You are wrong. The current Beta release does not meet your needs. That is not the same thing. Just be patient, maybe continue to use self-signing or learn how to use the current clumsy LE, and wait until the developers finish the true Beta release, which will use Python or Go to automatically renew your certificates. This will be a universal solution, and will work as perfectly as software can get, but only you must be patient. Ignore the LE hype, that perhaps is coming a bit too early. Be patient and ignore LE until it is mature. Let the developers fix the problems, and keep the faith that LE will meet its promises. Technically, there is no obstacle to that. It only requires the patience of people trying it out too early. This should be considered an Alpha release instead of a Beta release. Okay?

this cannot be more wrong.

the short times allow them to expire sooner WITHOUT having to be revoked, especially since revocation checks arent mandatory by default, meaning a MITM cutting off the revocation check would have no problem of MITM'ing because the software doesnt care that the revocation check failed and just continues.

1 Like