Update the release-next documentation

.spelling

@@ -56,6 +56,7 @@ DataDog
 Dean-Coakley
 DigitalOcean
 Distroless
+etcd
 EC2
 ECDSA
 EKS
@@ -79,6 +80,7 @@ HTTPRoute
 HashiCorp
 Helmfile
 IAM
+IdP
 INWX
 IPs
 IPv6
@@ -94,6 +96,7 @@ KUARD
 Kirill-Garbar
 Knative
 Krew
+kuard
 KubeCon
 Kubernetes
 Kyverno
@@ -116,9 +119,11 @@ OperatorHub.io
 PEM
 PKCS#12
 PKCS#8
+Pomerium
 PowerShell
 Prometheus
 RBAC
+Redis
 RFC2136
 RFC8555
 RR
@@ -245,6 +250,7 @@ manual-rotation-private-key
 mechanism
 metadata
 middleware
+migrate-api-version
 misconfiguration
 misconfigured
 mixin
@@ -257,6 +263,7 @@ namespace
 namespaced
 namespaces
 ndegory
+oauth2
 openshift-supported-versions
 powershell
 pre
@@ -270,6 +277,7 @@ publicised
 reStructuredText
 rebase
 reissuance
+reflector
 remediate
 renewBefore
 repo

_redirects

@@ -77,3 +77,6 @@ https://docs.cert-manager.io/en/release-0.16/* https://cert-manager.io/docs/rele
 https://docs.cert-manager.io/en/release-* https://cert-manager.io/docs/release-notes/release-notes-:splat 301!
 https://docs.cert-manager.io https://cert-manager.io/docs 301!
 https://docs.cert-manager.io/* https://cert-manager.io/docs/:splat 302!
+
+# These rules handle page renames
+https://cert-manager.io/docs/faq/kubed/* https://cert-manager.io/docs/faq/sync-secrets/

content/en/docs/configuration/acme/_index.md

@@ -371,13 +371,13 @@ solvers:
     apiKeySecretRef:
       name: cloudflare-apikey-secret
       key: apikey
-selector:
-  matchLabels:
-   'email': 'user@example.com'
-   'solver': 'cloudflare'
-  dnsZones:
-    - 'test.example.com'
-    - 'example.dev'
+  selector:
+    matchLabels:
+     'email': 'user@example.com'
+     'solver': 'cloudflare'
+    dnsZones:
+      - 'test.example.com'
+      - 'example.dev'
 ```
 In this case the `DNS01` solver for CloudFlare will only be used to solve a
 challenge for a DNS name if the `Certificate` has a label from

content/en/docs/configuration/acme/dns01/_index.md

@@ -115,7 +115,7 @@ spec:
     - selector:
         dnsZones:
         - 'example.com'
-    - dns01:
+      dns01:
         # Valid values are None and Follow
         cnameStrategy: Follow
         route53:
@@ -169,6 +169,7 @@ Links to these supported providers along with their documentation are below:
 - [`cert-manager-webhook-gandi`](https://github.com/bwolf/cert-manager-webhook-gandi)
 - [`cert-manager-webhook-infomaniak`](https://github.com/Infomaniak/cert-manager-webhook-infomaniak)
 - [`cert-manager-webhook-inwx`](https://gitlab.com/smueller18/cert-manager-webhook-inwx)
+- [`cert-manager-webhook-linode`](https://github.com/slicen/cert-manager-webhook-linode)
 - [`cert-manager-webhook-oci`](https://gitlab.com/dn13/cert-manager-webhook-oci) (Oracle Cloud Infrastructure)
 - [`cert-manager-webhook-scaleway`](https://github.com/scaleway/cert-manager-webhook-scaleway)
 - [`cert-manager-webhook-selectel`](https://github.com/selectel/cert-manager-webhook-selectel)
@@ -177,6 +178,7 @@ Links to these supported providers along with their documentation are below:
 - [`cert-manager-webhook-loopia`](https://github.com/Identitry/cert-manager-webhook-loopia)
 - [`cert-manager-webhook-arvan`](https://github.com/kiandigital/cert-manager-webhook-arvan)
 - [`bizflycloud-certmanager-dns-webhook`](https://github.com/bizflycloud/bizflycloud-certmanager-dns-webhook)
+- [`cert-manager-webhook-hetzner`](https://github.com/vadimkim/cert-manager-webhook-hetzner)
 
 You can find more information on how to configure webhook providers
 [here](./webhook/).

content/en/docs/configuration/external.md

@@ -43,6 +43,7 @@ These external issuers are known to support and honor [approval](https://cert-ma
   certificates signed by [FreeIPA](https://www.freeipa.org).
 - [ADCS Issuer](https://github.com/nokia/adcs-issuer): Requests
   certificates signed by [Microsoft Active Directory Certificate Service](https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority).
+- [CFSSL Issuer](https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/cfssl-issuer/): Request certificates signed by a [CFSSL](https://github.com/cloudflare/cfssl) `multirootca` instance.
 
 ## Building New External Issuers
 

content/en/docs/faq/_index.md

@@ -11,7 +11,7 @@ face:
 - [TLS Terminology, including commonly misused terms](./terminology/)
 - [Troubleshooting issuing ACME certificates](./acme/)
 - [How to change the Cluster Resource Namespace](./cluster-resource/)
-- [How to sync secrets across namespaces](./kubed/)
+- [How to sync secrets across namespaces](./sync-secrets/)
 - [Failing to create resources due to Webhook](./webhook/)
 
 ## Certificates

content/en/docs/faq/acme.md

@@ -54,6 +54,7 @@ Events:
 
 * `Failed to update ACME account:400 urn:ietf:params:acme:error:invalidEmail`: the email you specified in the Issuer configuration isn't valid.
 * `Error initializing issuer: Failed to register ACME account: secrets "acme-key" already exists`: there might be a leftover account from a previous issuer that is no longer valid, you should remove the secret so it can be recreated.
+* `Error accepting challenge: 400 urn:ietf:params:acme:error:malformed: Unable to update challenge :: authorization must be pending`: this suggests that the authorization was not in 'pending' state at a time when cert-manager sent a request to the ACME server to accept the challenge. This may be because the domain validation has already failed and the authorization has been marked as 'invalid'. Check the authorization URL on the status of the `Order` or `Challenge` to see the status of the authorization and any additional information.
 
 ## 2. Troubleshooting Orders
 
@@ -109,6 +110,12 @@ Events:
   Normal  OrderValid  4s    cert-manager  Order completed successfully
 ```
 
+You can see some additional information about the state of the [ACME authorization](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) that needs to be validated as part of this order using the authorization URL from the status of the `Order`:
+
+```bash
+$ kubectl get order <order-name> -ojsonpath='{.status.authorizations[x].url}'
+```
+
 If the Order is not completing successfully, you can debug the challenges
 for the Order by running `kubectl describe` on the `Challenge` resource which is described in the following steps.
 
@@ -170,6 +177,12 @@ Status:
 In this example our HTTP01 check fails due a network issue.
 You will also see any errors coming from your DNS provider here.
 
+You can also see some additional information about the state of the [ACME authorization](https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4) that the challenge should validate using the authorization URL on from the status of the `Challenge`:
+
+```bash
+$ kubectl get challenge <challenge-name> -ojsonpath='{.spec.authorizationURL}'
+```
+
 ### HTTP01 troubleshooting
 First of all check if you can see the challenge URL from the public internet, if this does not work check your Ingress and firewall configuration as well as the service and pod cert-manager created to solve the ACME challenge.
 If this does work check if your cluster can see it too. It is important to test this from inside a Pod. If you get a connection error it is suggested to check the cluster's network configuration.

content/en/docs/faq/kubed.md → content/en/docs/faq/sync-secrets.md

@@ -7,9 +7,11 @@ type: "docs"
 
 It may be required for multiple components across namespaces to consume the same
 `Secret` that has been created by a single `Certificate`. The recommended way to
-do this is to use [kubed](https://github.com/appscode/kubed) with its [secret
-syncing
-feature](https://appscode.com/products/kubed/v0.11.0/guides/config-syncer/intra-cluster/). However if your use case is a wildcard certificate another approach may meet your needs.
+do this is to use extensions such as:
+  - [reflector](https://github.com/emberstack/kubernetes-reflector) with support
+   for auto secret reflection
+  - [kubed](https://github.com/appscode/kubed) with its 
+  [secret syncing feature](https://appscode.com/products/kubed/v0.11.0/guides/config-syncer/intra-cluster/)
 
 ## Serving a wildcard to ingress resources in different namespaces (default SSL certificate)
 
@@ -31,9 +33,43 @@ spec:
     #secretName omitted to use default wildcard certificate
 ```
 
-## Syncing arbitrary secrets across namespaces using kubed
 
-In order for the target Secret to be synced, you can use the `secretTemplate` field for annotating the generated secret with the kubed sync annotation (See [CertificateSecretTemplate]). The example below shows syncing
+## Syncing arbitrary secrets across namespaces using extensions
+
+In order for the target Secret to be synced, you can use the `secretTemplate` field 
+for annotating the generated secret with the extension specific annotation (See [CertificateSecretTemplate]).
+
+
+### Using `reflector`
+ The example below shows syncing a certificate's secret from the `cert-manager` namespace to multiple namespaces (i.e. `dev`, `staging`, `prod`).
+ Reflector will ensure that any namespace (existing or new) matching the allowed condition (with regex support) will get a copy of the certificate's secret and will keep it up to date.
+ You can also sync other secrets (different name) using `reflector` (consult the extension's [README](https://github.com/emberstack/kubernetes-reflector/blob/main/README.md))
+
+```yaml
+---
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: source
+  namespace: cert-manager
+spec:
+  secretName: source-tls
+  commonName: source
+  issuerRef:
+    name: source-ca
+    kind: Issuer
+    group: cert-manager.io
+  secretTemplate:
+    annotations:
+      reflector.v1.k8s.emberstack.com/reflection-allowed: "true"  
+      reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "dev,staging,prod"  # Control destination namespaces
+      reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true" # Auto create reflection for matching namespaces
+      reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "dev,staging,prod" # Control auto-reflection namespaces
+```
+
+
+### Using `kubed`
+ The example below shows syncing
 a certificate belonging to the `sandbox` Certificate from the `cert-manager`
 namespace, into the `sandbox` namespace.
 
@@ -62,4 +98,6 @@ spec:
       kubed.appscode.com/sync: "cert-manager-tls=sandbox" # Sync certificate to matching namespaces
 ```
 
-[CertificateSecretTemplate]: ../../reference/api-docs/#cert-manager.io/v1.CertificateSecretTemplate
+[CertificateSecretTemplate]: ../../reference/api-docs/#cert-manager.io/v1.CertificateSecretTemplate
+
+

content/en/docs/faq/webhook.md

@@ -1,6 +1,6 @@
 ---
-title: "Webhook"
-linkTitle: "Webhook"
+title: "Troubleshooting webhook"
+linkTitle: "Troubleshooting webhook"
 weight: 60
 type: "docs"
 ---
@@ -10,3 +10,5 @@ and as such no cert-manager resources can be created or updated. In this case,
 it is advised to check the
 [compatibility](../../installation/compatibility/) of
 your environment and take necessary action outlined there.
+
+See more information about debugging webhook related issues [here](../../concepts/webhook/#known-problems-and-solutions).

content/en/docs/installation/helm.md

@@ -82,7 +82,7 @@ $ helm install \
   --create-namespace \
   --version v1.6.1 \
   --set prometheus.enabled=false \  # Example: disabling prometheus using a Helm parameter
-  --set webhook.timeoutSeconds=4   # Example: changing the wehbook timeout using a Helm parameter
+  --set webhook.timeoutSeconds=4   # Example: changing the webhook timeout using a Helm parameter
 ```
 
 Once you have deployed cert-manager, you can [verify](../verify/) the installation.

content/en/docs/installation/supported-releases.md

@@ -64,7 +64,7 @@ Note that dates in the future are uncertain and might change.
 [0.11]: https://cert-manager.io/docs/release-notes/release-notes-0.11
 
 You can find available releases on the [releases
-page](https://github.com/cert-manager/cert-manager/releases). You can find
+page](https://github.com/jetstack/cert-manager/releases). You can find
 the release notes for each minor release
 [here](https://cert-manager.io/docs/release-notes/), and the upgrade
 instructions are
@@ -173,7 +173,7 @@ possible.
 [#2857]: https://github.com/jetstack/cert-manager/issues/2857 "CloudDNS DNS01 challenge crashes cert-manager"
 [#4142]: https://github.com/jetstack/cert-manager/issues/4142 "Cannot issue a certificate that has the same subject and issuer"
 [#3444]: https://github.com/jetstack/cert-manager/issues/3444 "Certificates do not get immediately updated after updating them"
-[#3882]: https://github.com/jetstack/cert-manager/pull/3882: "Helm upgrade from v1.2 to v1.2 impossible due to a Helm bug"
+[#3882]: https://github.com/jetstack/cert-manager/pull/3882 "Certificate's revision history limit validated by webhook"
 [#3644]: https://github.com/jetstack/cert-manager/issues/3644 "Helm upgrade from v1.2 to v1.2 impossible due to a Helm bug"
 
 
@@ -183,22 +183,16 @@ The list of supported Kubernetes versions displayed in the [Supported
 Releases](#supported-releases) section depends on what the cert-manager
 maintainers think is reasonable to support and to test.
 
-As of 16 Dec 2021, our testing coverage is:
+As of 6th January 2022, our testing coverage is:
 
 | Release branch |      Prow configuration       |         Dashboard         | Kubernetes versions tested |  Periodicity  |
 |:--------------:|:------------------------------|:--------------------------|:--------------------------:|:-------------:|
-|      PRs       | [`presubmits.yaml`][]         | [`presubmits-blocking`][] |            1.22            |  On each PR   |
+|      PRs       | [`presubmits.yaml`][]         | [`presubmits-blocking`][] |            1.23            |  On each PR   |
 |     master     | [`periodics.yaml`][]          | [`master`][]              |        1.18 → 1.23         | Every 2 hours |
-|  release-1.7   | n/a\*                         | n/a                       |            n/a             |      n/a      |
-|  release-1.6   | [`previous-periodics.yaml`][] | [`previous`][]            |        1.18 → 1.23         | Every 2 hours |
+|  release-1.7   | [`next-periodics.yaml`][]     | [`next`][]                |        1.18 → 1.23         | Every 2 hours |
+|  release-1.6   | [`previous-periodics.yaml`][] | [`previous`][]            |        1.18 → 1.22         | Every 2 hours |
 |  release-1.5   | n/a                           |                           |            n/a             |      n/a      |
 
-\*The release-1.7 is currently equal to release-1.6; we decided to disable the
-periodic tests until we release `1.7.0-alpha.0`. The disabling of the periodic
-tests was performed in the [testing PR
-606](https://github.com/jetstack/testing/pull/606). This note should be removed
-as soon as we release `1.7.0-alpha.0`.
-
 [`presubmits.yaml`]: https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-presubmits.yaml
 [`periodics.yaml`]: https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml
 [`next-periodics.yaml`]: https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/release-next/cert-manager-release-next-periodics.yaml
@@ -208,8 +202,7 @@ as soon as we release `1.7.0-alpha.0`.
 [`next`]: https://testgrid.k8s.io/jetstack-cert-manager-next
 [`previous`]: https://testgrid.k8s.io/jetstack-cert-manager-previous
 
-The oldest Kubernetes release supported by cert-manager is 1.16, as we want
-to be supporting most commercial Kubernetes offerings.
+The oldest Kubernetes release supported by cert-manager is currently 1.18.
 
 |      Vendor       | Oldest Kubernetes Release\* |               Other Old\*\* Kubernetes Releases               |
 |:-----------------:|-----------------------------|---------------------------------------------------------------|
@@ -218,7 +211,7 @@ to be supporting most commercial Kubernetes offerings.
 |    [AKS][aks]     | 1.19 (EOL Jan 2022)         | 1.20 (EOL Feb 2022)                                           |
 | [OpenShift 4][os] | 1.18 (4.5, EOL July 2021)   | 1.19 (4.6 EUS, EOL May 2022)                                  |
 
-\*Oldest release relevant to the next cert-manager release, as of 2021-11-19
+\*Oldest release relevant to the next cert-manager release, as of 2022-01-06
 
 \*\*We say that a Kubernetes offering is "old" when it is not supported upstream
 as per the [Version Skew