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/integrating-cert-manager.md
+10-4Lines changed: 10 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ This guide will demonstrate how to:
17
17
18
18
1. Administrator access to a Kubernetes cluster is required.
19
19
2.[Helm](https://helm.sh) and [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) must be installed locally.
20
-
3. Deploy NGINX Kubernetes Gateway (NKG) following the [deployment instructions](../installation.md).
20
+
3. Deploy NGINX Kubernetes Gateway (NKG) following the [deployment instructions](/docs/installation.md).
21
21
4. A DNS resolvable domain name is required. It must resolve to the public endpoint of the NKG deployment, and this
22
22
public endpoint must be an external IP address or alias accessible over the internet. The process here will depend
23
23
on your DNS provider. This DNS name will need to be resolvable from the Let’s Encrypt servers, which may require
@@ -28,7 +28,7 @@ This guide will demonstrate how to:
28
28

29
29
30
30
The diagram above shows a simplified representation of the cert-manager ACME Challenge and certificate issuance process
31
-
using Gateway API. Please note not all of the Kubernetes objects created in this process are represented in
31
+
using Gateway API. Please note that not all of the Kubernetes objects created in this process are represented in
32
32
this diagram.
33
33
34
34
At a high level, the process looks like this:
@@ -149,7 +149,7 @@ It's worth noting a couple of key details in this manifest:
149
149
150
150
- The cert-manager annotation is present in the metadata – this enables the cert-manager integration, and tells
151
151
cert-manager which ClusterIssuer configuration it should use for the certificates.
152
-
- There are two Listeners configured, a http Listener on port 80, and a https Listener on port 443.
152
+
- There are two Listeners configured, an HTTP Listener on port 80, and an HTTPS Listener on port 443.
153
153
- The http Listener on port 80 is required for the HTTP01 ACME challenge to work. This is because as part of the
154
154
HTTP01 Challenge, a temporary HTTPRoute will be created by cert-manager to solve the ACME challenge, and this
155
155
HTTPRoute requires a Listener on port 80. See the [HTTP01 Gateway API solver documentation](https://cert-manager.io/docs/configuration/acme/http01/#configuring-the-http-01-gateway-api-solver)
@@ -165,7 +165,10 @@ been created successfully using `kubectl`. Note it will take a little bit of tim
165
165
Secret to be created:
166
166
167
167
```shell
168
-
❯ kubectl get secret cafe-secret
168
+
kubectl get secret cafe-secret
169
+
```
170
+
171
+
```shell
169
172
NAME TYPE DATA AGE
170
173
cafe-secret kubernetes.io/tls 2 20s
171
174
```
@@ -241,6 +244,9 @@ presented certificate. The output will look something like this:
241
244
242
245
```shell
243
246
curl https://cafe.example.com/coffee -v
247
+
```
248
+
249
+
```shell
244
250
* Trying 54.195.47.105:443...
245
251
* Connected to cafe.example.com (54.195.47.105) port 443 (#0)
0 commit comments