fix broken links

Signed-off-by: Tim Ramlot <[email protected]>

content/docs/concepts/acme-orders-challenges.md

@@ -20,7 +20,7 @@ In order to complete these challenges, cert-manager introduces two
 validation can be found on the Let's Encrypt website
 [here](https://letsencrypt.org/how-it-works/). An order represents a single
 certificate request which will be created automatically once a new
-[`CertificateRequest`](./certificaterequest.md) resource referencing an ACME
+[`CertificateRequest`](../usage/certificaterequest.md) resource referencing an ACME
 issuer has been created. `CertificateRequest` resources are created
 automatically by cert-manager once a [`Certificate`](./certificate.md) resource
 is created, has its specification changed, or needs renewal.

content/docs/contributing/external-issuers.md

@@ -49,13 +49,13 @@ on how to write an external issuer using Kubebuilder and controller-runtime.
 ## Approval
 
 Before signing a certificate, Issuers **must** also ensure that the `CertificateRequest` is
-[`Approved`](../concepts/certificaterequest.md#approval).
+[`Approved`](../usage/certificaterequest.md#approval).
 
 If the `CertificateRequest` is not `Approved`, the issuer **must** not process it. Issuers are not
 responsible for approving `CertificateRequests` and should refuse to proceed if they find a certificate
 that is not approved.
 
-If a `CertificateRequest` created for an issuance associated with a `Certificate` gets [`Denied`](../concepts/certificaterequest.md#approval), the issuance will be failed by cert-manager's issuing controller.
+If a `CertificateRequest` created for an issuance associated with a `Certificate` gets [`Denied`](../usage/certificaterequest.md#approval), the issuance will be failed by cert-manager's issuing controller.
 
 ## Conditions
 
@@ -65,7 +65,7 @@ status of that resource to a ready state, as this is what is used to signal to h
 controllers - such as the `Certificate` controller - that the resource is ready to be consumed.
 
 Conversely, if the `CertificateRequest` fails, it is as important to mark the resource as such, as this will
-also be used as a signal to higher order controllers. Valid condition states are listed under [concepts](../concepts/certificaterequest.md#conditions).
+also be used as a signal to higher order controllers. Valid condition states are listed under [concepts](../usage/certificaterequest.md#conditions).
 
 ## Implementation
 

content/docs/projects/README.md

@@ -8,19 +8,19 @@ that extend the project's functionality, and complement the core cert-manager fe
 
 These tools help with security, compliance and control.
 
-- [istio-csr](./istio-csr.md): Secure Istio service mesh with istio-csr which is
+- [istio-csr](../usage/istio-csr.md): Secure Istio service mesh with istio-csr which is
   an agent that allows for [Istio](https://istio.io) workload and control plane
   components to be secured using cert-manager.
 - [approver-policy](./approver-policy/README.md):
   a cert-manager **approver** that will automatically approve or deny
   certificate requests based on defined policy.
-- [csi-driver](./csi-driver.md):
+- [csi-driver](../usage/csi-driver.md):
   a Container Storage Interface (CSI) driver plugin for Kubernetes to work along
   cert-manager. The goal for this plugin is to seamlessly request and mount
   certificate key pairs to pods. This is useful for facilitating mTLS, or
   otherwise securing connections of pods with guaranteed present certificates
   whilst having all of the features that cert-manager provides.
-- [csi-driver-spiffe](./csi-driver-spiffe.md):
+- [csi-driver-spiffe](../usage/csi-driver-spiffe.md):
   another CSI driver plugin to work along cert-manager. This CSI driver
   transparently delivers [SPIFFE](https://spiffe.io/)
   [SVIDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/#spiffe-verifiable-identity-document-svid)

content/docs/projects/approver-policy/README.md

@@ -4,14 +4,14 @@ description: 'Policy plugin for cert-manager'
 ---
 
 approver-policy is a cert-manager
-[approver](../../concepts/certificaterequest.md#approval)
+[approver](../../usage/certificaterequest.md#approval)
 that will approve or deny CertificateRequests based on policies defined in
 the `CertificateRequestPolicy` custom resource.
 
 ## Prerequisites
 
 [cert-manager must be installed](../../installation/README.md), and
-the [the default approver in cert-manager must be disabled](../../concepts/certificaterequest.md#approver-controller).
+the [the default approver in cert-manager must be disabled](../../usage/certificaterequest.md#approver-controller).
 
 > ⚠️ If the default approver is not disabled in cert-manager, approver-policy will
 > race with cert-manager and policy will be ineffective.
@@ -69,7 +69,7 @@ If you are using approver-policy with [external
 issuers](../../configuration/external.md), you _must_
 include their signer names so that approver-policy has permissions to approve
 and deny CertificateRequests that
-[reference them](../../concepts/certificaterequest.md#rbac-syntax).
+[reference them](../../usage/certificaterequest.md#rbac-syntax).
 For example, if using approver-policy for the internal issuer types, along with
 [google-cas-issuer](https://github.com/jetstack/google-cas-issuer), and
 [aws-privateca-issuer](https://github.com/cert-manager/aws-privateca-issuer),

content/docs/reference/cmctl.md

@@ -74,7 +74,7 @@ Use "cmctl [command] --help" for more information about a command.
 ### Approve and Deny CertificateRequests
 
 CertificateRequests can be
-[approved or denied](../concepts/certificaterequest.md#approval) using their
+[approved or denied](../usage/certificaterequest.md#approval) using their
 respective cmctl commands:
 
 > **Note**: The internal cert-manager approver may automatically approve all

content/docs/tutorials/istio-csr/istio-csr.md

@@ -78,7 +78,7 @@ kubectl create secret generic -n cert-manager istio-root-ca --from-file=ca.pem=c
 ## Installing istio-csr
 
 istio-csr is best installed via Helm, and it should be simple and quick to install. There
-are a bunch of other configuration options for the helm chart, which you can check out [here](../../projects/istio-csr.md).
+are a bunch of other configuration options for the helm chart, which you can check out [here](../../usage/istio-csr.md).
 
 ```console
 helm repo add jetstack https://charts.jetstack.io

content/docs/usage/README.md

@@ -23,7 +23,7 @@ There are several use cases and methods for requesting certificates through cert
   pods.
 - [Securing Istio Gateway](https://istio.io/docs/tasks/traffic-management/ingress/ingress-certmgr/):
   Secure your Istio Gateway in Kubernetes using cert-manager.
-- [Securing Istio Service Mesh](./istio.md): Using the cert-manager
+- [Securing Istio Service Mesh](./istio-csr.md): Using the cert-manager
   [Istio](https://istio.io) integration, secure the mTLS PKI for each pod
   through cert-manager managed certificates.
 - [Policy for cert-manager certificates](./approver-policy.md): Manage

content/docs/usage/approver-policy.md

@@ -3,9 +3,9 @@ title: Policy for cert-manager certificates
 description: 'cert-manager usage: approver-policy'
 ---
 
-cert-manager [CertificateRequests](../concepts/certificaterequest.md) can be
+cert-manager [CertificateRequests](../usage/certificaterequest.md) can be
 rejected from being signed by using the [approval
-API](../concepts/certificaterequest.md#approval).
+API](../usage/certificaterequest.md#approval).
 [approver-policy](https://github.com/cert-manager/approver-policy) is a
 cert-manager project that enables you to write policy to automatically manage
 this approval mechanism.

content/docs/usage/certificaterequest.md

@@ -4,7 +4,7 @@ description: 'cert-manager core concepts: CertificateRequests'
 ---
 
 The `CertificateRequest` is a namespaced resource in cert-manager that is used
-to request X.509 certificates from an [`Issuer`](./issuer.md). The resource
+to request X.509 certificates from an [`Issuer`](../concepts/issuer.md). The resource
 contains a base64 encoded string of a PEM encoded certificate request which is
 sent to the referenced issuer. A successful issuance will return a signed
 certificate, based on the certificate signing request. `CertificateRequests` are

content/docs/usage/csi-driver-spiffe.md

@@ -46,7 +46,7 @@ which is used to create and mount Pod volumes from.
 
 When a Pod is created with the CSI volume configured, the
 driver will locally generate a private key, and create a cert-manager
-[CertificateRequest](../concepts/certificaterequest.md)
+[CertificateRequest](../usage/certificaterequest.md)
 in the same Namespace as the Pod.
 
 The driver uses [CSI Token Request](https://kubernetes-csi.github.io/docs/token-requests.html) to both
@@ -61,7 +61,7 @@ expiry of the signed certificate.
 
 #### Approver
 
-A distinct [cert-manager approver](../concepts/certificaterequest.md#approval)
+A distinct [cert-manager approver](../usage/certificaterequest.md#approval)
 Deployment is responsible for managing the approval and denial condition of
 created CertificateRequests that target the configured SPIFFE Trust Domain
 signer.
@@ -78,7 +78,7 @@ The approver ensures that requests have:
 
 If any of these checks do not pass, the CertificateRequest will be marked as
 Denied, else it will be marked as Approved. The approver will only manage
-CertificateRequests who request from the same [IssuerRef](../concepts/certificaterequest.md)
+CertificateRequests who request from the same [IssuerRef](../usage/certificaterequest.md)
 that has been configured.
 
 ## Installation
@@ -98,7 +98,7 @@ cert-manager `v1.3` or higher is also required.
 csi-driver-spiffe requires cert-manager to be [installed](../installation/README.md) but
 a default installation of cert-manager **will not work**.
 
-> ⚠️ It is **vital** that the [default approver is disabled in cert-manager](../concepts/certificaterequest.md#approver-controller) ⚠️
+> ⚠️ It is **vital** that the [default approver is disabled in cert-manager](../usage/certificaterequest.md#approver-controller) ⚠️
 
 If the default approver is not disabled, the csi-driver-spiffe approver will
 race with cert-manager and policy enforcement will become useless.
@@ -149,7 +149,7 @@ cmctl approve -n cert-manager \
 
 Install csi-driver-spiffe into the cluster using the issuer we configured. We
 must also configure the issuer resource type and name of the issuer we
-configured so that the approver has [permissions to approve referencing CertificateRequests](../concepts/certificaterequest.md#rbac-syntax).
+configured so that the approver has [permissions to approve referencing CertificateRequests](../usage/certificaterequest.md#rbac-syntax).
 
 Note that the `issuer.name`, `issuer.kind` and `issuer.group` will need to be changed to match
 the issuer you're actually using!

content/docs/usage/csi-driver.md

@@ -182,9 +182,9 @@ volumeAttributes:
 ## Requesting Certificates using the mounting Pod's ServiceAccount
 
 If the flag `--use-token-request` is enabled on the csi-driver DaemonSet, the
-[CertificateRequest](../concepts/certificaterequest.md) resource will be created
+[CertificateRequest](../usage/certificaterequest.md) resource will be created
 by the mounting Pod's ServiceAccount. This can be paired with
-[approver-policy](./approver-policy/README.md) to enable advanced policy control
+[approver-policy](../projects/approver-policy/README.md) to enable advanced policy control
 on a per-ServiceAccount basis.
 
 Ensure that you give permissions to Pod ServiceAccounts to create CertificateRequests

content/docs/usage/csi.md

@@ -6,7 +6,7 @@ description: 'cert-manager usage: CSI driver'
 ## Enabling mTLS of Pods using the cert-manager CSI Driver
 
 A [Container Storage Interface (CSI)
-driver](../projects/csi-driver.md) has been created to
+driver](./csi-driver.md) has been created to
 facilitate mTLS of Pods running inside your cluster through use of cert-manager.
 Using this driver will ensure that the private key and corresponding signed
 certificate will be unique to each Pod and will be stored on disk to the node

content/docs/usage/kube-csr.md

@@ -6,7 +6,7 @@ description: 'cert-manager usage: Kubernetes CertificateSigningRequest resources
 Kubernetes has an in-built
 [CertificateSigningRequest](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/)
 resource. This resource is similar to the cert-manager
-[CertificateRequest](../concepts/certificaterequest.md) in that it is used to
+[CertificateRequest](../usage/certificaterequest.md) in that it is used to
 request an X.509 signed certificate from a referenced Certificate Authority
 (CA).
 

public/_redirects

@@ -7,6 +7,7 @@ https://cert-manager.netlify.com/* https://cert-manager.io/:splat 301!
 /docs/projects/istio-csr/ /docs/usage/istio-csr/ 301!
 /docs/projects/csi-driver/ /docs/usage/csi-driver/ 301!
 /docs/projects/csi-driver-spiffe/ /docs/usage/csi-driver-spiffe/ 301!
+/docs/concepts/certificaterequest/ /docs/usage/certificaterequest/ 301!
 
 # Redirect all next-docs on the main site to the release-next preview
 https://cert-manager.io/next-docs/* https://release-next--cert-manager-website.netlify.app/docs/:splat 301!