]>
Commit | Line | Data |
---|---|---|
8c889e95 TL |
1 | [[sysadmin_certificate_management]] |
2 | Certificate Management | |
3 | ---------------------- | |
81b3c41f | 4 | |
8c889e95 TL |
5 | Access to the administration web-interface is always encrypted through `https`. |
6 | Each {pmg} host creates by default its own (self-signed) Certificate Authority | |
7 | (CA) and generates a certificate for the node which gets signed by the | |
8 | aforementioned CA. | |
9 | These certificates are used for encrypted communication with | |
10 | the cluster's `pmgproxy` service for any API call, between an user and the | |
11 | web-interface or between nodes in a cluster. | |
12 | ||
13 | [[sysadmin_certs_api_gui]] | |
14 | Certificates for the API and SMTP | |
15 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
16 | ||
17 | {pmg} knows two different certificates: | |
18 | ||
19 | * `/etc/pmg/pmg-api.pem`: the required certificate used for {pmg} API requests. | |
20 | * `/etc/pmg/pmg-tls.pem`: the optional certificate used for SMTP TLS | |
21 | connections, see xref:pmgconfig_mailproxy_tls[mailproxy TLS configuration] | |
22 | for details. | |
23 | ||
24 | You have the following options for those certificates: | |
25 | ||
26 | 1. keep using the default self-signed certificate in `/etc/pmg/pmg-api.pem`. | |
27 | 2. use an externally provided certificate (for example, signed by a commercial | |
28 | Certificate Authority (CA)). | |
29 | 3. use an ACME provider like Let's Encrypt to get a trusted certificate with | |
30 | automatic renewal, this is also integrated in the {pmg} API and Webinterface. | |
31 | ||
32 | Certificates are managed through the {pmg} web-interface/API or using the | |
33 | the `pmgconfig` CLI tool. | |
34 | ||
35 | [[sysadmin_certs_upload_custom]] | |
36 | Upload Custom Certificate | |
37 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
38 | ||
39 | If you already have a certificate which you want to use for a {pmg} host, you | |
40 | can upload that certificate simply over the web interface. | |
41 | ||
42 | [thumbnail="pmg-gui-certs-upload-custom.png"] | |
43 | ||
44 | Note that any certificates key file must not be password protected. | |
45 | ||
46 | [[sysadmin_certs_get_trusted_acme_cert]] | |
47 | Trusted certificates via Let's Encrypt (ACME) | |
48 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
49 | ||
50 | {PMG} includes an implementation of the **A**utomatic **C**ertificate | |
51 | **M**anagement **E**nvironment **ACME** protocol, allowing {pmg} admins to | |
52 | interface with Let's Encrypt for easy setup of trusted TLS certificates which | |
53 | are accepted out of the box on most modern operating systems and browsers. | |
54 | ||
55 | Currently the two ACME endpoints implemented are the | |
56 | https://letsencrypt.org[Let's Encrypt (LE)] production and its staging | |
57 | environment. Our ACME client supports validation of `http-01` challenges using | |
58 | a built-in webserver and validation of `dns-01` challenges using a DNS plugin | |
59 | supporting all the DNS API endpoints https://acme.sh[acme.sh] does. | |
60 | ||
61 | [[sysadmin_certs_acme_account]] | |
62 | ACME Account | |
63 | ^^^^^^^^^^^^ | |
64 | ||
65 | [thumbnail="pmg-gui-acme-create-account.png"] | |
66 | ||
67 | You need to register an ACME account per cluster with the endpoint you want to | |
68 | use. The email address used for that account will server as contact point for | |
69 | renewal-due or similar notifications from the ACME endpoint. | |
70 | ||
71 | You can register or deactivate ACME accounts over the web interface | |
72 | `Certificates -> ACME Accounts` or using the `pmgconfig` command line tool. | |
73 | ---- | |
74 | pmgconfig acme account register <account-name> <mail@example.com> | |
75 | ---- | |
76 | ||
77 | TIP: Because of https://letsencrypt.org/docs/rate-limits/[rate-limits] you | |
78 | should use LE `staging` for experiments or if you use ACME for the very first | |
79 | time until all is working there, and only then switch over to the production | |
80 | directory. | |
81 | ||
82 | [[sysadmin_certs_acme_plugins]] | |
83 | ACME Plugins | |
84 | ^^^^^^^^^^^^ | |
85 | ||
86 | The ACME plugins task is to provide automatic verification that you, and thus | |
87 | the {pmg} cluster under your operation, are the real owner of a domain. This is | |
88 | the basis building block for automatic certificate management. | |
89 | ||
90 | The ACME protocol specifies different types of challenges, for example the | |
91 | `http-01` where a webserver provides a file with a certain value to prove that | |
92 | it controls a domain. Sometimes this isn't possible, either because of | |
93 | technical limitations or if the address a domain points to is not reachable | |
94 | from the public internet. For such cases, one could use the `dns-01` challenge. | |
95 | This challenge also provides a certain value, but through a DNS record on the | |
96 | authority name server of the domain, rather than over a text file. | |
97 | ||
98 | [thumbnail="pmg-gui-acme-create-challenge-plugin.png"] | |
99 | ||
100 | {pve} supports both of those challenge types out of the box, you can configure | |
101 | plugins either over the web interface under `Datacenter -> ACME`, or using the | |
102 | `pvenode acme plugin add` command. | |
103 | ||
104 | ACME Plugin configurations are stored in `/etc/pve/priv/acme/plugins.cfg`. | |
105 | A plugin is available for all nodes in the cluster. | |
106 | ||
107 | Domains | |
108 | ^^^^^^^ | |
109 | ||
110 | You can add new or manage existing domain entries under `Certificates`, or | |
111 | using the `pmgconfig` command. | |
112 | ||
113 | [thumbnail="pmg-gui-acme-add-domain.png"] | |
114 | ||
115 | After configuring the desired domain(s) for a node and ensuring that the | |
116 | desired ACME account is selected, you can order your new certificate over the | |
117 | web-interface. On success the interface will reload after circa 10 seconds. | |
118 | ||
119 | Renewal will happen xref:sysadmin_certs_acme_automatic_renewal[automatically]. | |
120 | ||
121 | [[sysadmin_certs_acme_http_challenge]] | |
122 | ACME HTTP Challenge Plugin | |
123 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
124 | ||
125 | There is always an implicitly configured `standalone` plugin for validating | |
126 | `http-01` challenges via the built-in webserver spawned on port 80. | |
127 | ||
128 | NOTE: The name `standalone` means that it can provide the validation on it's | |
129 | own, without any third party service. So, this plugin works also for cluster | |
130 | nodes. | |
131 | ||
132 | There are a few prerequisites to use it for certificate management with Let's | |
133 | Encrypts ACME. | |
134 | ||
135 | * You have to accept the ToS of Let's Encrypt to register an account. | |
136 | * **Port 80** of the node needs to be reachable from the internet. | |
137 | * There **must** be no other listener on port 80. | |
138 | * The requested (sub)domain needs to resolve to a public IP of the {pmg} host. | |
139 | ||
140 | ||
141 | [[sysadmin_certs_acme_dns_challenge]] | |
142 | ACME DNS API Challenge Plugin | |
143 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
144 | ||
145 | On systems where external access for validation via the `http-01` method is | |
146 | not possible or desired, it is possible to use the `dns-01` validation method. | |
147 | This validation method requires a DNS server that allows provisioning of `TXT` | |
148 | records via an API. | |
149 | ||
150 | [[sysadmin_certs_acme_dns_api_config]] | |
151 | Configuring ACME DNS APIs for validation | |
152 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
153 | ||
154 | {PVE} re-uses the DNS plugins developed for the `acme.sh` | |
155 | footnote:[acme.sh https://github.com/acmesh-official/acme.sh] | |
156 | project, please refer to its documentation for details on configuration of | |
157 | specific APIs. | |
158 | ||
159 | The easiest way to configure a new plugin with the DNS API is using the web | |
160 | interface (`Certificates -> ACME Accounts/Challenges`). | |
161 | ||
162 | [thumbnail="pmg-gui-acme-create-challenge-plugin.png"] | |
163 | ||
164 | Add a new challenge plugin, here you can select your API provider, enter the | |
165 | credential data to access your account over their API. | |
166 | ||
167 | TIP: See the acme.sh | |
168 | https://github.com/acmesh-official/acme.sh/wiki/dnsapi#how-to-use-dns-api[How to use DNS API] | |
169 | wiki for more detailed information about getting API credentials for your | |
170 | provider. Configuration values do not need to be quoted with single or double | |
171 | quotes, for some plugins that is even an error. | |
172 | ||
173 | As there are many DNS providers and API endpoints {pmg} autogenerates the form | |
174 | for the credentials, but not all providers are annotated yet. For those you | |
175 | will see a bigger text area, simply copy all the credentials `KEY`=`VALUE` | |
176 | pairs in there. | |
177 | ||
178 | DNS Validation through CNAME Alias | |
179 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
180 | ||
181 | A special `alias` mode can be used to handle the validation on a different | |
182 | domain/DNS server, in case your primary/real DNS does not support provisioning | |
183 | via an API. Manually set up a permanent `CNAME` record for | |
184 | `_acme-challenge.domain1.example` pointing to `_acme-challenge.domain2.example` | |
185 | and set the `alias` property in the {pmg} node configuration file | |
186 | `/etc/pmg/node.conf` to `domain2.example` to allow the DNS server of | |
187 | `domain2.example` to validate all challenges for `domain1.example`. | |
188 | ||
189 | ||
190 | Combination of Plugins | |
191 | ^^^^^^^^^^^^^^^^^^^^^^ | |
192 | ||
193 | Combining `http-01` and `dns-01` validation is possible in case your node is | |
194 | reachable via multiple domains with different requirements / DNS provisioning | |
195 | capabilities. Mixing DNS APIs from multiple providers or instances is also | |
196 | possible by specifying different plugin instances per domain. | |
197 | ||
198 | TIP: Accessing the same service over multiple domains increases complexity and | |
199 | should be avoided if possible. | |
200 | ||
201 | [[sysadmin_certs_acme_automatic_renewal]] | |
202 | Automatic renewal of ACME certificates | |
203 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
204 | ||
205 | If a node has been successfully configured with an ACME-provided certificate | |
206 | (either via pmgconfig or via the web-interface/API), the certificate will be | |
207 | automatically renewed by the `pmg-daily.service`. Currently, renewal is | |
208 | triggered if the certificate either already expired or if it will expire in the | |
209 | next 30 days. | |
210 | ||
211 | Manually Change Certificate over Command-Line | |
212 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
81b3c41f DM |
213 | |
214 | If you want to get rid of these warnings, you have to generate a valid | |
215 | certificate for your server. | |
216 | ||
f7198e12 | 217 | Login to your {pmg} via ssh or use the console: |
81b3c41f DM |
218 | |
219 | ---- | |
220 | openssl req -newkey rsa:2048 -nodes -keyout key.pem -out req.pem | |
221 | ---- | |
222 | ||
223 | Follow the instructions on the screen, see this example: | |
224 | ||
225 | ---- | |
226 | Country Name (2 letter code) [AU]: AT | |
227 | State or Province Name (full name) [Some-State]:Vienna | |
228 | Locality Name (eg, city) []:Vienna | |
229 | Organization Name (eg, company) [Internet Widgits Pty Ltd]: Proxmox GmbH | |
230 | Organizational Unit Name (eg, section) []:Proxmox Mail Gateway | |
231 | Common Name (eg, YOUR name) []: yourproxmox.yourdomain.com | |
232 | Email Address []:support@yourdomain.com | |
233 | ||
234 | Please enter the following 'extra' attributes to be sent with your certificate request | |
235 | A challenge password []: not necessary | |
236 | An optional company name []: not necessary | |
237 | ---- | |
238 | ||
239 | After you finished this certificate request you have to send the file | |
240 | `req.pem` to your Certification Authority (CA). The CA will issue the | |
241 | certificate (BASE64 encoded) based on your request – save this file as | |
f7198e12 | 242 | `cert.pem` to your {pmg}. |
81b3c41f | 243 | |
f7198e12 | 244 | To activate the new certificate, do the following on your {pmg}: |
81b3c41f DM |
245 | |
246 | ---- | |
247 | cat key.pem cert.pem >/etc/pmg/pmg-api.pem | |
248 | ---- | |
249 | ||
f7198e12 | 250 | Then restart the API servers: |
81b3c41f DM |
251 | |
252 | ---- | |
253 | systemctl restart pmgproxy | |
254 | ---- | |
255 | ||
256 | Test your new certificate by using your browser. | |
257 | ||
8c889e95 TL |
258 | NOTE: To transfer files from and to your {pmg}, you can use secure copy: If you |
259 | desktop is Linux, you can use the `scp` command line tool. If your desktop PC | |
260 | is windows, please use a scp client like WinSCP (see https://winscp.net/). | |
0fe083dc DM |
261 | |
262 | Change Certificate for Cluster Setups | |
263 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
264 | ||
8c889e95 TL |
265 | If you change the API certificate of an active cluster node manually, you also |
266 | need to update the pinned fingerprint inside the cluster configuration. | |
0fe083dc | 267 | |
8c889e95 TL |
268 | You can do that by executing the following command on the host where the |
269 | certificate changed: | |
0fe083dc DM |
270 | |
271 | ---- | |
8c889e95 | 272 | pmgcm update-fingerprints |
0fe083dc | 273 | ---- |
8c889e95 TL |
274 | |
275 | Note, this will be done automatically if using the integrated ACME (for | |
276 | example, through Let's Encrypt) feature. |