General review/proofreading

Signed-off-by: sdarwin <[email protected]>

content/docs/configuration/acme/README.md

@@ -60,6 +60,13 @@ spec:
     server: https://acme-staging-v02.api.letsencrypt.org/directory
     privateKeySecretRef:
       # Secret resource that will be used to store the account's private key.
+      # This is your identity with your ACME provider. Any secret name
+      # may be chosen. It will be populated with data automatically,
+      # so generally nothing further needs to be done with
+      # the secret. If you lose this identity/secret, you will be able to
+      # generate a new one and generate certificates for any/all domains
+      # managed using your previous account, but you will be unable to revoke
+      # any certificates generated using that previous account.
       name: example-issuer-account-key
     # Add a single challenge solver, HTTP01 using nginx
     solvers:

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

@@ -387,7 +387,7 @@ Here's how to set it up:
 
    - `<service-account-name>` name of the `ServiceAccount` object.
    - `<service-account-namespace>` namespace of the `ServiceAccount` object.
-   - `<cert-manager-service-account-name>` name of cert-managers `ServiceAccount` object, as created during cert-manager installation.
+   - `<cert-manager-service-account-name>` name of cert-manager's `ServiceAccount` object, as created during cert-manager installation.
    - `<cert-manager-namespace>` namespace that cert-manager is deployed into.
 
 4. **Create an Issuer or ClusterIssuer**

content/docs/trust/trust-manager/README.md

@@ -31,7 +31,7 @@ install trust-manager.
 
 ## Usage
 
-trust-manager is intentionally simple, adding just one new Kubernetes `CustomResourceDefintion`: `Bundle`.
+trust-manager is intentionally simple, adding just one new Kubernetes `CustomResourceDefinition`: `Bundle`.
 
 A `Bundle` represents a set of X.509 certificates that should be distributed across a cluster.
 

content/docs/tutorials/acme/migrating-from-kube-lego.md

@@ -6,7 +6,7 @@ description: 'cert-manager tutorials: Migrating from kube-lego'
 [kube-lego](https://github.com/jetstack/kube-lego) is an older Jetstack project
 for obtaining TLS certificates from Let's Encrypt (or another ACME server).
 
-Since cert-managers release, kube-lego has been gradually deprecated in favor
+Since cert-manager's release, kube-lego has been gradually deprecated in favor
 of this project. There are a number of key differences between the two:
 
 | Feature                                   | kube-lego                        | cert-manager           |
@@ -229,4 +229,4 @@ I1025 21:54:02.869269       1 sync.go:206] Certificate my-example-certificate sc
 ```
 
 Here we can see cert-manager has verified the existing TLS certificate and
-scheduled it to be renewed in 292 hours time.
+scheduled it to be renewed in 292 hours time.

content/docs/tutorials/acme/nginx-ingress.md

@@ -107,7 +107,7 @@ sample deployment and an associated service:
 ```yaml file=./example/service.yaml
 ```
 
-You can create download and reference these files locally, or you can
+You can download and reference these files locally, or you can
 reference them from the GitHub source repository for this documentation.
 To install the example service from the tutorial files straight from GitHub, do
 the following:

content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md

@@ -235,6 +235,7 @@ metadata:
     # This tells Google Cloud to create an External Load Balancer to realize this Ingress
     kubernetes.io/ingress.class: gce
     # This enables HTTP connections from Internet clients
+    # Since "true" is the default, does not need to be set.
     kubernetes.io/ingress.allow-http: "true"
     # This tells Google Cloud to associate the External Load Balancer with the static IP which we created earlier
     kubernetes.io/ingress.global-static-ip-name: web-ip
@@ -277,7 +278,7 @@ At this point we have a Google load balancer which is forwarding HTTP traffic to
 > configured and for Internet clients to be routed to your web server.
 > Refer to the [Troubleshooting](#troubleshooting) section if it takes longer.
 >
-> 🔰 Read about how to [Use a static IP addresses for HTTP(S) load balancers via Ingress annotation](https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#static_ip_addresses_for_https_load_balancers).
+> 🔰 Read about how to [Use static IP addresses for HTTP(S) load balancers via Ingress annotation](https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#static_ip_addresses_for_https_load_balancers).
 >
 > 🔰 Read a [Summary of external Ingress annotations for GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/load-balance-ingress#summary_of_external_ingress_annotations).
 >

content/docs/usage/csi.md

@@ -17,7 +17,7 @@ certificate will be unique to each Pod and will be stored on disk to the node
 that the Pod is scheduled to.
 
 The life cycle of the certificate key pair matches that of the Pod; the certificate is issued
-when the Pod is creation, and destroyed during termination.
+when the Pod is created, and destroyed during termination.
 
 This driver also handles renewal of live certificates on the fly.
 
@@ -70,8 +70,8 @@ node, containing that Pods information as well as the attributes detailed from
 the in-line volume attributes. From this, the driver will generate a private key
 as well as a certificate request based upon that key using information built
 from the volume attributes. The driver will create a `CertificateRequest`
-resource in the same namespace in the Pod that, if valid, cert-manager will
-return a signed certificate.
+resource in the same namespace as the Pod. If the request is valid, cert-manager
+will return a signed certificate.
 
 The resulting signed certificate and generated key will be written to that
 node's file system to be mounted to the Pods file system. Since the driver needs

content/docs/usage/gateway.md

@@ -152,7 +152,7 @@ meet the following requirements:
 
 |           Field                |                         Requirement                         |
 |--------------------------------|-------------------------------------------------------------|
-| `tls.hostname`                 | Must not be empty.                                          |
+| `hostname`                     | Must not be empty.                                          |
 | `tls.mode`                     | Must be set to `Terminate`. `Passthrough` is not supported. |
 | `tls.certificateRef.name`      | Cannot be left empty.                                       |
 | `tls.certificateRef.kind`      | If specified, must be set to `Secret`.                      |

content/docs/usage/ingress.md

@@ -187,10 +187,11 @@ Besides the annotation, it is necessary that each ingress possess a unique `tls.
 The ingress-shim sub-component is deployed automatically as part of
 installation.
 
-If you would like to use the old
-[kube-lego](https://github.com/jetstack/kube-lego) `kubernetes.io/tls-acme:
-"true"` annotation for fully automated TLS, you will need to configure a default
-`Issuer` when deploying cert-manager. This can be done by adding the following
+The old [kube-lego](https://github.com/jetstack/kube-lego) `kubernetes.io/tls-acme: "true"`
+annotation is an alternate method to fully automated TLS.
+If this annotation is set, the other annotations are not needed,
+but in order to use it you will need to configure a default Issuer when deploying cert-manager.
+This can be done by adding the following
 `--set` when deploying using Helm:
 
 ```bash
@@ -212,7 +213,11 @@ In the above example, cert-manager will create `Certificate` resources that
 reference the `ClusterIssuer` `letsencrypt-prod` for all Ingresses that have a
 `kubernetes.io/tls-acme: "true"` annotation.
 
-Issuers configured via annotations have a preference over the default issuer. If a default issuer is configured via CLI flags and a `cert-manager.io/cluster-issuer` or `cert-manager.io/issuer` annotation also has been added to an Ingress, the created `Certificate` will refer to the issuer configured via annotation.
+Issuers configured via specific annotations have a preference over the default issuer. If a default issuer is configured via CLI flags and a `cert-manager.io/cluster-issuer` or `cert-manager.io/issuer` annotation also has been added to an Ingress, the created `Certificate` will refer to the issuer configured via annotation.
+
+When `kubernetes.io/tls-acme: "true"` annotation hasn't been set, automatic certificate deployment may still occur based on the `cert-manager.io/issuer`, `cert-manager.io/issuer-kind`, and `cert-manager.io/issuer-group` annotations.
+
+If all annotations are absent, then manual deployment is necessary: create Certificate resources directly, and assign the resulting Secret to the Ingress.
 
 For more information on deploying cert-manager, read the [installation
 guide](../installation/README.md).