lecli 0.2.4 → 0.2.5
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile.lock +1 -1
- data/README.md +8 -8
- data/exe/lecli +2 -3
- data/lib/lecli/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA1:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: d065e1b5b0ba66e69cd54f86d3a13576eac41291
|
|
4
|
+
data.tar.gz: 3e65138be288b57f3013ba55dc2f543080d155f0
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 876972f3c6a052937d54d668f128505e13319b3bc3949f971596d86cdf45a8486c0cd60a53dcd403967767155a9c13b1ae4944d3dd3102bed4e6341330a9fe0a
|
|
7
|
+
data.tar.gz: 4621de3585faac585485ad38a8f164f4112b8c42e5925a898f2f9d43fb1351c26e37b3b80d05c34c305ed7747a0d8be9bb6879a8e78bb8c635fd782f03ceef85
|
data/Gemfile.lock
CHANGED
data/README.md
CHANGED
|
@@ -30,21 +30,21 @@ challenges_relative_path: challenges
|
|
|
30
30
|
success_callback_script: deploy.sh
|
|
31
31
|
```
|
|
32
32
|
|
|
33
|
-
Most entries are optional, except those that specify the domains
|
|
33
|
+
Most entries are optional, except those that specify the request domains and "identity fields". Meaning that at least **domains** (list of domains), **common_name** (your company/name) and **account_email** should always appear in order to perform a valid request.
|
|
34
34
|
|
|
35
35
|
### The flow
|
|
36
36
|
|
|
37
|
-
From the two available types of validation requests only HTTP (and not DNS) is supported [yet](#contributing). This means you'll need to serve a token (lecli will create them) behind each domain in the **list of domain addresses** requested
|
|
37
|
+
From the two available types of validation requests only HTTP (and not DNS) is supported [yet](#contributing). This means you'll need to serve a token (lecli will create them) behind each domain in the **list of domain addresses** requested.
|
|
38
38
|
|
|
39
|
-
The tokens are written to
|
|
39
|
+
The tokens are written to **challenges_relative_path** and need to be served behind each domain you are requesting, i.e. `example.com/.well-known/acme-challenge/#{token_filename}` needs to return the token. If requesting multiple domains at once you will need additional setup to route from each domain requested to where the tokens are persisted. When working with a single domain, for example, you can just make this relative path write the tokens on `/usr/share/nginx/html/.well-known/acme-challenge/` if working with an nginx server.
|
|
40
40
|
|
|
41
41
|
|
|
42
42
|
|
|
43
|
-
After Let's Encrypt is able to access both tokens on the list of domain addresses requested the certificates can be issued. The resulting certificate will be identified by the **email** and under the **common_name** provided. The
|
|
43
|
+
After Let's Encrypt is able to access both tokens on the list of domain addresses requested the certificates can be issued. The resulting certificate will be identified by the **email** and under the **common_name** provided. The certificates (`.pem` files) can be renamed with **request_key** and **certificate_key**.
|
|
44
44
|
|
|
45
|
-
Optionally you can specify a script
|
|
45
|
+
Optionally you can specify a script with **success_callback_script** to be executed. This script will function as a "callback hook" and it will run after successfully exporting the domains' certificate.
|
|
46
46
|
|
|
47
|
-
|
|
47
|
+
Now you've read about `lecli.yml` options available (keywords in **bold**). If you've made sure to: (1) Customized the options config file to create the desired certificate, and (2) made sure the **challenges_relative_path** path is available for a public internet request, then you're now ready to kick off the validation process by executing the following on your terminal
|
|
48
48
|
|
|
49
49
|
```
|
|
50
50
|
lecli generate
|
|
@@ -66,9 +66,9 @@ server {
|
|
|
66
66
|
}
|
|
67
67
|
```
|
|
68
68
|
|
|
69
|
-
You can script a server restart if needed, or any other setup that you require to make use of the newly created certificates. Just make sure to point the **success_callback_script** path in your config file so the CLI can automatically execute it if the request result was
|
|
69
|
+
You can script a server restart if needed, or any other setup that you require to make use of the newly created certificates. Just make sure to point the **success_callback_script** path in your config file (and the script is 'executable') so the CLI can automatically execute it if the request result was successful.
|
|
70
70
|
|
|
71
|
-
If you pair the CLI with a cron-job (specially using the [whenever](https://github.com/javan/whenever) gem) you've essentially put together a Let's Encrypt bot and can now leverage scripting for complex deployments. Your certificates will be renewed periodically. When using **whenever** you'll have lecli CLI in your crontab as easy as:
|
|
71
|
+
If you pair the CLI with a cron-job (specially using the [whenever](https://github.com/javan/whenever) gem) you've essentially put together a Let's Encrypt bot and can now leverage scripting for more complex deployments. Your certificates will be renewed periodically. When using **whenever** you'll have lecli CLI in your crontab as easy as:
|
|
72
72
|
|
|
73
73
|
```
|
|
74
74
|
every :month, at: '4am' do
|
data/exe/lecli
CHANGED
|
@@ -32,9 +32,8 @@ class LECLIRunner < Thor
|
|
|
32
32
|
aliases: [:f],
|
|
33
33
|
desc: 'Specify the path of the configuration file.'
|
|
34
34
|
def generate
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
opts = LECLI::CertificateBuilder.load_options(config_file: config_file)
|
|
35
|
+
config_path = options[:config_file]
|
|
36
|
+
opts = LECLI::CertificateBuilder.load_options(config_file: config_path)
|
|
38
37
|
if opts.nil? # Bail if options can't be loaded properly
|
|
39
38
|
puts 'Unable to locate .lecli.yml file. Try `lecli help generate`'
|
|
40
39
|
return
|
data/lib/lecli/version.rb
CHANGED