docs/ssct: service side to server side (#14654)

website/content/docs/configuration/replication.mdx

@@ -45,4 +45,4 @@ replication {
 - `allow_forwarding_via_token` `(string: "")` - When set to `new_token`, requests sent to non-active nodes
   are forwarded if the node does not yet have the token information in storage.
 
-Support for Service Side Consistent Tokens is now available. Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details.
+Support for Server Side Consistent Tokens is now available. Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details.

website/content/docs/enterprise/consistency.mdx

@@ -206,7 +206,7 @@ The replication option [allow_forwarding_via_token](/docs/configuration/replicat
 can be used to enforce requests that would have returned 412s in the
 aforementioned way will be forwarded instead to the active node.
 
-Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details.
+Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details.
 
 ## Client API helpers
 

website/content/docs/faq/ssct.mdx

@@ -1,7 +1,7 @@
 ---
 layout: docs
 page_title: Server Side Consistent Token FAQ
-description: An list of frequently asked questions about service side consistent token
+description: An list of frequently asked questions about server side consistent tokens
 ---
 
 # Server Side Consistent Token FAQ

website/content/docs/release-notes/1.10.mdx

@@ -68,11 +68,11 @@ To address security and compliance needs, customers may require that keys be eit
 
 The work done above to support HSM-backed PKI operations inspired us to consider what other key possession paradigms we could support. This led us to extend the implementation to support Cloud Key Management Systems in addition to HSMs. In Vault 1.10, users may generate new PKI pairs and perform sign/verify certificate workflows, all with those keys never leaving the cloud KMS itself. Vault 1.10 provides support for AWS Key Management Service and Azure Key Vault Key Management Service.
 
-### Server Side Consisten Tokens
+### Server Side Consistent Tokens
 
 Vault’s [eventual consistency](/docs/enterprise/consistency) model precludes read-after-write guarantees when clients interact with performance standbys or performance replication clusters. The [Client Controlled Consistency](/docs/enterprise/consistency#vault-1-7-mitigations) mitigations supported with Vault 1.7 provide ways to achieve consistency through client modifications or by using the agent for proxied requests, which is not possible in all cases. The Server Side Consistent Tokens feature provides an implicit way to achieve consistency by embedding the minimum Write-Ahead-Log state information in the Service tokens returned from logins or token-create requests. This feature introduces changes in the token format and the new tokesn will be the default tokens starting in Vault 1.10. Vault 1.10 is backwards compatible with old tokens.
 
-See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x) and [Service Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10 and the considerations to be aware of prior to selecting an option for your use case.
+See [Replication](/docs/configuration/replication), [Vault Eventual Consistency](/docs/enterprise/consistency), [Upgrade to 1.10](/docs/upgrading/upgrade-to-1.10.x) and [Server Side Consistent Token FAQ](/docs/faq/ssct) to understand the various consistency options available with Vault 1.10 and the considerations to be aware of prior to selecting an option for your use case.
 
 ## Vault Agent Features
 

website/content/docs/upgrading/upgrade-to-1.10.x.mdx

@@ -51,4 +51,4 @@ Additionally, non-root service tokens are now longer than before. Previously, se
 were 26 characters; they now have a minimum of 95 characters. However, existing tokens will
 still work.
 
-Refer to the [Service Side Consistent Token FAQ](/docs/faq/ssct) for details.
+Refer to the [Server Side Consistent Token FAQ](/docs/faq/ssct) for details.