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/policy/approval/README.md

@@ -13,10 +13,10 @@ that rejects the request.
 
 ## Rejecting requests before sending the X.509 Certificate Signing Request (CSR) to the issuer
 
-cert-manager requires that a [CertificateRequest](../../concepts/certificaterequest.md)
+cert-manager requires that a [CertificateRequest](../../usage/certificaterequest.md)
 is approved before it is sent to the issuer. Also, CertificateSigningRequests must
 be approved before they are sent to the issuer. This approval is done by adding an
-[approval condition](../../concepts/certificaterequest.md#approval) to the resource.
+[approval condition](../../usage/certificaterequest.md#approval) to the resource.
 
 In a default installation, cert-manager automatically approves all CertificateRequests
 and CertificateSigningRequests that use any of its built-in issuers. This is done to

content/docs/policy/approval/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/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,7 +182,7 @@ 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](../policy/approval/approver-policy/README.md) to enable advanced policy control
 on a per-ServiceAccount basis.

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).