Certificate changes for 7.6

[ggray-cb]

This PR covers several certificate/encryption-related features:

• MB-58276 Document removal of support for TLS1 and TLS1.1
• DOC-11682 Document email / UI alert for certificate expiry
• DOC-11297 Add X.509 Elliptic Curve Keys support to the docs
• DOC-11280 Change list of default ciphers / explain change
• DOC-11071 Document support for PKCS12 format of cert

Overview of changes, with links to the preview site:

• What’s New in Version 7.6:
  • Moved all security and authentication features to their own section (which will later be done to organize other content).
  • Added entries for all certificate-related new features. Note that this is the only work done for DOC-11280 because there is no main documentation that covers the area covered by the changes.
• Certificates:
  • heavily edited this topic to comply with our documentation standards. Some content was removed because it wasn't relevant to this topic or was redundant.
  • Added PKCS 12 support for node certificates.
  • Added section on certificate expiration that mentions alerts for expiration and mentions the expiration can be changed.
  • Expanded section on private keys to discuss support for EC keys.
• Configure Server Certificates: also heavily edited for standards and clarity. Added section on using PKCS 12 certificates.
• Upgrade: added a "Before You Upgrade" section and moved existing warning about .NET SDKs and mixed mode. Added section about the removal of TLS 1 and 1.1.
• On-the-Wire Security: changes mainly for removasl of TLS 1 and 1.1.
• Manage On-the-Wire Security: standards and clarity edits, plus changes for TLS 1 and 1.1 removal.
• Alerts: Added certificate expiration to list of possible alerts. Also updated out-of-date screenshot.
• Setting Alerts: fixed error in several examples. Updated some example output for limits. Added limit setting for expiration alerts.
• Configure On-the-Wire Security: changes for TLS 1 and 1.1 removal, mainly around tlsMinVersion setting.

[timofey-barmin]

The terminology has changed a bit since we introduced multiple ca support. Since you are rewriting it maybe we should not use obsolete terminology.
For example, we don't actually have cluster certificate anymore. We used to have a single root cert for the cluster, and all node certs were supposed to be signed by that cert, but it has changed.
Now every node can be issued by a separate ca and that will be fine. In this case it is not really clear what to call the cluster certificate. I suggest we get rid of this term as it seems confusing.

Instead of "the cluster certificate" we now have the trust store which is basically a list of root and intermediate certificates that are considered trusted by the cluster (it is cluster wide). The meaning of it is simple: we trust any certificate that was signed by a certificate from the trust store.
Basically any node certificate chain should end with a certificate from the trust store.

[timofey-barmin]

The private key of the default self-signed cluster certificate is not available.

I think it would be better to say "default self-signed root certificate"

[timofey-barmin]

Couchbase Server provides a default self-signed cluster certificate which it generates and deploys while creating the first node in a cluster.
You can deploy a new replacement cluster certificate on the cluster using the Couchbase REST API or command line interface.
For example, you can replace the certificate with one supplied by a well-known CA to make authentication with third parties easier.
The current cluster certificate is always visible on the Root Certificate panel of the Security screen of Couchbase Server Web Console.

This paragraph seems to be obsolete. There is no root certificate panel in UI anymore.
I think we can write about the trust store here instead.
Main points:

• This is a list of trusted certificates that is used for peer verification when (1) TLS connections are established between couchbase-nodes, and (2) when clients authenticate using client certificates.
• It is cluster wide
• the default self-signed root certificate (which is generated while creating the first node in a cluster) is added to the trust store automatically. It can be removed from the trust store if all nodes use custom certificates.
• Trusted certificates are visible on Certificates panel of the Security screen

[timofey-barmin]

Therefore, certificates of the existing and new node must have a common CA in their trust chain.

They don't have to have common CA.
But rather cluster and the-node-to-be-added should have each others root (CA) certificates added to their trust store. Basically they should trust each other.
Say A joins B. Then A should have B's root certificate added to A's trusted store. And B should have A's root certificate added to B's trusted store.
In most cases it is satisfied automatically because usually all certs are issued by the same CA (so root cert is the same). But in some cases CA can be different (CA certs are rotated periodically, users also can switch from one CA to abother, etc...)

[timofey-barmin]

If, for some reason, you cannot use the same certificate to sign the node's certificates, you must concatenate the intermediate certificates to each node's certificate.
This concatenation make sure the nodes can find a common CA in their chain of trust to identify each other.

I am not sure I understand these phrases. Probably we need to discuss it.
Or we can remove it.

[bfavini]

Great job! Looks good.

[bryandmc]

So the sections I looked at specifically were the ones regarding change of ciphers, change of available tlsMinVersion numbers and gave the rest a quick read and it seems fine to me. Please have other's finish their reviews since I didn't go into detail into sections I didn't cover originally.