Add explanation for "CN"

content/en/docs/concepts/cluster-administration/certificates.md

@@ -25,7 +25,8 @@ manually through `easyrsa`, `openssl` or `cfssl`.
         tar xzf easy-rsa.tar.gz
         cd easy-rsa-master/easyrsa3
         ./easyrsa init-pki
-1.  Generate a CA. (`--batch` set automatic mode. `--req-cn` default CN to use.)
+1.  Generate a new certificate authority (CA). `--batch` sets automatic mode;
+    `--req-cn` specifies the Common Name (CN) for the CA's new root certificate.
 
         ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
 1.  Generate server certificate and key.

content/en/docs/concepts/services-networking/ingress.md

@@ -319,8 +319,8 @@ type: kubernetes.io/tls
 
 Referencing this secret in an Ingress tells the Ingress controller to
 secure the channel from the client to the load balancer using TLS. You need to make
-sure the TLS secret you created came from a certificate that contains a CN
-for `sslexample.foo.com`.
+sure the TLS secret you created came from a certificate that contains a Common
+Name (CN), also known as a Fully Qualified Domain Name (FQDN) for `sslexample.foo.com`.
 
 ```yaml
 apiVersion: networking.k8s.io/v1beta1

content/en/docs/reference/access-authn-authz/authentication.md

@@ -572,7 +572,7 @@ checked. WARNING: do **not** reuse a CA that is used in a different context unle
 the risks and the mechanisms to protect the CA's usage.
 
 * `--requestheader-client-ca-file` Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names.
-* `--requestheader-allowed-names` Optional.  List of common names (cn). If set, a valid client certificate with a Common Name (cn) in the specified list must be presented before the request headers are checked for user names. If empty, any Common Name is allowed.
+* `--requestheader-allowed-names` Optional. List of Common Name values (CNs). If set, a valid client certificate with a CN in the specified list must be presented before the request headers are checked for user names. If empty, any CN is allowed.
 
 
 ## Anonymous requests

content/en/docs/reference/setup-tools/kubeadm/implementation-details.md

@@ -167,7 +167,7 @@ Kubeadm kubeconfig files with identities for control plane components:
 - A kubeconfig file for kubelet to use, `/etc/kubernetes/kubelet.conf`; inside this file is embedded a client certificate with kubelet identity.
   This client cert should:
     - Be in the `system:nodes` organization, as required by the [Node Authorization](/docs/reference/access-authn-authz/node/) module
-    - Have the CN `system:node:<hostname-lowercased>`
+    - Have the Common Name (CN) `system:node:<hostname-lowercased>`
 - A kubeconfig file for controller-manager, `/etc/kubernetes/controller-manager.conf`; inside this file is embedded a client
   certificate with controller-manager identity. This client cert should have the CN `system:kube-controller-manager`, as defined
 by default [RBAC core components roles](/docs/reference/access-authn-authz/rbac/#core-component-roles)

content/en/docs/tasks/access-kubernetes-api/configure-aggregation-layer.md

@@ -132,7 +132,7 @@ The Kubernetes apiserver connects to the extension apiserver over TLS, authentic
 * private key file via `--proxy-client-key-file`
 * signed client certificate file via `--proxy-client-cert-file`
 * certificate of the CA that signed the client certificate file via `--requestheader-client-ca-file`
-* valid Common Names (CN) in the signed client certificate via `--requestheader-allowed-names`
+* valid Common Name values (CNs) in the signed client certificate via `--requestheader-allowed-names`
 
 The Kubernetes apiserver will use the files indicated by `--proxy-client-*-file` to authenticate to the extension apiserver. In order for the request to be considered valid by a compliant extension apiserver, the following conditions must be met: