Fix spelling mistakes

Signed-off-by: James Munnelly <james@munnelly.eu>

content/en/docs/concepts/ca-injector.md

@@ -19,7 +19,7 @@ It copies across the CA defined in the `cert-manager-webhook-ca` Secret
 generated to the `caBundle` field on the `APIService` resource. It also sets
 the webhook's `clientConfig.caBundle` field on the `cert-manager-webhook`
 `ValidatingWebhookConfiguration` resource to that of your Kubernetes API server
-in order to support Kubernetes versions earlier than v1.11.
+in order to support Kubernetes versions earlier than `v1.11`.
 
 The CA injector runs as a separate pod along side the main cert-manager
 controller and webhook components.

content/en/docs/concepts/certificate.md

@@ -5,13 +5,13 @@ weight: 200
 type: "docs"
 ---
 
-cert-manager has the concept of `Certificate`s that define a desired X.509
+cert-manager has the concept of `Certificate`s that define a desired x509
 certificate which will be renewed and kept up to date. A `Certificate` is a
 namespaced resource that references an `Issuer` or `ClusterIssuer` that
 determine what will be honoring the certificate request.
 
 When a `Certificate` is created, a corresponding `CertificateRequest` resource is
-created by cert-manager containing the encoded x.509 certificate request, issuer
+created by cert-manager containing the encoded x509 certificate request, issuer
 reference, and other options based upon the specification of the `Certificate`
 resource.
 
@@ -47,7 +47,7 @@ Names`](https://en.wikipedia.org/wiki/Subject_Alternative_Name) to be associated
 with the certificate.
 
 The referenced Issuer must exist in the same namespace as the Certificate.
-A Certificate can alternatively reference a ClusterIssuer which is
+A Certificate can alternatively reference a `ClusterIssuer` which is
 non-namespaced and so can be referenced from any namespace.
 
 You can read more on how to configure your certificate resources

content/en/docs/concepts/certificaterequest.md

@@ -6,7 +6,7 @@ type: "docs"
 ---
 
 The `CertificateRequest` is a namespaced resource in cert-manager that is used
-to request x.509 certificates from an issuer. The resource contains a base64
+to request x509 certificates from an issuer. 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. `CertificateRequet`s are typically consumed
@@ -58,11 +58,11 @@ manage the logic and life cycle of `CertificateRequet`s.
 `CertificateRequest`s have a set of strongly defined conditions that should be
 used and relied upon by controllers or services to make decisions on what
 actions to take next on the resource. Each condition consists of the pair
-`Ready` - a boolean value, and `Reason` - a string. The set of values and
+`Ready` - a true or false value, and `Reason` - a string. The set of values and
 meanings are as follows:
 
 | Ready | Reason  | Condition Meaning                                                                                                                                                                                                                             |
 |-------|---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| False | Pending | The CertificateRequest is currently pending, waiting for some other operation to take place. This could be that the Issuer does not exist yet or the Issuer is in the process of issuing a certificate.                                       |
-| False | Failed  | The certificate has failed to be issued - either the returned certificate failed to be decoded or an instance of the referenced issuer used for signing failed. No further action will be taken on the CertificateRequest by it's controller. |
+| False | Pending | The `CertificateRequest` is currently pending, waiting for some other operation to take place. This could be that the `Issuer` does not exist yet or the `Issuer` is in the process of issuing a certificate.                                       |
+| False | Failed  | The certificate has failed to be issued - either the returned certificate failed to be decoded or an instance of the referenced issuer used for signing failed. No further action will be taken on the `CertificateRequest` by it's controller. |
 | True  | Issued  | A signed certificate has been successfully issued by the referenced Issuer.                                                                                                                                                                   |

content/en/docs/concepts/issuer.md

@@ -27,7 +27,7 @@ This is a simple Issuer that will sign certificates based on a private key. The
 corresponding CA certificate can then be used to trust newly signed certificates
 in a PKI system.
 
-## Namespacing
+## Namespaces
 
 An Issuer is a namespaced resource, and it is not possible to issue
 certificates from an Issuer in a different namespace. This means you will need

content/en/docs/concepts/project-maturity.md

@@ -7,7 +7,7 @@ type: "docs"
 
 cert-manager has wide adoption with it being in use in both production and
 non-production clusters. The project is still in an alpha state where it has yet
-to reach v1.0.
+to reach `v1.0`.
 
 ## API
 

content/en/docs/concepts/webhook.md

@@ -12,17 +12,17 @@ over cert-manager resources. This means that cert-manager benefits from most of
 the same behavior that core Kubernetes resource have. The webhook has three
 main functions:
 
-- [ValidatingAdmissionWebhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook):
+- [`ValidatingAdmissionWebhook`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook):
   Ensures that when cert-manager resources are created or updated, they conform
   to the rules of the API. This validation is more in depth than for example
   ensuring resources conform to the OpenAPI schema, but instead contains logic such as
   not allowing to specify more than one issuer type per issuer resource. The
   validating admission is always called and will respond with a success or
   failed response.
-- [MutatingAdmissionWebhook](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook):
+- [`MutatingAdmissionWebhook`](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook):
   Changes the contents of resources during create and update operations, for
   example to set default values.
-- [CustomResourceConversionWebhook](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion):
+- [`CustomResourceConversionWebhook`](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion):
   The webhook will also be responsible for implementing a conversion over
   versions in the cert-manager custom resources. Although none are currently
   implemented, the webhook will convert versions from `v1alpha2` to newer
@@ -33,7 +33,7 @@ cert-manager controller and CA injector components.
 
 In order for the API server to communicate with the webhook component, the
 webhook requires a TLS certificate that the apiserver is configured to trust.
-This is created by the [ca-injector](../ca-injector/) and is implemented by the
+This is created by the [`cainjector`](../ca-injector/) and is implemented by the
 following two Secrets:
 
 - `secret/cert-manager-webhook-ca`: A self-signed root CA certificate which is

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

@@ -107,11 +107,11 @@ A number of different DNS providers are supported for the ACME issuer. Below is
 a listing of available providers, their `.yaml` configurations, along with additional Kubernetes
 and provider specific notes regarding their usage.
 
-- [acme-dns](./acme-dns/)
+- [ACMEDNS](./acme-dns/)
 - [Akamai](./akamai/)
 - [AzureDNS](./azuredns/)
 - [CloudFlare](./cloudflare/)
-- [google](./google/)
+- [Google](./google/)
 - [Route53](./route53/)
 - [DigitalOcean](./digitalocean/)
 - [RFC2136](./rfc2136/)
@@ -120,10 +120,11 @@ and provider specific notes regarding their usage.
 
 cert-manager also supports out of tree DNS providers using an external webhook.
 Links to these supported providers along with their documentation are below:
-- [AliDNS-Webhook](https://github.com/pragkent/alidns-webhook)
-- [cert-manager-webhook-dnspod](https://github.com/qqshfox/cert-manager-webhook-dnspod)
-- [cert-manager-webhook-selectel](https://github.com/selectel/cert-manager-webhook-selectel)
-- [cert-manager-webhook-softlayer](https://github.com/cgroschupp/cert-manager-webhook-softlayer)
+
+- [`AliDNS-Webhook`](https://github.com/pragkent/alidns-webhook)
+- [`cert-manager-webhook-dnspod`](https://github.com/qqshfox/cert-manager-webhook-dnspod)
+- [`cert-manager-webhook-selectel`](https://github.com/selectel/cert-manager-webhook-selectel)
+- [`cert-manager-webhook-softlayer`](https://github.com/cgroschupp/cert-manager-webhook-softlayer)
 
 To create a new unsupported DNS provider, follow the development documentation
 [here](../../../contributing/dns-providers/).

content/en/docs/configuration/acme/dns01/acme-dns.md

@@ -1,6 +1,6 @@
 ---
-title: "ACME-DNS"
-linkTitle: "ACME-DNS"
+title: "ACMEDNS"
+linkTitle: "ACMEDNS"
 weight: 30
 type: "docs"
 ---
@@ -22,16 +22,16 @@ spec:
             key: acmedns.json
 ```
 
-In general, clients to acme-dns perform registration on the users behalf and
+In general, clients to ACMEDNS perform registration on the users behalf and
 inform them of the CNAME entries they must create. This is not possible in
 cert-manager, it is a non-interactive system. Registration must be carried out
 beforehand and the resulting credentials JSON uploaded to the cluster as a
-secret. In this example, we use ``curl`` and the API endpoints directly.
-Information about setting up and configuring acme-dns is available on the
-[acme-dns project page](https://github.com/joohoi/acme-dns).
+secret. In this example, we use `curl` and the API endpoints directly.
+Information about setting up and configuring ACMEDNS is available on the
+[ACMEDNS project page](https://github.com/joohoi/acme-dns).
 
-1. First, register with the acme-dns server, in this example, there is one
-   running at "auth.example.com"
+1. First, register with the ACMEDNS server, in this example, there is one
+   running at `auth.example.com`
 
 `curl -X POST http://auth.example.com/register` will return a JSON with
 credentials for your registration:
@@ -64,8 +64,8 @@ Make sure to update the `allowfrom` field to match your cluster configuration. T
 ```
 
 2. Save this JSON to a file with the key as your domain. You can specify multiple domains with the same credentials
-   if you like. In our example, the returned credentials can be used to verify ownership of "example.com" and
-   and "example.org".
+   if you like. In our example, the returned credentials can be used to verify ownership of `example.com` and
+   and `example.org`.
 
 ```json
 {
@@ -87,20 +87,20 @@ Make sure to update the `allowfrom` field to match your cluster configuration. T
 ```
 
 3. Next update your primary DNS server with CNAME record that will tell the verifier how to locate the challenge TXT
-   record. This is obtained from the "fulldomain" field in the registration:
+   record. This is obtained from the `fulldomain` field in the registration:
 
 `_acme-challenge.example.com CNAME d420c923-bbd7-4056-ab64-c3ca54c9b3cf.auth.example.com`
 `_acme-challenge.example.org CNAME d420c923-bbd7-4056-ab64-c3ca54c9b3cf.auth.example.com`
 
 Note that the "name" of the record is always the `\_acme-challenge` subdomain, and the "value" of the record matches
-exactly the "fulldomain" field from registration.
+exactly the `fulldomain` field from registration.
 
-At verification time, the domain name ``d420c923-bbd7-4056-ab64-c3ca54c9b3cf.auth.example.com`` will be a TXT
-record that is set to your validation token. When the verifier queries ``_acme-challenge.example.com``, it will
-be directed to the correct location by this CNAME record. This proves that you control "example.com"
+At verification time, the domain name `d420c923-bbd7-4056-ab64-c3ca54c9b3cf.auth.example.com` will be a TXT
+record that is set to your validation token. When the verifier queries `_acme-challenge.example.com`, it will
+be directed to the correct location by this CNAME record. This proves that you control `example.com`
 
-4. Create a secret from the credentials json that was saved in step 2, this secret is referenced
-   in the ``accountSecretRef`` field of your DNS01 issuer settings.
+4. Create a secret from the credentials JSON that was saved in step 2, this secret is referenced
+   in the `accountSecretRef` field of your DNS01 issuer settings.
 
 ```bash
 $ kubectl create secret generic acme-dns --from-file acmedns.json

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

@@ -6,7 +6,7 @@ type: "docs"
 ---
 
 This provider uses a Kubernetes `Secret` Resource to work. In the following
-example, the secret will have to be named `digitalocean-dns` and have a subkey
+example, the secret will have to be named `digitalocean-dns` and have a sub-key
 `access-token` with the token in it.
 
 To create a Personal Access Token, see [DigitalOcean documentation](https://www.digitalocean.com/docs/api/create-personal-access-token).

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

@@ -41,7 +41,7 @@ To access this service account cert-manager uses a key stored in a Kubernetes
 Secret. First, create a key for the service account and download it as JSON
 file, then create a Secret from this file.
 
-If you did not create the service "dns01-solver" account before, you need to
+If you did not create the service account `dns01-solver` before, you need to
 create it first:
 
 ```bash
@@ -89,7 +89,7 @@ spec:
             key: key.json
 ```
 
-For more information about Issuers and ClusterIssuers, see
+For more information about `Issuers` and `ClusterIssuers`, see
 [Configuration](../../../).
 
 Once an `Issuer` (or `ClusterIssuer`) has been created successfully a

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

@@ -82,7 +82,7 @@ use `nsupdate` to test that the server behaves as expected before we get there.
 `https://debian-administration.org/article/591/Using_the_dynamic_DNS_editor_nsupdate`
 is a solid breakdown of how to use the tool.
 
-To get started, we’ll simply run `nsupdate -k <keyID>` where keyID is the value
+To get started, we’ll simply run `nsupdate -k <keyID>` where `keyID` is the value
 returned from `dnssec-keygen`. This will read the key from disk and provide a
 command prompt to issue commands. In general, we want to write a simple TXT RR
 and make sure we can delete it.
@@ -91,10 +91,10 @@ and make sure we can delete it.
 $ nsupdate -k <keyID>
 update add www1.example.com txt testing
 send
-… test here with ``nslookup``
+… test here with `nslookup`
 update delete www1.example.com txt
 send
-… test here with ``nslookup``
+… test here with `nslookup`
 ```
 
 Any failures to write, read or delete the record will mean that cert-manager
@@ -147,7 +147,7 @@ $ dnssec-keygen -r /dev/urandom -a HMAC-SHA512 -b 512 -n HOST example-com-secret
 ```
 
 Also note how the `tsigAlgorithm` is provided in both the configuration and the
-keygen command. They are listed at
+`keygen` command. They are listed at
 `https://github.com/miekg/dns/blob/v1.0.12/tsig.go#L18-L23`.
 
 The second bit of configuration you need on the Kubernetes side is to create a

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

@@ -43,7 +43,7 @@ permissions:
 ```
 
 > Note: The `route53:ListHostedZonesByName` statement can be removed if you
-> specify the (optional) ``hostedZoneID``. You can further tighten the policy by
+> specify the (optional) `hostedZoneID`. You can further tighten the policy by
 > limiting the hosted zone that cert-manager has access to (e.g.
 > `arn:aws:route53:::hostedzone/DIKER8JEXAMPLE`).
 
@@ -58,13 +58,13 @@ Cert-manager supports two ways of specifying credentials:
 - explicit by providing a `accessKeyID` and `secretAccessKey`
 - or implicit (using [metadata
   service](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)
-  or [env vars or credentials
+  or [environment variables or credentials
   file](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
 
 Cert-manager also supports specifying a `role` to enable cross-account access
 and/or to limit the access for the cert-manager. Integration with
-[kiam](https://github.com/uswitch/kiam) and
-[kube2iam](https://github.com/jtblin/kube2iam) should work out of the box.
+[`kiam`](https://github.com/uswitch/kiam) and
+[`kube2iam`](https://github.com/jtblin/kube2iam) should work out of the box.
 
 
 ## Cross account access
@@ -95,9 +95,9 @@ This allows the role `cert-manager` in account X to manage the Route53 DNS Zone
 in account A.  For more information visit the [official
 documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html>).
 
-## Creating a Issuer (or ClusterIssuer)
+## Creating a Issuer (or `ClusterIssuer`)
 
-Here is an example configuration for a ClusterIssuer:
+Here is an example configuration for a `ClusterIssuer`:
 
 ```yaml
 apiVersion: cert-manager.io/v1alpha2

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

@@ -25,10 +25,10 @@ The HTTP01 Issuer supports a number of additional options.  For full details on
 the range of options available, read the [reference
 documentation](https://docs.cert-manager.io/en/latest/reference/api-docs/#acmeissuerhttp01config-v1alpha2). TODO: fix link
 
-### ingressClass
+### `ingressClass`
 
 If the `ingressClass` field is specified, cert-manager will create new
-Ingress resources in order to route traffic to the 'acmesolver' pods, which
+Ingress resources in order to route traffic to the `acmesolver` pods, which
 are responsible for responding to ACME challenge validation requests.
 
 If this field is not specified, and `ingressName` is also not specified,
@@ -38,36 +38,36 @@ installed in your cluster will server traffic for the challenge solver,
 potentially occurring additional cost.
 
 
-### ingressName
+### `ingressName`
 
-If the 'ingressName' field is specified, cert-manager will edit the named
+If the `ingressName` field is specified, cert-manager will edit the named
 ingress resource in order to solve HTTP01 challenges.
 
-This is useful for compatibility with ingress controllers such as ingress-gce,
+This is useful for compatibility with ingress controllers such as `ingress-gce`,
 which utilize a unique IP address for each Ingress resource created.
 
 This mode should be avoided when using ingress controllers that expose a single
 IP for all ingress resources, as it can create compatibility problems with
 certain ingress-controller specific annotations.
 
-### servicePort
+### `servicePort`
 
-In rare cases it might be not possible/desired to use NodePort as type for the
+In rare cases it might be not possible/desired to use `NodePort` as type for the
 HTTP01 challenge response service, e.g. because of Kubernetes limit
 restrictions. To define which Kubernetes service type to use during challenge
-response specify the following HTTP01 config:
+response specify the following HTTP01 configuration:
 
 ```yaml
     http01:
       # Valid values are ClusterIP and NodePort
       serviceType: ClusterIP
 ```
 
-By default type NodePort will be used when you don't set HTTP01 or when you set
-serviceType to an empty string. Normally there's no need to change this.
+By default type `NodePort` will be used when you don't set HTTP01 or when you set
+`serviceType` to an empty string. Normally there's no need to change this.
 
 
-### podTemplate
+### `podTemplate`
 
 You may wish to change or add to the labels and annotations of solver pods.
 These can be configured under the `metadata` field under `podTemplate`. 

content/en/docs/configuration/ca.md

@@ -60,7 +60,7 @@ Once deployed, you can then check that the issuer has been successfully
 configured by checking the ready status of the certificate. Replace `issuers`
 here with `clusterissuers` if that is what has been deployed.
 
-TODO (@joshvanl): add output to this command once the ready status has been
+TODO (`@joshvanl`): add output to this command once the ready status has been
 configured for the CLI.
 ```bash
 $ kubectl get issuers ca-issuer -n sandbox -o wide