You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guides/ssl/automatic-renewal.md
+29-10Lines changed: 29 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,74 +12,87 @@ This guide uses:
12
12
13
13
## Prerequisites
14
14
15
-
-**Pi-hole installed and running** on your system.
16
-
-**A Cloudflare account** that manages your domain’s DNS records.
17
-
-**Control of a registered domain** (e.g., `mydomain.com`).
15
+
-**Pi-hole installed and running** on your system.
16
+
-**A Cloudflare account** that manages your domain's DNS records.
17
+
-**Control of a registered domain** (e.g., `mydomain.com`).
18
18
19
19
These prerequisites ensure that you can successfully request and install an SSL certificate using **Cloudflare DNS validation** with `acme.sh`.
20
-
This guide uses **Cloudflare DNS** and **Let’s Encrypt**. These instructions can be adapted for any DNS provider and Certificate Authority (CA) that `acme.sh` supports. Simply update the `--dns` and `--server` flags accordingly when issuing your certificate.
20
+
21
+
This guide uses **Cloudflare DNS** and **Let's Encrypt**. These instructions can be adapted for any DNS provider and Certificate Authority (CA) that `acme.sh` supports. Simply update the `--dns` and `--server` flags accordingly when issuing your certificate.
21
22
22
23
**Note:** This guide assumes that `acme.sh` runs under the `root` user. The `--reloadcmd` contains commands that require `sudo`, such as removing old certificates, writing the new certificate, and restarting Pi-hole FTL. If you prefer to run `acme.sh` as a regular user, additional configuration is required to allow these commands to execute without a password. Methods for achieving this, such as configuring `sudo` rules, are beyond the scope of this article.
-`openssl` is installed on the same machine that Pi-hole is installed on, but this is not a requirement -
19
+
-`openssl` is installed on the same machine that Pi-hole is installed on, but this is not a requirement -
19
20
`openssl` can be installed on a machine that is not running Pi-hole; `tls.pem` just needs to be copied to `/etc/pihole` on the target mahcine running Pi-hole.
20
21
- All shell commands are executed from the home directory (e.g., `/home/your_user` or `~/`).
21
22
22
23
---
24
+
23
25
## Method 1: Use an Internal Certificate Authority CA (Recommended)
26
+
24
27
- Pros: All future certificates are trusted once you install the CA cert.
25
28
- Cons: Requires setting up a CA.
26
29
27
30
**Summary:** Set up a CA, sign certificates for each server, and install only one CA certificate instead of trusting multiple self-signed certificates.
28
31
29
32
### Step 1: Create a directory to hold your cert, config, and key files:
30
-
```
33
+
34
+
```bash
31
35
mkdir -p ~/crt &&cd~/crt
32
36
```
33
37
34
38
### Step 2: Create a Certificate Authority (CA) Key and Certificate
@@ -54,11 +59,12 @@ The **CA key** (homelabCA.key) and **CA certificate** (homelabCA.crt) is now rea
54
59
55
60
### Step 3: Create a Certificate Configuration File (`cert.cnf`)
56
61
57
-
```
62
+
```bash
58
63
touch cert.cnf && nano cert.cnf
59
64
```
60
65
61
66
Use the attached [cert.cnf](https://gist.github.com/kaczmar2/e1b5eb635c1a1e792faf36508c5698ee#file-cert-cnf) file as a template:
67
+
62
68
```ini
63
69
# Country Name (C)
64
70
#Organization Name (O)
@@ -93,9 +99,11 @@ IP.2 = 10.10.10.116 # Another local IP if needed
93
99
### Step 4: Generate a Key and CSR
94
100
95
101
Use **Elliptic Curve Digital Signature Algorithm (ECDSA)** to generate both the **private key** (`tls.key`) and **Certificate Signing Request (CSR)** (`tls.csr`).
### Issuing additional server certificates with your CA (Optional)
148
-
You can issue additional certificates for your other servers using the CA you created in **step 2**, and you do not have to re-install the CA certificate in your browser.
164
+
165
+
You can issue additional certificates for your other servers using the CA you created in **step 2**, and you do not have to re-install the CA certificate in your browser.
149
166
Just run the commands listed in **steps 4 and 5** again:
## Method 2: Use a Self-Signed Certificate and Manually Trust It
179
+
161
180
- Pros: Simple, no need to set up a CA.
162
181
- Cons: Must manually add each self-signed cert to your browser.
163
182
164
183
**Summary:** Generate a self-signed certificate and install it in your browser. You must manually trust each certificate, so this is adequate for a single server setup.
165
184
166
185
### Step 1: Create a directory to hold your cert, config, and key files:
167
-
```
186
+
187
+
```bash
168
188
mkdir -p ~/crt &&cd~/crt
169
189
```
170
190
171
191
### Step 2: Create a Certificate Configuration File (`cert.cnf`)
172
192
173
-
```
193
+
```bash
174
194
touch cert.cnf && nano cert.cnf
175
195
```
176
196
177
197
Use the attached [cert.cnf](https://gist.github.com/kaczmar2/e1b5eb635c1a1e792faf36508c5698ee#file-cert-cnf) file as a template:
198
+
178
199
```ini
179
200
# Country Name (C)
180
201
#Organization Name (O)
@@ -207,10 +228,11 @@ IP.2 = 10.10.10.116 # Another local IP if needed
207
228
```
208
229
209
230
### Step 3: Generate a key and Self-Signed Certificate
210
-
Use **Elliptic Curve Digital Signature Algorithm (ECDSA)** to generate both the **private key** (`tls.key`) and the **Self-Signed Certificate** (`tls.crt`).
Use **Elliptic Curve Digital Signature Algorithm (ECDSA)** to generate both the **private key** (`tls.key`) and the **Self-Signed Certificate** (`tls.crt`).
0 commit comments