search

will-in-wi / letsencrypt-webfaction

LetsEncrypt utility client for WebFaction hosts.
MIT License
350 stars 27 forks source link

Testing v.3, at the crossroads #153

Closed wion closed 6 years ago

wion commented 6 years ago

Hi,

Context: I originally started using LE on WF manually with Neil Pang's great acme.sh shell some time back. Not exactly designed for WF, I then tried Greg Brown's python script method (but also just manually with that, no cron) because it seems to work in relation to Pang's acme.sh a bit. Now I tried to renew expired certs again and and can't get any of it to work. The point of mentioning all that is I have a ~/certificates directory full of old expired certs and perhaps some old script files sitting around that might need removed.

Also, I am not a dev by any means and need dummy-level 1, 2, 3 steps, but can make my way through things okay if I have them. ;)

On to the current situation...

I've walked through the initial steps of the ReadMe. I was confused by some of the comments/examples in the default config, but I think I have it in order now and set for testing.

First, you might want to add some clarifier in the docs about what the difference between init and run is, and whether one needs to use both at the same time, because I don't know there. I'm just trying them both together, and you can see the output result here:

letsencrypt_webfaction init run
Config file already exists. Skipping copy...
Account private key already exists. Skipping generation...
Your system is set up. Next, edit the config file: run `nano ~/letsencrypt_webfaction.toml`.

As you can see, it's routing me back to the config, which I thought I had setup already.

One thing I am doing in the config is using an old certificate name= in the dashboard, which of course would be populated with a cert from an old method. I'm guessing that's the problem here.

How should I proceed to create new certs and clear out the old files?

will-in-wi commented 6 years ago

First, you might want to add some clarifier in the docs about what the difference between init and run is, and whether one needs to use both at the same time […]

init generates a registration cert and the config file. Once you have run this, you then edit your configuration file. init should be run only once.

run actually does the work of creating certificates. You run this roughly daily (in Cron) to check for which certs need to be issued and renewed and do so.

So, since you've run the init command, you should only need to execute the run command. init run ignores the second param and just inits.

One thing I am doing in the config is using an old certificate name= in the dashboard, which of course would be populated with a cert from an old method. I'm guessing that's the problem here.

If you point to an old name it will check the currently installed certificate's expiration date and issue a new one when it is less than 30 days from expiration. So this should be fine.

How should I proceed to create new certs and clear out the old files?

Pretty much as you are doing, except use just the run command without init. Feel free to reuse name= entries, it'll continue to use your old certificates until they are about to expire then replace them with new ones.

wion commented 6 years ago

Thanks for the clarification on init and run. And apologies, I now see you did detail those a bit. I was focusing on the Usage section.

I ran a test and have mostly good results, I think, but still one snafu.

I'm using a sites list in the config to designate where the cert should be applied:

domains = [
  "domain.tld",
  "www.domain.tld",
  "sub1.domain.tld",
  "www.sub1.domain.tld",
  "sub2.domain.tld",
  "www.sub2.domain.tld"
]

(I like Class B, no 'www' URLs, and even though mod_rewrite rules in .htaccess are set for redirecting, I still need to create websites for those in WebFaction, dashboard, apparently. So I'm just listing sites by that logic here. Not sure that's right though.)

When I run the test, I get a Success in command-line output on the last four, but the first two (the common domain pair) give me a problem:

Failed to verify statuses.
domain.tld: Invalid response from http://domain.tld/.well-known/acme-challenge/37xQm4AkKwxGuopXyPTxe0kOHpm79b1o3JVVUJlGQJs: "
<html class="no-js" lang="en">
<head>
<title>Site Name: 503 Service Unavailable</title>
<!-- METADATA LINKS -->
<meta http-"
Make sure that you can access http://domain.tld/.well-known/acme-challenge/37xQm4AkKwxGuopXyPTxe0kOHpm79b1o3JVVUJlGQJs

www.domain.tld: Invalid response from http://www.domain.tld/.well-known/acme-challenge/9_a8HpzMJ2HaPyDMVqfTGMY6uPVluvIRlK7KBhcepXw: "
<html class="no-js" lang="en">
<head>
<title>Site Name: 503 Service Unavailable</title>
<!-- METADATA LINKS -->
<meta http-"
Make sure that you can access http://www.domain.tld/.well-known/acme-challenge/9_a8HpzMJ2HaPyDMVqfTGMY6uPVluvIRlK7KBhcepXw

I do happen to have that site (a site running Textpattern CMS) under a 503 'under construction' status using a plugin for that function. Could it be that I need to turn that plugin off during renewals and run the test again? Or is this a problem somewhere else?

Thanks for the time and insight.

will-in-wi commented 6 years ago

This is where things get tricky since it is so dependent on your setup.

Using the last error as an example, for Let's Encrypt to validate the domain www.domain.tld, it needs to put a file on the filesystem and access it remotely. In this case, it's trying to access it at http://www.domain.tld/.well-known/acme-challenge/9_a8HpzMJ2HaPyDMVqfTGMY6uPVluvIRlK7KBhcepXw.

Since Textpattern is intercepting that and returning a 503, Let's Encrypt cannot verify ownership, and fails. You will need to find a way to have Textpattern not intercept requests to .well-known. I would guess that they have a default .htaccess which routes all requests to them, and which you might be able to modify to add an exception.

will-in-wi commented 6 years ago

Doing some testing with the default Textpattern .htaccess found here: https://github.com/textpattern/textpattern/blob/dev/.htaccess, it seems like it should work…

wion commented 6 years ago

Found the problem. Silly mistake on my part. I entered the wrong webapp name for that site in the config list.

Just waiting for the changes to propagate now, which hasn't happened yet. Any insights on how long that should take, in case I should worry it's some other problem?

In any case, thanks for the help on this. I haven't tried setting up the Cron renewal yet, but I'll open a new ticket if that's a problem.

Cheers!

will-in-wi commented 6 years ago

Wonderful, glad to hear you found the issue! I generally just go get coffee (or start working on something else) when I'm waiting for change propagation. Maybe 5 minutes?

wion commented 6 years ago

Hmm... Okay, well it's been 2 hours now and encryption still isn't working even though it looks okay in the dashboard side. I'll have to open a WF ticket, I guess.

But, if I may quickly ask about the crontab, which I've never used before in my life...

My default crontab has the following, where 'username' is my WF username:

0 0 * * * "/home/username/.acme.sh"/acme.sh --cron --home "/home/username/.acme.sh" > /dev/null

I'm assuming I just leave that 'job' alone and create a new one underneath, like this?

0 0 * * * "/home/username/.acme.sh"/acme.sh --cron --home "/home/username/.acme.sh" > /dev/null

18 3 * * *     PATH=$PATH:$GEM_HOME/bin:/usr/local/bin GEM_HOME=$HOME/.letsencrypt_webfaction/gems RUBYLIB=$GEM_HOME/lib ruby2.2 $HOME/.letsencrypt_webfaction/gems/bin/letsencrypt_webfaction run --quiet

Do I add the blank line between them like that, or does it matter?

Also, I realize 18 3 * * * must be how to set the time, but I dont' grasp the pattern. What if I wanted the job to run, for example, every 85 days at 02:53; how would that look?

ElectricFeet commented 6 years ago

85 days is problematic. You need to make it calendar based. Every 2 months works well. This site helps you get the format. I've set the link to give you 02:53 on the 8th of every 2nd month.

ElectricFeet commented 6 years ago

(and blank lines in Cron are fine)

jools-r commented 6 years ago

The first line looks like the cron job from the acme.sh script you were using before for the certificates. You probably want to disable / comment that one out if you're now using this script.

wion commented 6 years ago

@ElectricFeet

That site is pretty cool. Thank you for the tips.

@jools-r

I was wondering about that. It must have been added automatically way back when using Pang's shell. I certainly don't remember adding it myself.

Another observation I just made, I don't have this uncommented in the config file:

# Right now, only http01 is available. This is the default.
#method = "http01"

Is that second line supposed to be uncommented?

wion commented 6 years ago

Hmm... in this example, it looks like you DO NOT uncomment all the default config values (such as #method = "http01"). Is that correct? I should NOT uncomment those?

The one I did uncomment was the name of the existing cert in the WF dashboard, because I changed that from the default config value:

name = "domain_ssl"

It seemed to work, though, because that cert was updated in the dashboard.

will-in-wi commented 6 years ago

Goodness, I leave for a couple of hours and everyone is here being super helpful to each other. Thanks all! You guys make this a great community and a pleasure to be a part of it.

@wion You can leave the method line commented. It is http01 by default (and right now that's the only method that is supported). I added it mostly for when later I work on dns01 validation and wildcard certificates.

will-in-wi commented 6 years ago

One other note about frequency: Versions 1 and 2 did indeed need every two month renewal, since they renewed the certificate every time it ran.

Version 3 only renews the certificate if it is fewer than 30 days from expiration. So it's probably a good idea to run that every couple of days. You could run it as frequently as nightly or as infrequently as every 4 days. I probably wouldn't run it less frequently than that.

wion commented 6 years ago

Thanks for the explanation about the cron. I don't know how to make the 'every 2 days' declaration so I just used 06:53 every day: 53 6 * * *.

will-in-wi commented 6 years ago

Every day works fine. If you wanted to do every other day at that time, you could do something like this: 53 6 */2 * *.

Cron syntax is quite obtuse… I wish there were a more user friendly way of handling this.

wion commented 6 years ago

Thanks again. (Agree about cron. Yipes.)

So one last status update, but I am going to a WF support ticket at this point, because I think I've done all I can and should do at this end.

I realized that when I tried running the production command the first time, I forgot to add the --force param. After fixing the webapp name I flubbed in the sites list in config and running the cert again using --force, the domain that didn't work before worked as expected, but I got the same /.well-known/ error for one of the other subdomains, which I didn't get the first time. Huh. Double checking the name there, it's correct, so I'm not sure why that suddenly started happening.

In any case, I'm sure it's human error on my part somewhere (setup in WF dashboard is not the most straightforward process, IMO) and just a matter of triple-quadruple checking everything.

will-in-wi commented 6 years ago

Sounds good. I hope that WF support can help with getting those details hammered out.