Upgrade FIPS 1402 -> 1403 (#30576)

* Upgrade FIPS 1402 -> 1403

* Clean up

* changelog

.github/actions/containerize/action.yml

@@ -63,19 +63,19 @@ runs:
             redhat_container_tags='quay.io/redhat-isv-containers/5f89bb9242e382c85087dce2:${{ inputs.vault-version }}-${{ inputs.vault-edition }}-ubi'
             redhat_container_target='ubi-hsm'
           ;;
-          "ent.hsm.fips1402")
+          "ent.hsm.fips1403")
             container_version='${{ inputs.vault-version }}+${{ inputs.vault-edition }}'
             docker_container_tags='docker.io/hashicorp/vault-enterprise:${{ inputs.vault-version }}-${{ inputs.vault-edition}} public.ecr.aws/hashicorp/vault-enterprise:${{ inputs.vault-version }}-${{ inputs.vault-edition }}'
             docker_container_target='ubi-hsm-fips'
             redhat_container_tags='quay.io/redhat-isv-containers/5f89bb9242e382c85087dce2:${{ inputs.vault-version }}-${{ inputs.vault-edition }}-ubi'
             redhat_container_target='ubi-hsm-fips'
           ;;
-          "ent.fips1402")
+          "ent.fips1403")
-            # NOTE: For compatibility we still publish the ent.fips1402 containers to different
+            # NOTE: For compatibility we still publish the ent.fips1403 containers to different
-            # namespaces. All ent, ent.hsm, and ent.hsm.fips1402 containers are released in the
+            # namespaces. All ent, ent.hsm, and ent.hsm.fips1403 containers are released in the
             # enterprise namespaces. After we've updated the upstream docker action to support
             # multiple tags we can start to tag images with both namespaces, publish to both, and
-            # eventually sunset the fips1402 specific namespaces.
+            # eventually sunset the fips1403 specific namespaces.
             container_version='${{ inputs.vault-version }}+${{ inputs.vault-edition }}'
             docker_container_tags='docker.io/hashicorp/vault-enterprise-fips:${{ inputs.vault-version }}-${{ inputs.vault-edition }} public.ecr.aws/hashicorp/vault-enterprise-fips:${{ inputs.vault-version }}-${{ inputs.vault-edition }}'
             docker_container_target='ubi-fips'

.github/workflows/ci.yml

@@ -228,7 +228,7 @@ jobs:
         }
       name: fips
       go-arch: amd64
-      go-tags: '${{ needs.setup.outputs.go-tags }},deadlock,cgo,fips,fips_140_2'
+      go-tags: '${{ needs.setup.outputs.go-tags }},deadlock,cgo,fips,fips_140_3'
       runs-on: ${{ needs.setup.outputs.compute-test-go }}
       runs-on-small: ${{ needs.setup.outputs.compute-small }}
       test-timing-cache-key: go-test-timing-fips

.go-version

@@ -1 +1 @@
-1.24.2
+1.24.3

changelog/30576.txt

@@ -0,0 +1,3 @@
+```release-note: improvement
+core: Updated code and documentation to support FIPS 140-3 compliant algorithms.
+```

command/config/validate_listener.go

@@ -1,12 +0,0 @@
-// Copyright (c) HashiCorp, Inc.
-// SPDX-License-Identifier: BUSL-1.1
-
-//go:build !fips_140_3
-
-package config
-
-import "github.com/hashicorp/vault/internalshared/configutil"
-
-func IsValidListener(listener *configutil.Listener) error {
-	return nil
-}

command/server.go

@@ -38,7 +38,6 @@ import (
 	"github.com/hashicorp/go-secure-stdlib/parseutil"
 	"github.com/hashicorp/go-secure-stdlib/reloadutil"
 	"github.com/hashicorp/vault/audit"
-	config2 "github.com/hashicorp/vault/command/config"
 	"github.com/hashicorp/vault/command/server"
 	"github.com/hashicorp/vault/helper/builtinplugins"
 	"github.com/hashicorp/vault/helper/constants"
@@ -443,7 +442,7 @@ func (c *ServerCommand) parseConfig() (*server.Config, []configutil.ConfigError,
 	}
 
 	if config != nil && config.Entropy != nil && config.Entropy.Mode == configutil.EntropyAugmentation && constants.IsFIPS() {
-		c.UI.Warn("WARNING: Entropy Augmentation is not supported in FIPS 140-2 Inside mode; disabling from server configuration!\n")
+		c.UI.Warn("WARNING: Entropy Augmentation is not supported in FIPS 140-3 Inside mode; disabling from server configuration!\n")
 		config.Entropy = nil
 	}
 	entCheckRequestLimiter(c, config)
@@ -3128,10 +3127,6 @@ func startHttpServers(c *ServerCommand, core *vault.Core, config *server.Config,
 			return fmt.Errorf("found nil listener config after parsing")
 		}
 
-		if err := config2.IsValidListener(ln.Config); err != nil {
-			return err
-		}
-
 		handler := vaulthttp.Handler.Handler(&vault.HandlerProperties{
 			Core:                  core,
 			ListenerConfig:        ln.Config,

enos/enos-dev-scenario-pr-replication.hcl

@@ -21,14 +21,14 @@ scenario "dev_pr_replication" {
     arch              = ["amd64", "arm64"]
     artifact          = ["local", "deb", "rpm", "zip"]
     distro            = ["amzn", "leap", "rhel", "sles", "ubuntu"]
-    edition           = ["ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+    edition           = ["ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
     primary_backend   = ["consul", "raft"]
     primary_seal      = ["awskms", "pkcs11", "shamir"]
     secondary_backend = ["consul", "raft"]
     secondary_seal    = ["awskms", "pkcs11", "shamir"]
 
     exclude {
-      edition = ["ent.hsm", "ent.fips1402", "ent.hsm.fips1402"]
+      edition = ["ent.hsm", "ent.fips1403", "ent.hsm.fips1403"]
       arch    = ["arm64"]
     }
 
@@ -49,12 +49,12 @@ scenario "dev_pr_replication" {
 
     exclude {
       primary_seal = ["pkcs11"]
-      edition      = ["ce", "ent", "ent.fips1402"]
+      edition      = ["ce", "ent", "ent.fips1403"]
     }
 
     exclude {
       secondary_seal = ["pkcs11"]
-      edition        = ["ce", "ent", "ent.fips1402"]
+      edition        = ["ce", "ent", "ent.fips1403"]
     }
   }
 

enos/enos-dev-scenario-single-cluster.hcl

@@ -21,11 +21,11 @@ scenario "dev_single_cluster" {
     artifact = ["local", "deb", "rpm", "zip"]
     backend  = ["consul", "raft"]
     distro   = ["amzn", "leap", "rhel", "sles", "ubuntu"]
-    edition  = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+    edition  = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
     seal     = ["awskms", "pkcs11", "shamir"]
 
     exclude {
-      edition = ["ent.hsm", "ent.fips1402", "ent.hsm.fips1402"]
+      edition = ["ent.hsm", "ent.fips1403", "ent.hsm.fips1403"]
       arch    = ["arm64"]
     }
 
@@ -46,7 +46,7 @@ scenario "dev_single_cluster" {
 
     exclude {
       seal    = ["pkcs11"]
-      edition = ["ce", "ent", "ent.fips1402"]
+      edition = ["ce", "ent", "ent.fips1403"]
     }
   }
 

enos/enos-globals.hcl

@@ -11,9 +11,9 @@ globals {
   build_tags = {
     "ce"               = ["ui"]
     "ent"              = ["ui", "enterprise", "ent"]
-    "ent.fips1402"     = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_2", "ent.fips1402"]
+    "ent.fips1403"     = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_3", "ent.fips1403"]
     "ent.hsm"          = ["ui", "enterprise", "cgo", "hsm", "venthsm"]
-    "ent.hsm.fips1402" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_2", "ent.hsm.fips1402"]
+    "ent.hsm.fips1403" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_3", "ent.hsm.fips1403"]
   }
   config_modes    = ["env", "file"]
   consul_editions = ["ce", "ent"]
@@ -51,7 +51,7 @@ globals {
     sles   = var.distro_version_sles
     ubuntu = var.distro_version_ubuntu
   }
-  editions            = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+  editions            = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
   enterprise_editions = [for e in global.editions : e if e != "ce"]
   ip_versions         = ["4", "6"]
   package_manager = {

enos/enos-scenario-agent.hcl

@@ -58,7 +58,7 @@ scenario "agent" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       seal    = ["pkcs11"]
       edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-autopilot.hcl

@@ -63,10 +63,10 @@ scenario "autopilot" {
     // versions after our initial publication of these editions for arm64.
     exclude {
       arch    = ["arm64"]
-      edition = ["ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+      edition = ["ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       seal    = ["pkcs11"]
       edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-dr-replication.hcl

@@ -65,7 +65,7 @@ scenario "dr_replication" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       primary_seal = ["pkcs11"]
       edition      = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-pr-replication.hcl

@@ -65,7 +65,7 @@ scenario "pr_replication" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       primary_seal = ["pkcs11"]
       edition      = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-proxy.hcl

@@ -58,7 +58,7 @@ scenario "proxy" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       seal    = ["pkcs11"]
       edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-seal-ha.hcl

@@ -63,7 +63,7 @@ scenario "seal_ha" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       primary_seal = ["pkcs11"]
       edition      = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-smoke.hcl

@@ -57,7 +57,7 @@ scenario "smoke" {
       artifact_type   = ["package"]
     }
 
-    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
+    // PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
     exclude {
       seal    = ["pkcs11"]
       edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]

enos/enos-scenario-upgrade.hcl

@@ -64,7 +64,7 @@ scenario "upgrade" {
     // versions after our initial publication of these editions for arm64.
     exclude {
       arch    = ["arm64"]
-      edition = ["ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+      edition = ["ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
     }
 
     // PKCS#11 can only be used with hsm editions

enos/k8s/enos-scenario-k8s.hcl

@@ -11,7 +11,7 @@ scenario "k8s" {
   EOF
 
   matrix {
-    edition = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
+    edition = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
     repo    = ["docker", "ecr", "quay"]
   }
 
@@ -68,7 +68,7 @@ scenario "k8s" {
           tag  = local.tag_version_ubi
         }
       },
-      "ent.fips1402" = {
+      "ent.fips1403" = {
         docker = {
           // https://hub.docker.com/r/hashicorp/vault-enterprise-fips
           repo = "hashicorp/vault-enterprise-fips"
@@ -102,7 +102,7 @@ scenario "k8s" {
           tag  = local.tag_version_ubi
         }
       },
-      "ent.hsm.fips1402" = {
+      "ent.hsm.fips1403" = {
         docker = {
           // https://hub.docker.com/r/hashicorp/vault-enterprise
           repo = "hashicorp/vault-enterprise"

enos/modules/k8s_vault_verify_version/scripts/smoke-verify-version.sh

@@ -27,8 +27,8 @@ case "${VAULT_EDITION}" in
   ce) version_expected="${vault_expected_version}${expected_build_date}" ;;
   ent) version_expected="${vault_expected_version}${expected_build_date}" ;;
   ent.hsm) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
-  ent.fips1402) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
+  ent.fips1403) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
-  ent.hsm.fips1402) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
+  ent.hsm.fips1403) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
   *) fail "(${VAULT_EDITION}) does not match any known Vault editions" ;;
 esac
 

enos/modules/vault_verify_version/scripts/verify-cli-version.sh

@@ -32,8 +32,8 @@ case "$edition" in
   *ce) ;;
   *ent) ;;
   *ent.hsm) version_expected="$version_expected (cgo)" ;;
-  *ent.fips1402) version_expected="$version_expected (cgo)" ;;
+  *ent.fips1403) version_expected="$version_expected (cgo)" ;;
-  *ent.hsm.fips1402) version_expected="$version_expected (cgo)" ;;
+  *ent.hsm.fips1403) version_expected="$version_expected (cgo)" ;;
   *) fail "Unknown Vault edition: ($edition)" ;;
 esac
 

sdk/helper/keysutil/policy_test.go

@@ -16,6 +16,7 @@ import (
 	"fmt"
 	mathrand "math/rand"
 	"reflect"
+	"runtime"
 	"strconv"
 	"strings"
 	"sync"
@@ -991,11 +992,6 @@ func Test_RSA_PSS(t *testing.T) {
 		t.Log(tabs[3], "Make an automatic signature")
 		sig, err := p.Sign(0, nil, input, hashType, sigAlgorithm, marshalingType)
 		if err != nil {
-			// A bit of a hack but FIPS go does not support some hash types
-			if isUnsupportedGoHashType(hashType, err) {
-				t.Skip(tabs[4], "skipping test as FIPS Go does not support hash type")
-				return
-			}
 			t.Fatal(tabs[4], "❌ Failed to automatically sign:", err)
 		}
 
@@ -1192,15 +1188,20 @@ func Test_RSA_PKCS1Signing(t *testing.T) {
 			input = hash.Sum(nil)
 		}
 
+		// Skip over SHA3 hash tests when running with boringcrypto as it still doesn't support it or hasn't been
+		// validated yet. Wasn't available in FIPS-140-2, but should be in FIPS-140-3 eventually?
+		if strings.Contains(runtime.Version(), "X:boringcrypto") {
+			switch hashType {
+			case HashTypeSHA3224, HashTypeSHA3256, HashTypeSHA3384, HashTypeSHA3512:
+				t.Skip(tabs[4], "boringcrypto does not support SHA3")
+				return
+			}
+		}
+
 		// 1. Make a signature with the given key size and hash algorithm.
 		t.Log(tabs[3], "Make an automatic signature")
 		sig, err := p.Sign(0, nil, input, hashType, sigAlgorithm, marshalingType)
 		if err != nil {
-			// A bit of a hack but FIPS go does not support some hash types
-			if isUnsupportedGoHashType(hashType, err) {
-				t.Skip(tabs[4], "skipping test as FIPS Go does not support hash type")
-				return
-			}
 			t.Fatal(tabs[4], "❌ Failed to automatically sign:", err)
 		}
 
@@ -1246,15 +1247,3 @@ func Test_RSA_PKCS1Signing(t *testing.T) {
 		}
 	}
 }
-
-// Normal Go builds support all the hash functions for RSA_PSS signatures but the
-// FIPS Go build does not support at this time the SHA3 hashes as FIPS 140_2 does
-// not accept them.
-func isUnsupportedGoHashType(hashType HashType, err error) bool {
-	switch hashType {
-	case HashTypeSHA3224, HashTypeSHA3256, HashTypeSHA3384, HashTypeSHA3512:
-		return strings.Contains(err.Error(), "unsupported hash function")
-	}
-
-	return false
-}

website/content/api-docs/secret/pki/index.mdx

@@ -410,9 +410,6 @@ engine override the issuer as necessary.
 - `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
   or `ec`.
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-   and thus should not be used: `ed25519`.
-
 - `key_bits` `(int: 0)` - Specifies the number of bits to use for the
   generated keys. Allowed values are 0 (universal default); with
   `key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
@@ -2002,9 +1999,6 @@ used.
 - `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
   or `ec`.
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-   and thus should not be used: `ed25519`.
-
 - `key_bits` `(int: 0)` - Specifies the number of bits to use for the
   generated keys. Allowed values are 0 (universal default); with
   `key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
@@ -2149,9 +2143,6 @@ use the values set via `config/urls`.
 - `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
   or `ec`.
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-   and thus should not be used: `ed25519`.
-
 - `key_bits` `(int: 0)` - Specifies the number of bits to use for the
   generated keys. Allowed values are 0 (universal default); with
   `key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
@@ -2396,9 +2387,6 @@ generated depending on the `type` request parameter.
 - `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
   or `ec`. Not suitable for `type=existing` requests.
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-   and thus should not be used: `ed25519`.
-
 ~> **Note**: Keys of type `rsa` currently only support PKCS#1 v1.5 signatures.
    This includes any managed keys.
 
@@ -3345,9 +3333,6 @@ request is denied.
   When `any` is used, this role cannot generate certificates and can only
   be used to sign CSRs.
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-   and thus should not be used: `ed25519`.
-
 - `key_bits` `(int: 0)` - Specifies the number of bits to use for the
   generated keys. Allowed values are 0 (universal default); with
   `key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;

website/content/api-docs/secret/ssh.mdx

@@ -168,9 +168,6 @@ This endpoint creates or updates a named role.
   with `ecdsa-sha2-nistp256` or `ed25519`), the value of the length is ignored (and
   can be zero).
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `ed25519`.
-
 - `allow_empty_principals` `(bool: false)` - Allow signing certificates with
   no valid principals (e.g. any valid principal).  For backwards
   compatibility only.  The default of false is highly recommended.
@@ -589,9 +586,6 @@ overridden._
   `ecdsa-sha2-nistp384`, `ecdsa-sha2-nistp521`, or `ssh-ed25519`) or an
   algorithm (`rsa`, `ec`, or `ed25519`).
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-      and thus should not be used: `ed25519`.
-
 - `key_bits` `(int: 0)` - Specifies the desired key bits for the generated SSH
   CA key when `generate_signing_key` is set to `true`. This is only used for
   variable length keys (such as `ssh-rsa`, where the value of `key_bits`

website/content/api-docs/secret/transit.mdx

@@ -70,8 +70,8 @@ values set here cannot be changed after key creation.
   - `ml-dsa` - ML-DSA (asymmetric) (experimental) <EnterpriseAlert inline="true" />
   - `hybrid` - hybrid signatures combining a post-quantum algorithm and an elliptic curve algorithm (asymmetric) (experimental) <EnterpriseAlert inline="true" />
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
+  ~> **Note**: In FIPS 140-3 mode, the following algorithms are not certified
-     and thus should not be used: `chacha20-poly1305` and `ed25519`.
+     and thus should not be used: `chacha20-poly1305`.
 
   ~> **Note**: All key types support HMAC through the use of a second randomly
      generated key created key creation time or rotation.  The HMAC key type only
@@ -1270,10 +1270,6 @@ algorithm.
   - `sha3-384`
   - `sha3-512`
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
-     `sha3-512`.
-
 - `input` `(string: <required>)` – Specifies the **base64 encoded** input data.
 
 - `format` `(string: "hex")` – Specifies the output encoding. This can be either
@@ -1340,10 +1336,6 @@ be used.
   - `sha3-384`
   - `sha3-512`
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
-     `sha3-512`.
-
 - `input` `(string: "")` – Specifies the **base64 encoded** input data. One of
   `input` or `batch_input` must be supplied.
 
@@ -1479,10 +1471,6 @@ supports signing.
   - `sha3-512`
   - `none`
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
-     `sha3-512`.
-
   ~> ** Warning:** `sha1` should be considered a compromised algorithm and used
   only for legacy applications. Signing using SHA-1 can be blocked by operators by
   assigning the following policy corresponding to a named key:
@@ -1670,10 +1658,6 @@ or [generate CMAC](#generate-cmac) API calls.
   - `sha3-512`
   - `none`
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
-     `sha3-512`.
-
   ~> ** Warning:** `sha1` should be considered a compromised algorithm. Signatures
   verified using the algorithm could be forgeries. Verification using SHA-1 can
   be blocked by operators by assigning the following policy corresponding to a

website/content/api-docs/system/tools.mdx

@@ -80,10 +80,6 @@ algorithm.
   - `sha3-384`
   - `sha3-512`
 
-  ~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
-     and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
-     `sha3-512`.
-
 - `input` `(string: <required>)` – Specifies the **base64 encoded** input data.
 
 - `format` `(string: "hex")` – Specifies the output encoding. This can be either

website/content/docs/configuration/entropy-augmentation.mdx

@@ -22,7 +22,7 @@ from seals in priority order, using bytes from the first available and online se
 
 A valid Vault Enterprise license is required for Entropy Augmentation.
 
-~> **Warning** This feature is not available with FIPS 140-2 Inside variants of Vault.
+~> **Warning** This feature is not available with FIPS 140-3 Inside variants of Vault.
 
 Additionally, the following software packages and enterprise modules are required for sourcing entropy
 via the [PKCS11 seal](/vault/docs/configuration/seal/pkcs11):

website/content/docs/enterprise/entropy-augmentation.mdx

@@ -10,7 +10,7 @@ description: >-
 @include 'alerts/enterprise-only.mdx'
 
 <Warning>
-  Entropy augmentation <b>is not</b> available with "FIPS 140-2 Inside" variants of
+  Entropy augmentation <b>is not</b> available with "FIPS 140-3 Inside" variants of
   Vault.
 </Warning>
 

website/content/docs/enterprise/fips/fips1403.mdx

@@ -1,26 +1,26 @@
 ---
 layout: docs
-page_title: Built-in FIPS 140-2 support
+page_title: Built-in FIPS 140-3 support
 description: >-
-  Learn about the FIPS build of Vault, which has FIPS 140-2 support built into
+  Learn about the FIPS build of Vault, which has FIPS 140-3 support built into
   the Vault binary for FIPS compliance.
 ---
 
-# Built-in FIPS 140-2 support
+# Built-in FIPS 140-3 support
 
 @include 'alerts/enterprise-only.mdx'
 
-Special builds of Vault Enterprise (marked with a `fips1402` feature name)
+Special builds of Vault Enterprise (marked with a `fips1403` feature name)
-include built-in support for FIPS 140-2 compliance. Unlike using Seal Wrap
+include built-in support for FIPS 140-3 compliance. Unlike using Seal Wrap
 for FIPS compliance, this binary has no external dependencies on a HSM.
 
 To use this feature, you must have an active or trial license for Vault
 Enterprise Plus (HSMs). To start a trial, contact [HashiCorp
 sales](mailto:sales@hashicorp.com).
 
-## Using FIPS 140-2 Vault enterprise
+## Using FIPS 140-3 Vault enterprise
 
-FIPS 140-2 Inside versions of Vault Enterprise behave like non-FIPS versions
+FIPS 140-3 Inside versions of Vault Enterprise behave like non-FIPS versions
 of Vault. No restrictions are placed on algorithms; it is up to the operator
 to ensure Vault remains in a FIPS-compliant mode of operation. This means
 configuring some Secrets Engines to permit a limited set of algorithms (e.g.,
@@ -29,7 +29,7 @@ forbidding ed25519-based CAs with PKI Secrets Engines).
 Because Vault Enterprise may return secrets in plain text, it is important to
 ensure the Vault server's `listener` configuration section utilizes TLS. This
 ensures secrets are transmitted securely from Server to Client. Additionally,
-note that TLSv1.3 will not work with FIPS 140-2 Inside, as HKDF is not a
+note that TLSv1.3 will not work with FIPS 140-3 Inside, as HKDF is not a
 certified primitive. If TLSv1.3 is desired, it is suggested to front Vault
 Server with a FIPS-certified load balancer.
 
@@ -41,8 +41,8 @@ A non-exhaustive list of potential compliance issues include:
  - Using a Derived Key (using HKDF) for Agent auto-authing or the Transit
    Secrets Engine.
  - Using **Entropy Augmentation**: because BoringCrypto uses its internal,
-   FIPS 140-2 approved RNG, it cannot mix entropy from other sources.
+   FIPS 140-3 approved RNG, it cannot mix entropy from other sources.
-   Attempting to use EA with FIPS 140-2 HSM enabled binaries will result
+   Attempting to use EA with FIPS 140-3 HSM enabled binaries will result
    in failures such as `panic: boringcrypto: invalid code execution`.
 
 Hashicorp can only provide general guidance regarding using Vault Enterprise
@@ -50,11 +50,11 @@ in a FIPS-compliant manner. We are not a NIST-certified testing laboratory
 and thus organizations may need to consult an approved auditor for final
 information.
 
-The FIPS 140-2 variant of Vault uses separate binaries; these are available
+The FIPS 140-3 variant of Vault uses separate binaries; these are available
 from the following sources:
 
  - From the [Hashicorp Releases Page](https://releases.hashicorp.com/vault),
-   ending with the `+ent.fips1402` and `+ent.hsm.fips1402` suffixes.
+   ending with the `+ent.fips1403` and `+ent.hsm.fips1403` suffixes.
  - From the [Docker Hub `hashicorp/vault-enterprise-fips`](https://hub.docker.com/r/hashicorp/vault-enterprise-fips)
    container repository.
  - From the [AWS ECR `hashicorp/vault-enterprise-fips`](https://gallery.ecr.aws/hashicorp/vault-enterprise-fips)
@@ -90,15 +90,15 @@ reasons:
 
 As such Hashicorp cannot provide support for workloads that are affected
 either technically or via non-compliance that results from converting
-existing cluster workloads to the FIPS 140-2 Inside binary.
+existing cluster workloads to the FIPS 140-3 Inside binary.
 
 Instead, we suggest leaving the existing cluster in place, and carefully
 consider migration of specific workloads to the FIPS-backed cluster.  
 
 #### Entropy augmentation restrictions
 
-Entropy Augmentation **does not** work with FIPS 140-2 Inside. The internal
+Entropy Augmentation **does not** work with FIPS 140-3 Inside. The internal
-BoringCrypto RNG is FIPS 140-2 certified and does not accept entropy from
+BoringCrypto RNG is FIPS 140-3 certified and does not accept entropy from
 other sources. On Vault 1.11.0 and later, attempting to use Entropy
 Augmentation will result in a warning ("Entropy Augmentation is not supported...")
 and Entropy Augmentation will be disabled.
@@ -121,9 +121,6 @@ Additionally, only the following key types are allowed in TLS chains of trust:
  - RSA 2048, 3072, 4096, 7680, and 8192-bit;
  - ECDSA P-256, P-384, and P-521.
 
-Finally, only TLSv1.2 or higher is supported in FIPS mode. These are in line
-with recent NIST guidance and recommendations.
-
 #### Heterogeneous cluster deployments
 
 Hashicorp does not support mixed deployment scenarios within the same Vault
@@ -137,30 +134,30 @@ the system are not compliant with FIPS.
 
 ## Technical details
 
-Vault Enterprise's FIPS 140-2 Inside binaries rely on a special version of the
+Vault Enterprise's FIPS 140-3 Inside binaries rely on a special version of the
 Go toolchain which include a FIPS-validated BoringCrypto version. To ensure
 your version of Vault Enterprise includes FIPS support, after starting the
 server, make sure you see a line with `Fips: Enabled`, such as:
 
 ```
-                    Fips: FIPS 140-2 Enabled, BoringCrypto version 7
+                    Fips: FIPS 140-3 Enabled, BoringCrypto version 7
 ```
 
-~> **Note**: FIPS 140-2 Inside binaries depend on cgo, which require that a
+~> **Note**: FIPS 140-3 Inside binaries depend on cgo, which require that a
    GNU C Library (glibc) Linux distribution be used to run Vault. We've
    additionally opted to certify only on the AMD64 architecture at this time.
    This means these binaries will not work on Alpine Linux based containers.
 
-### FIPS 140-2 inside and external plugins
+### FIPS 140-3 inside and external plugins
 
 Vault Enterprise's built-in plugins are compiled into the Vault binary using
 the same Go toolchain version that compiled the core Vault; this results in
-these plugins having FIPS 140-2 compliance status as well. This same guarantee
+these plugins having FIPS 140-3 compliance status as well. This same guarantee
 does not apply to external plugins.
 
-### Validating FIPS 140-2 inside
+### Validating FIPS 140-3 inside
 
-To validate that the FIPS 140-2 Inside binary correctly includes BoringCrypto,
+To validate that the FIPS 140-3 Inside binary correctly includes BoringCrypto,
 run `go tool nm` on the binary to get a symbol dump. On non-FIPS builds,
 searching for `goboringcrypto` in the output will yield no results, but on
 FIPS-enabled builds, you'll see many results with this:
@@ -228,30 +225,19 @@ with the FIPS integrity check succeeding.
 
 ### BoringCrypto certification
 
-BoringCrypto Version 7 uses the following FIPS 140-2 Certificate and software
+BoringCrypto Version 7 uses the following FIPS 140-3 Certificate and software
 version:
 
- - NIST CMVP [Certificate #3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678).
+ - NIST CMVP [Certificate #4735](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4735).
- - BoringSSL Release [`ae223d6138807a13006342edfeef32e813246b39`](https://github.com/google/boringssl/commit/ae223d6138807a13006342edfeef32e813246b39).
+ - BoringCrypto software version 2022061300
 
-The following algorithms were certified as part of this release:
+-### Leidos compliance
 
- - RSA in all key sizes greater than or equal to 2048 bits (tested at 2048
+Leidos evaluated Vault for compliance with the FIPS 140-2 version of BoringCrypto.  HashiCorp will be seeking an evaluation against FIPS 140-3 
-   and 3072 bits),
+in the near future.  In the meantime, Vault has not modified it's integration with BoringCrypto since the FIPS 140-2 evaluation except to 
- - ECDSA and ECDH with P-224 (not accessible from Vault), P-256, P-384, and
+enable TLS 1.3 as is now allowed by the standard, and BoringCrypto itself is largely unchanged and has been certified as FIPS 140-3 validated.  
-   P-521,
- - AES symmetric encryption with 128/192/256-bit CBC, ECB, and CRT modes and
-   128/256-bit GCM modes,
- - SHA-1 and SHA-2 (224, 256,384, and 512-bit variants),
- - HMAC+SHA-2 with 224, 256, 384, and 512-bit variants of SHA-2,
- - TLSv1.0/TLSv1.1 and TLSv1.2 KDFs,
- - AES-256 based CRT_DRBG CS-PRNG.
 
-### Leidos compliance
+-What is the difference between Seal Wrap FIPS 140 compliance and the new FIPS Inside compliance?
-
-See the updated [Leidos Compliance Letter (V Entr v1.10.0+entrfips) for FIPS Inside](https://www.datocms-assets.com/2885/1653327036-boringcrypto_compliance_letter_signed.pdf) using the Boring Crypto Libraries for more details. All [past letters](https://www.hashicorp.com/vault-compliance) are also available for reference.
-
-What is the difference between Seal Wrap FIPS 140 compliance and the new FIPS Inside compliance?
 - Only the storage of sensitive entries (seal wrapped entries) is covered by FIPS-validated crypto when using Seal Wrapping.
 - The TLS connection to Vault by clients is not covered by FIPS-validated crypto when using Seal Wrapping (it is when using FIPS 140-2 Inside, per items 1, 2, 7, and 13 in the updated letter).
 - The generation of key material  wasn't using FIPS-validated crypto in the Seal Wrap version (for example, the PKI certificates: item 8 in the updated FIPS 140-2 Inside letter; or SSH module: item 10 in the updated FIPS 140-2 Inside letter).

website/content/docs/enterprise/fips/index.mdx

@@ -14,16 +14,16 @@ is a cryptography-focused certification standard for U.S. Government usage.
 
 Hashicorp's Vault Enterprise supports the modes of FIPS compliance documented below.
 
-## FIPS 140-2 inside
+## FIPS 140-3 inside
 
-Vault Enterprise now includes release flavors with FIPS 140-2 compliant
+Vault Enterprise now includes release flavors with FIPS 140-3 compliant
 cryptography built into the Vault binary. More information on these releases
-can be found on the [FIPS 140-2 Inside](/vault/docs/enterprise/fips/fips1402) page.
+can be found on the [FIPS 140-3 Inside](/vault/docs/enterprise/fips/fips1403) page.
 
 ## Seal wrap
 
 Before our FIPS Inside effort, Vault [depended on](https://www.hashicorp.com/vault-compliance)
-an external HSM for FIPS 140-2 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap)
+an external HSM for FIPS 140-2/3 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap)
 functionality to wrap security relevant keys in an extra layer of encryption.
 
 ## Comparison of versions

website/content/docs/enterprise/sealwrap.mdx

@@ -3,7 +3,7 @@ layout: docs
 page_title: Wrap seals with encryption
 description: >-
   Wrap sealed data with an extra layer of encryption to honor increased
-  compliance and regulatory requirements including FIPS 140-2.
+  compliance and regulatory requirements including FIPS 140-2/3.
 ---
 
 # Wrap seals with encryption
@@ -13,7 +13,7 @@ description: >-
 Vault Enterprise features a mechanism to wrap values with an extra layer of
 encryption for supported [seals](/vault/docs/configuration/seal). This adds an
 extra layer of protection and is useful in some compliance and regulatory
-environments, including FIPS 140-2 environments.
+environments, including FIPS 140-2/3 environments.
 
 To use this feature, you must have an active or trial license for Vault
 Enterprise Plus (HSMs). To start a trial, contact [HashiCorp
@@ -23,10 +23,10 @@ sales](mailto:sales@hashicorp.com).
 
 Your Vault deployments can gain the following benefits by enabling seal wrapping:
 
-- Conformance with FIPS 140-2 directives on Key Storage and Key Transport as [certified by Leidos](/vault/docs/enterprise/sealwrap#fips-140-2-compliance)
+- Conformance with FIPS 140-2/3 directives on Key Storage and Key Transport as [certified by Leidos](/vault/docs/enterprise/sealwrap#fips-140-2-compliance)
 - Supports FIPS level of security equal to HSM
   - For example, if you use Level 3 hardware encryption on an HSM, Vault will be
-    using FIPS 140-2 Level 3 cryptography
+    using FIPS 140-3 Level 3 cryptography
 - Enables Vault deployments in high security [GRC](https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance)
   environments (e.g. PCI-DSS, HIPAA) where FIPS guidelines important for external audits
 - Pathway to use Vault for managing Department of Defense (DOD) or North

website/content/docs/partners/protocols.mdx

@@ -15,10 +15,10 @@ advanced data protection features.
 
 [Vault Enterprise supports IPv6](https://www.hashicorp.com/trust/compliance/vault-enterprise)
 in compliance with OMB Mandate M-21-07 and Federal IPv6 policy requirements
-for the following operating systems and storage backends. 
+for the following operating systems and storage backends.
 
-**Self-attested testing covers functionality related to HSM, FIPS 140-2, and
+**Self-attested testing covers functionality related to HSM, FIPS 140-3, and
-HSM/FIPS 140-2.**
+HSM/FIPS 140-3.**
 
 ## OS validation
 

website/content/docs/secrets/transit/index.mdx

@@ -93,7 +93,7 @@ types also generate separate HMAC keys):
 - `ml-dsa` - ML-DSA; supports signing and signature verification (experimental) <EnterpriseAlert inline="true" />
 - `hybrid` - combination of two signature algorithms; supports signing and signature verification (experimental) <EnterpriseAlert inline="true" />
 
-~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
+~> **Note**: In FIPS 140-3 mode, the following algorithms are not certified
 and thus should not be used: `chacha20-poly1305` and `ed25519`.
 
 ~> **Note**: All key types support HMAC operations through the use of a second randomly

website/data/docs-nav-data.json

@@ -2809,8 +2809,8 @@
             "path": "enterprise/fips"
           },
           {
-            "title": "Built-in FIPS 140-2 support",
+            "title": "Built-in FIPS 140-3 support",
-            "path": "enterprise/fips/fips1402"
+            "path": "enterprise/fips/fips1403"
           },
           {
             "title": "Seal wrap for FIPS compliance",