1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Letsencrypt
===========
A module for configuring certificates from letsencrypt (or other ACME
providers), and deploying them.
Table of Contents
-----------------
1. [Why](#why)
2. [Usage](#usage)
1. [Examples](#examples)
2. [Authenticators](#authenticators)
3. [Facts](#facts)
3. [Restrictions](#restrictions)
3. [Other Stuff](#other-stuff)
Why
---
Why this module instead of [puppet/letsencrypt][2]? Setting up certificates on
existing infrastructure with that module isn't a problem. However, bootstraping
new servers is a problem, since one usually wants to write a complete server
configuration (for nginx (or similar)) at the beginning, but letsencrypt
requires a working webserver to authenticate. This module solves that (see
[Server Integration](#Server Integration)).
This module also allows multiple domains to be added to a single certificate one
by one, instead of requiring them all to be pre-determined.
Usage
-----
### Examples
For basic usage, include `letsencrypt`, and define `letsencrypt::cert`
resources.
```puppet
include ::letsencrypt
letsencrypt::cert { 'example.com':
include_self => true,
authenticator => 'nginx',
}
```
Each certificate can have its own authenticator and configuration, allowing
multiple different setups to co-exist.
#### Server Integration
A number of functions are available for easy integration with different
web servers (currently only nginx). These procedures expand to a correct ssl
configuration if the wanted certificate is available, or to `ssl => false` (or
similar) if it isn't. This allows efficient bootstrapping.
The following example would configure an ngnix server without SSL on its first
run, but configure a server with ssl on future runs (since the certificate will
be generated by then).
```puppet
nginx::resource::server { 'example.com':
* => letsencrypt::conf::nginx('example.com'),
}
```
It's recommended to reload to add a post-hook to `letsencrypt::cert` which
reloads your server configuration. This won't allow SSL to get configured on the
first run, but is usually needed when a certificate gets renewed.
```
letsencrypt::cert { 'example.com':
# [...]
config => {
'post-hook' => 'nginx -s reload',
},
}
```
#### Extra Domains
Additional domain names can later be added to a given certificate.
```puppet
letsencrypt::domain { 'subdomain.example.com':
cert_name => 'example.com',
}
```
This is for example useful if you have a profile which sets up a certificate
with the hosts fully qualified domain name as its name, and each other profile
registering domains to that certificate.
### Authenticators
Each certificate needs to be authenticated, this has no relation to where the
certificate is used, even though the usual configuration uses the certificates
on the same web server which was used for authentication. Currently only nginx
is supported.
### Facter Facts
#### `letsencrypt_bycertname`
A hash from each certificates locally chosen name, to its directory in the
letsencrypt live directory. The actual directory name [may have extra numbers on
its end]. This fact strips them to allow one to check if a given certificate is
loaded.
#### `letsencrypt_directory`
A hash from each domain name which has a certificate, to its directory in
letsencrypts live directory.
`"${letsencrypt_directory['example.com']}/fullchain.pem"` or similar is probably
what you want.
Restrictions
------------
Currently only nginx is supported. In the future, at least the following should
be supported:
- Apache2 authenticator
- Apache2 configuration function
- Route53 authenticator
The letsencrypt directories aren't cleaned up if certificates is no longer
managed.
The module doesn't notice if the authenticator service changes, meaning that old
certificates will need to be removed by hand.
Other Stuff
-----------
When debugging locally, configuration files will be placed in
`/etc/letsencrypt`. Letsencrypt stores its debug logs to
`/var/log/letsencrypt/letsencrypt.log`.
[1]: https://eff-certbot.readthedocs.io/en/stable/using.html#where-are-my-certificates
[2]: https://forge.puppet.com/modules/puppet/letsencrypt
|
