Several documentation updates

Author: Jonathan S. Katz

docs/content/custom-resources/_index.md

@@ -464,7 +464,7 @@ There are two Secrets that need to be created:
 1. A Secret containing the certificate authority (CA). You may only need to create this Secret once, as a CA certificate can be shared amongst your clusters.
 2. A Secret that contains the TLS private key & certificate.
 
-This assumes that you have already [generated your TLS certificates](https://www.postgresql.org/docs/current/ssl-tcp.html#SSL-CERTIFICATE-CREATION) where the CA is named `ca.crt` and the server key and certificate are named `server.key` and `server.crt` respectively.
+This assumes that you have already [generated your TLS certificates](https://blog.crunchydata.com/blog/tls-postgres-kubernetes-openssl) where the CA is named `ca.crt` and the server key and certificate are named `server.key` and `server.crt` respectively.
 
 Substitute the correct values for your environment into the environmental variables in the example below:
 

docs/content/pgo-client/common-tasks.md

@@ -1040,7 +1040,7 @@ There are a variety of methods available to generate these items: in fact,
 Kubernetes comes with its own [certificate management system](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)!
 It is up to you to decide how you want to manage this for your cluster. The
 PostgreSQL documentation also provides an example for how to
-[generate a TLS certificate](https://www.postgresql.org/docs/current/ssl-tcp.html#SSL-CERTIFICATE-CREATION)
+[generate a TLS certificate](https://blog.crunchydata.com/blog/tls-postgres-kubernetes-openssl)
 as well.
 
 To set up TLS for your PostgreSQL cluster, you have to create two [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/):
@@ -1191,7 +1191,7 @@ pgo create cluster hippo \
 ```
 
 By default, the PostgreSQL Operator has each replica connect to PostgreSQL using
-a [PostgreSQL TLS mode](https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS)
+a [PostgreSQL TLS mode](https://blog.crunchydata.com/blog/tls-postgres-kubernetes-openssl)
 of `verify-ca`. If you wish to perform TLS mutual authentication between
 PostgreSQL instances (i.e. certificate-based authentication with SSL mode of
 `verify-full`), you will need to create a

docs/content/releases/4.7.0.md

@@ -115,7 +115,7 @@ The `pgclusters.crunchydata.com` custom resource now allows for the following at
 
 Additionally, the following flags are now available on the [`pgo update cluster`](https://access.crunchydata.com/documentation/postgres-operator/latest/pgo-client/reference/pgo_update_cluster/) command:
 
-- `--disable-tls`: removes TLS from a cluster
+- `--disable-server-tls`: removes TLS from a cluster
 - `--disable-tls-only`: removes the TLS-only requirement from a cluster
 - `--enable-tls-only`: adds the TLS-only requirement to a cluster
 - `--server-ca-secret`: combined with `--server-tls-secret`, enables TLS in a cluster
@@ -167,6 +167,6 @@ Note that PGO will rewrite some of your HBA rules when performing any TLS enable
 - Support the substitution for the limit on the number of queries to include the the `pg_stat_statements` support of pgMonitor. Defaults to 20, which is the pgMonitor upstream value. Contributed by Steven Siahetiong (@ssiahetiong).
 - Ensure `sshd_config` is correctly set on an upgrade. This could have manifested with some pgBackRest functionality not working. This can be manually fixed by setting `UsePAM no` in the `sshd_config` file in a cluster. Reported by (@douggutaby)
 - Ensure major upgrades via `crunchy-upgrade` support PostgreSQL 12 and PostgreSQL 13. Reported by (@lbartnicki92).
-- The `pgo-deployer` and Ansible installer will no longer create an initial TLS secret for the PGO apiserver. PGO apiserver has been able to self-create this for a long time, and PGO defers to that. This fixes an issue that occurred on newer builds where certificates generated by OPenSSL contained incomplete usage blocks, which could cause for these certificates to be properly outright rejected.
+- The `pgo-deployer` and Ansible installer will no longer create an initial TLS secret for the PGO apiserver. PGO apiserver has been able to self-create this for a long time, and PGO defers to that. This fixes an issue that occurred on newer builds where certificates generated by OpenSSL contained incomplete usage blocks, which could cause for these certificates to be properly outright rejected.
 - Fix installed RBAC permissions via OLM. Reported by Tim Bo (@timbrd), with additional analysis from Aleksander Roszig (@AleksanderRoszig) and Eric Ace (@aceeric).
 - Fix nonbreaking error message that occurs when `pgo-scheduler` container shuts down in the UBI 8 base container.

docs/content/tutorial/tls.md

@@ -15,7 +15,7 @@ There are three items that are required to enable TLS in your PostgreSQL cluster
 - A TLS private key
 - A TLS certificate
 
-There are a variety of methods available to generate these items: in fact, Kubernetes comes with its own [certificate management system](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)! It is up to you to decide how you want to manage this for your cluster. The PostgreSQL documentation also provides an example for how to [generate a TLS certificate](https://www.postgresql.org/docs/current/ssl-tcp.html#SSL-CERTIFICATE-CREATION) as well.
+There are a variety of methods available to generate these items: in fact, Kubernetes comes with its own [certificate management system](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)! It is up to you to decide how you want to manage this for your cluster. The PostgreSQL documentation also provides an example for how to [generate a TLS certificate](https://blog.crunchydata.com/blog/tls-postgres-kubernetes-openssl) as well.
 
 To set up TLS for your PostgreSQL cluster, you have to create two [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/): one that contains the CA certificate, and the other that contains the server TLS key pair.