vault These are general upgrade instructions for Vault plugins Plugin upgrade procedure Upgrading Vault plugins page title Upgrading Plugins Guides layout docs

Answer:
---
layout: docs
page_title: Upgrading Plugins - Guides
description: These are general upgrade instructions for Vault plugins.
---

# Upgrading Vault plugins

## Plugin upgrade procedure

The following procedures detail steps for upgrading a plugin that has been mounted
at a path on a running server. The steps are the same whether the plugin being
upgraded is built-in or external.

~> [Plugin versioning](/vault/docs/plugins#plugin-versioning) was introduced
  with Vault 1.12.0, so if your Vault server is on 1.11.x or earlier, see the
  [1.11.x version of this page](/vault/docs/v1.11.x/upgrading/plugins)
  for plugin upgrade instructions.

### Upgrading auth and secrets plugins

The process is nearly identical for auth and secret plugins. If you are upgrading
an auth plugin, just replace all usages of `secrets` or `secret` with `auth`.

1. [Register][plugin_registration] the first version of your plugin to the catalog.
   Skip this step if your initial plugin is built-in or already registered.

    ```shell-session
    $ vault plugin register \
        -sha256=<SHA256 Hex value of the plugin binary> \
        secret \
        my-secret-plugin
    Success! Registered plugin: my-secret-plugin
    ```

1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
   is already mounted.

    ```shell-session
    $ vault secrets enable my-secret-plugin
    Success! Enabled the my-secret-plugin secrets engine at: my-secret-plugin/
    ```

1. Register a second version of your plugin. You **must** use the same plugin
   type and name (the last two arguments) as the plugin being upgraded. This is
   true regardless of whether the plugin being upgraded is built-in or external.

    ```shell-session
    $ vault plugin register \
        -sha256=<SHA256 Hex value of the plugin binary> \
        -command=my-secret-plugin-1.0.1 \
        -version=v1.0.1 \
        secret \
        my-secret-plugin
    Success! Registered plugin: my-secret-plugin
    ```

1. Set the new version as the cluster's pinned version.

   ```shell-session
   $ vault write sys/plugins/pins/secret/my-secret-plugin version=v1.0.1
   ```

1. Trigger a global [plugin reload](/vault/docs/commands/plugin/reload) to
   reload all instances of the plugin.

    ```shell-session
    $ vault plugin reload -type=secret -plugin=my-secret-plugin -scope=global
    Success! Reloading plugin: my-secret-plugin, reload_id: 98b1e875-4217-745d-07f2-93d14219fb3c
    ```

1. **Optional:** Check the "Running Version" field to verify the new version is
    running:

    ```shell-session
    $ vault secrets list -detailed
    ```

Until the reload step, the mount will still run the first version of `my-secret-plugin`. When
the reload is triggered, Vault will kill `my-secret-plugin`’s process and start the
new plugin process for `my-secret-plugin` version 1.0.1.

### Upgrading database plugins

1. [Register][plugin_registration] the first version of your plugin to the catalog.
   Skip this step if your initial plugin is built-in or already registered.

    ```shell-session
    $ vault plugin register
        -sha256=<SHA256 Hex value of the plugin binary> \
        database \
        my-db-plugin
    Success! Registered plugin: my-db-plugin
    ```

1. [Mount][plugin_management] the plugin. Skip this step if your initial plugin
   is already mounted.

    ```shell-session
    $ vault secrets enable database
    $ vault write database/config/my-db \
        plugin_name=my-db-plugin \
        # ...
    Success! Data written to: database/config/my-db
    ```

1. Register a second version of your plugin. You **must** use the same plugin
   type and name (the last two arguments) as the plugin being upgraded. This is
   true regardless of whether the plugin being upgraded is built-in or external.

    ```shell-session
    $ vault plugin register \
        -sha256=<SHA256 Hex value of the plugin binary> \
        -command=my-db-plugin-1.0.1 \
        -version=v1.0.1 \
        database \
        my-db-plugin
    Success! Registered plugin: my-db-plugin
    ```

1. Set the new version as the cluster's pinned version.

    ```shell-session
    $ vault write sys/plugins/pins/database/my-db-plugin version=v1.0.1
    ```

1. Trigger a global [plugin reload](/vault/docs/commands/plugin/reload) to
   reload all instances of the plugin.

    ```shell-session
    $ vault plugin reload -type=database -plugin=my-db-plugin -scope=global
    Success! Reloading plugin: my-db-plugin, reload_id: 98b1e875-4217-745d-07f2-93d14219fb3c
    ```

1. **Optional:** Verify the current version of the running plugin:

    ```shell-session
    $ vault read database/config/my-db
    ```

Until the reload step, the mount will still run the first version of `my-db-plugin`. When
the reload is triggered, Vault will kill `my-db-plugin`’s process and start the
new plugin process for `my-db-plugin` version 1.0.1.

### Downgrading plugins

Plugin downgrades follow the same procedure as upgrades. You can use the Vault
plugin list command to check what plugin versions are available to downgrade to:

```shell-session
$ vault plugin list secret
Name                Version
----                -------
ad                  v0.14.0+builtin
alicloud            v0.13.0+builtin
aws                 v1.12.0+builtin.vault
azure               v0.14.0+builtin
cassandra           v1.12.0+builtin.vault
consul              v1.12.0+builtin.vault
gcp                 v0.14.0+builtin
gcpkms              v0.13.0+builtin
kv                  v0.13.3+builtin
ldap                v1.12.0+builtin.vault
mongodb             v1.12.0+builtin.vault
mongodbatlas        v0.8.0+builtin
mssql               v1.12.0+builtin.vault
mysql               v1.12.0+builtin.vault
nomad               v1.12.0+builtin.vault
openldap            v0.9.0+builtin
pki                 v1.12.0+builtin.vault
postgresql          v1.12.0+builtin.vault
rabbitmq            v1.12.0+builtin.vault
ssh                 v1.12.0+builtin.vault
terraform           v0.6.0+builtin
totp                v1.12.0+builtin.vault
transit             v1.12.0+builtin.vault
```

### Additional upgrade notes

* As mentioned earlier, disabling existing mounts will wipe the existing data.
* Overwriting an existing version in the catalog will affect all uses of that
  plugin version. So if you have 5 different Azure Secrets mounts using v1.0.0,
  they'll all start using the new binary if you overwrite it. We recommend
  treating plugin versions in the catalog as immutable, much like version control
  tags.
* Each plugin has its own data within Vault storage. While it is rare for HashiCorp
  maintained plugins to update their storage schema, it is up to plugin authors
  to manage schema upgrades and downgrades. Check the plugin release notes for
  any unsupported upgrade or downgrade transitions, especially before moving to
  a new major version or downgrading.
* Existing Vault [leases](/vault/docs/concepts/lease) and [tokens](/vault/docs/concepts/tokens)
  are generally unaffected by plugin upgrades and reloads. This is because the lifecycle
  of leases and tokens is handled by core systems within Vault. The plugin itself only
  handles renewal and revocation of them when it’s requested by those core systems.

[plugin_reload_api]: /vault/api-docs/system/plugins-reload
[plugin_registration]: /vault/docs/plugins/plugin-architecture#plugin-registration
[plugin_management]: /vault/docs/plugins/plugin-management#enabling-disabling-external-plugins

layout  docs page title  Upgrading Plugins   Guides description  These are general upgrade instructions for Vault plugins         Upgrading Vault plugins     Plugin upgrade procedure  The following procedures detail steps for upgrading a plugin that has been mounted at a path on a running server  The steps are the same whether the plugin being upgraded is built in or external       Plugin versioning   vault docs plugins plugin versioning  was introduced   with Vault 1 12 0  so if your Vault server is on 1 11 x or earlier  see the    1 11 x version of this page   vault docs v1 11 x upgrading plugins    for plugin upgrade instructions       Upgrading auth and secrets plugins  The process is nearly identical for auth and secret plugins  If you are upgrading an auth plugin  just replace all usages of  secrets  or  secret  with  auth    1   Register  plugin registration  the first version of your plugin to the catalog     Skip this step if your initial plugin is built in or already registered          shell session       vault plugin register            sha256  SHA256 Hex value of the plugin binary            secret           my secret plugin     Success  Registered plugin  my secret plugin          1   Mount  plugin management  the plugin  Skip this step if your initial plugin    is already mounted          shell session       vault secrets enable my secret plugin     Success  Enabled the my secret plugin secrets engine at  my secret plugin           1  Register a second version of your plugin  You   must   use the same plugin    type and name  the last two arguments  as the plugin being upgraded  This is    true regardless of whether the plugin being upgraded is built in or external          shell session       vault plugin register            sha256  SHA256 Hex value of the plugin binary             command my secret plugin 1 0 1            version v1 0 1           secret           my secret plugin     Success  Registered plugin  my secret plugin          1  Set the new version as the cluster s pinned version         shell session      vault write sys plugins pins secret my secret plugin version v1 0 1         1  Trigger a global  plugin reload   vault docs commands plugin reload  to    reload all instances of the plugin          shell session       vault plugin reload  type secret  plugin my secret plugin  scope global     Success  Reloading plugin  my secret plugin  reload id  98b1e875 4217 745d 07f2 93d14219fb3c          1    Optional    Check the  Running Version  field to verify the new version is     running          shell session       vault secrets list  detailed          Until the reload step  the mount will still run the first version of  my secret plugin   When the reload is triggered  Vault will kill  my secret plugin  s process and start the new plugin process for  my secret plugin  version 1 0 1       Upgrading database plugins  1   Register  plugin registration  the first version of your plugin to the catalog     Skip this step if your initial plugin is built in or already registered          shell session       vault plugin register          sha256  SHA256 Hex value of the plugin binary            database           my db plugin     Success  Registered plugin  my db plugin          1   Mount  plugin management  the plugin  Skip this step if your initial plugin    is already mounted          shell session       vault secrets enable database       vault write database config my db           plugin name my db plugin                     Success  Data written to  database config my db          1  Register a second version of your plugin  You   must   use the same plugin    type and name  the last two arguments  as the plugin being upgraded  This is    true regardless of whether the plugin being upgraded is built in or external          shell session       vault plugin register            sha256  SHA256 Hex value of the plugin binary             command my db plugin 1 0 1            version v1 0 1           database           my db plugin     Success  Registered plugin  my db plugin          1  Set the new version as the cluster s pinned version          shell session       vault write sys plugins pins database my db plugin version v1 0 1          1  Trigger a global  plugin reload   vault docs commands plugin reload  to    reload all instances of the plugin          shell session       vault plugin reload  type database  plugin my db plugin  scope global     Success  Reloading plugin  my db plugin  reload id  98b1e875 4217 745d 07f2 93d14219fb3c          1    Optional    Verify the current version of the running plugin          shell session       vault read database config my db          Until the reload step  the mount will still run the first version of  my db plugin   When the reload is triggered  Vault will kill  my db plugin  s process and start the new plugin process for  my db plugin  version 1 0 1       Downgrading plugins  Plugin downgrades follow the same procedure as upgrades  You can use the Vault plugin list command to check what plugin versions are available to downgrade to      shell session   vault plugin list secret Name                Version                             ad                  v0 14 0 builtin alicloud            v0 13 0 builtin aws                 v1 12 0 builtin vault azure               v0 14 0 builtin cassandra           v1 12 0 builtin vault consul              v1 12 0 builtin vault gcp                 v0 14 0 builtin gcpkms              v0 13 0 builtin kv                  v0 13 3 builtin ldap                v1 12 0 builtin vault mongodb             v1 12 0 builtin vault mongodbatlas        v0 8 0 builtin mssql               v1 12 0 builtin vault mysql               v1 12 0 builtin vault nomad               v1 12 0 builtin vault openldap            v0 9 0 builtin pki                 v1 12 0 builtin vault postgresql          v1 12 0 builtin vault rabbitmq            v1 12 0 builtin vault ssh                 v1 12 0 builtin vault terraform           v0 6 0 builtin totp                v1 12 0 builtin vault transit             v1 12 0 builtin vault          Additional upgrade notes    As mentioned earlier  disabling existing mounts will wipe the existing data    Overwriting an existing version in the catalog will affect all uses of that   plugin version  So if you have 5 different Azure Secrets mounts using v1 0 0    they ll all start using the new binary if you overwrite it  We recommend   treating plugin versions in the catalog as immutable  much like version control   tags    Each plugin has its own data within Vault storage  While it is rare for HashiCorp   maintained plugins to update their storage schema  it is up to plugin authors   to manage schema upgrades and downgrades  Check the plugin release notes for   any unsupported upgrade or downgrade transitions  especially before moving to   a new major version or downgrading    Existing Vault  leases   vault docs concepts lease  and  tokens   vault docs concepts tokens    are generally unaffected by plugin upgrades and reloads  This is because the lifecycle   of leases and tokens is handled by core systems within Vault  The plugin itself only   handles renewal and revocation of them when it s requested by those core systems    plugin reload api    vault api docs system plugins reload  plugin registration    vault docs plugins plugin architecture plugin registration  plugin management    vault docs plugins plugin management enabling disabling external plugins


vault page title Upgrade to Vault 1 15 x Guides for anyone upgrading to 1 15 x from Vault 1 14 x Deprecations important or breaking changes and remediation recommendations layout docs Overview

Answer:
---
layout: docs
page_title: Upgrade to Vault 1.15.x - Guides
description: |-
  Deprecations, important or breaking changes, and remediation recommendations
  for anyone upgrading to 1.15.x from Vault 1.14.x.
---

# Overview

The Vault 1.15.x upgrade guide contains information on deprecations, important
or breaking changes, and remediation recommendations for anyone upgrading from
Vault 1.14. **Please read carefully**.

## Consul service registration

As of version 1.15, `service_tags` supplied to Vault for the purpose of [Consul
service registration](/vault/docs/configuration/service-registration/consul#service_tags)
will be **case-sensitive**.

In previous versions of Vault tags were converted to lowercase which led to issues,
for example when tags contained Traefik rules which use case-sensitive method names
such as `Host()`.

If you previously used Consul service registration tags ignoring case, or relied
on the lowercase tags created by Vault, then this change may cause unexpected behavior.

Please audit your Consul storage stanza to ensure that you either:

* Manually convert your `service_tags` to lowercase if required
* Ensure that any system that relies on the tags is aware of the new case-preserving behavior

## Rollback metrics

Vault no longer measures and reports the metrics `vault.rollback.attempts.{MOUNTPOINT}` and `vault.route.rollback.{MOUNTPOINT}` by default. The new default metrics are `vault.rollback.attempts`
and `vault.route.rollback`, which **do not** contain the mount point in the metric name.

To continue measuring `vault.rollback.attempts.{MOUNTPOINT}` and
`vault.route.rollback.{MOUNTPOINT}`, you must explicitly enable mount-specific
metrics in the `telemetry` stanza of your Vault configuration with the
[`add_mount_point_rollback_metrics`](/vault/docs/configuration/telemetry#add_mount_point_rollback_metrics)
option.

## Application of Sentinel Role Governing Policies (RGPs) via identity groups

@include 'application-of-sentinel-rgps-via-identity-groups.mdx'

### Docker image no longer contains `curl`

As of 1.15.13 and later, the `curl` binary is no longer included in the published Docker container
images for Vault and Vault Enterprise. If your workflow depends on `curl` being available in the
container, consider one of the following strategies:

#### Create a wrapper container image

Use the HashiCorp image as a base image to create a new container image with `curl` installed.

```Dockerfile
FROM hashicorp/vault-enterprise
RUN apk add curl
```

**NOTE:** While this is the preferred option it will require managing your own registry and rebuilding new images.

#### Install it at runtime dynamically

When running the image as root (not recommended), you can install it at runtime dynamically by using the `apk` package manager:

```shell-session
docker exec <CONTAINER-ID> apk add curl
```
```shell-session
kubectl exec -ti <NAME> -- apk add curl
```

When running the image as non-root without privilege escalation (recommended) you can use existing
tools to install a static binary of `curl` into the `vault` users home directory:

```shell-session
docker exec <CONTAINER-ID> wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```
```shell-session
kubectl exec -ti <NAME> -- wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```

**NOTE:** When using this option you'll want to verify that the static binary comes from a trusted source.

## Known issues and workarounds

@include 'known-issues/1_15-auto-upgrade.mdx'

@include 'known-issues/transit-managed-keys-panics.mdx'

@include 'known-issues/transit-managed-keys-sign-fails.mdx'

@include 'known-issues/aws-auth-panics.mdx'

@include 'known-issues/ui-collapsed-navbar.mdx'

@include 'known-issues/1_15-audit-file-sighup-does-not-trigger-reload.mdx'

@include 'known-issues/internal-error-namespace-missing-policy.mdx'

@include 'known-issues/ephemeral-loggers-memory-leak.mdx'

@include 'known-issues/sublogger-levels-unchanged-on-reload.mdx'

@include 'known-issues/kv2-url-change.mdx'

@include 'known-issues/expiration-metrics-fatal-error.mdx'

@include 'known-issues/1_15_audit-use-of-log-raw-applies-to-all-devices.mdx'

@include 'known-issues/1_15_openldap-rotate-credentials.mdx'

@include 'known-issues/perf-secondary-many-mounts-deadlock.mdx'

@include 'known-issues/1_15-audit-panic-handling-with-eventlogger.mdx'

@include 'known-issues/ocsp-redirect.mdx'

@include 'known-issues/1_15-audit-vault-enterprise-perf-standby-logs-all-headers.mdx'

@include 'known-issues/perf-standbys-revert-to-standby.mdx'

@include 'known-issues/1_13-reload-census-panic-standby.mdx'

@include 'known-issues/autopilot-upgrade-upgrade-version.mdx'

@include 'known-issues/config_listener_proxy_protocol_behavior_issue.mdx'

@include 'known-issues/duplicate-identity-groups.mdx'

@include 'known-issues/manual-entity-merge-does-not-persist.mdx'

layout  docs page title  Upgrade to Vault 1 15 x   Guides description       Deprecations  important or breaking changes  and remediation recommendations   for anyone upgrading to 1 15 x from Vault 1 14 x         Overview  The Vault 1 15 x upgrade guide contains information on deprecations  important or breaking changes  and remediation recommendations for anyone upgrading from Vault 1 14    Please read carefully        Consul service registration  As of version 1 15   service tags  supplied to Vault for the purpose of  Consul service registration   vault docs configuration service registration consul service tags  will be   case sensitive     In previous versions of Vault tags were converted to lowercase which led to issues  for example when tags contained Traefik rules which use case sensitive method names such as  Host      If you previously used Consul service registration tags ignoring case  or relied on the lowercase tags created by Vault  then this change may cause unexpected behavior   Please audit your Consul storage stanza to ensure that you either     Manually convert your  service tags  to lowercase if required   Ensure that any system that relies on the tags is aware of the new case preserving behavior     Rollback metrics  Vault no longer measures and reports the metrics  vault rollback attempts  MOUNTPOINT   and  vault route rollback  MOUNTPOINT   by default  The new default metrics are  vault rollback attempts  and  vault route rollback   which   do not   contain the mount point in the metric name   To continue measuring  vault rollback attempts  MOUNTPOINT   and  vault route rollback  MOUNTPOINT    you must explicitly enable mount specific metrics in the  telemetry  stanza of your Vault configuration with the   add mount point rollback metrics    vault docs configuration telemetry add mount point rollback metrics  option      Application of Sentinel Role Governing Policies  RGPs  via identity groups   include  application of sentinel rgps via identity groups mdx       Docker image no longer contains  curl   As of 1 15 13 and later  the  curl  binary is no longer included in the published Docker container images for Vault and Vault Enterprise  If your workflow depends on  curl  being available in the container  consider one of the following strategies        Create a wrapper container image  Use the HashiCorp image as a base image to create a new container image with  curl  installed      Dockerfile FROM hashicorp vault enterprise RUN apk add curl        NOTE    While this is the preferred option it will require managing your own registry and rebuilding new images        Install it at runtime dynamically  When running the image as root  not recommended   you can install it at runtime dynamically by using the  apk  package manager      shell session docker exec  CONTAINER ID  apk add curl        shell session kubectl exec  ti  NAME     apk add curl      When running the image as non root without privilege escalation  recommended  you can use existing tools to install a static binary of  curl  into the  vault  users home directory      shell session docker exec  CONTAINER ID  wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        shell session kubectl exec  ti  NAME     wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        NOTE    When using this option you ll want to verify that the static binary comes from a trusted source      Known issues and workarounds   include  known issues 1 15 auto upgrade mdx    include  known issues transit managed keys panics mdx    include  known issues transit managed keys sign fails mdx    include  known issues aws auth panics mdx    include  known issues ui collapsed navbar mdx    include  known issues 1 15 audit file sighup does not trigger reload mdx    include  known issues internal error namespace missing policy mdx    include  known issues ephemeral loggers memory leak mdx    include  known issues sublogger levels unchanged on reload mdx    include  known issues kv2 url change mdx    include  known issues expiration metrics fatal error mdx    include  known issues 1 15 audit use of log raw applies to all devices mdx    include  known issues 1 15 openldap rotate credentials mdx    include  known issues perf secondary many mounts deadlock mdx    include  known issues 1 15 audit panic handling with eventlogger mdx    include  known issues ocsp redirect mdx    include  known issues 1 15 audit vault enterprise perf standby logs all headers mdx    include  known issues perf standbys revert to standby mdx    include  known issues 1 13 reload census panic standby mdx    include  known issues autopilot upgrade upgrade version mdx    include  known issues config listener proxy protocol behavior issue mdx    include  known issues duplicate identity groups mdx    include  known issues manual entity merge does not persist mdx


vault page title Upgrade to Vault 1 17 x Guides Deprecations important or breaking changes and remediation recommendations layout docs for anyone upgrading to 1 17 x from Vault 1 16 x Overview

Answer:
---
layout: docs
page_title: Upgrade to Vault 1.17.x - Guides
description: |-
  Deprecations, important or breaking changes, and remediation recommendations
  for anyone upgrading to 1.17.x from Vault 1.16.x.
---

# Overview

The Vault 1.17.x upgrade guide contains information on deprecations, important
or breaking changes, and remediation recommendations for anyone upgrading from
Vault 1.16. **Please read carefully**.

## Important changes

### Allowed audit headers now have unremovable defaults

The [config auditing API endpoint](/vault/api-docs/system/config-auditing#create-update-audit-request-header)
tells Vault to log incoming request headers (when present) in the audit log.

Previously, Vault only logged headers that were explicitly configured for
logging. As of version 1.17, Vault automatically logs a predefined set of
[default headers](/vault/docs/audit#default-headers). By default, the header
values are not HMAC encrypted. You must explicitly configure the
[HMAC setting](/vault/api-docs/system/config-auditing#hmac) for each of the
default headers if required.

Refer to the
[audit request headers documentation](/vault/docs/audit#audit-request-headers)
for more information.

### PKI sign-intermediate now truncates notAfter field to signing issuer

Prior to 1.17.x, Vault allowed the calculated sign-intermediate `notAfter` field
to go beyond the signing issuer `notAfter` field. The extended value lead to a
CA chain that would not validate properly. As of 1.17.x, Vault truncates the
intermediary `notAfter` value to the signing issuer `notAfter` if the calculated
field is greater.

#### How to opt out

You can use the new `enforce_leaf_not_after_behavior` flag on the
sign-intermediate API along with the `leaf_not_after_behavior` flag for the
signing issuer to opt out of the truncating behavior.

When you set `enforce_leaf_not_after_behavior` to true, the sign-intermediate
API uses the `leaf_not_after_behavior` value configured for the signing issuer
to control truncation the behavior. Setting the issuer `leaf_not_after_behavior`
field to `permit` and `enforce_leaf_not_after_behavior` to true restores the
legacy behavior.

### Request limiter deprecation

Vault 1.16.0 included an experimental request limiter. The limiter was disabled
by default. Further testing indicated that an alternative approach improves
performance and reduces risk for many workloads. Vault 1.17.0 includes a
new [adaptive overload
protection](/vault/docs/concepts/adaptive-overload-protection) feature that
prevents outages when Vault is overwhelmed by write requests. Adaptive overload
protection is a beta feature in 1.17.0 and is disabled by default.

The beta request limiter will be removed from Vault entirely in a later release.

### JWT auth login requires bound audiences on the role

The `bound_audiences` parameter of "jwt" roles is **mandatory** if the JWT contains an audience
(which is more often than not the case), and **must** match at least one of
the JWT's associated `aud` claims. The `aud` claim claim can be a single string
or a list of strings as per [RFC 7519 Section 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3).
If the JWT's `aud` claim is not set, then the role's `bound_audiences`
parameter is not required.

Users may not be able to log into Vault if the JWT role is configured
incorrectly. For additional details, refer to the
[JWT auth method (API)](/vault/api-docs/auth/jwt) documentation.

### Activity Log Changes

#### Default Activity Log Querying Period

As of 1.17.9 and later, the field `default_report_months` can no longer be configured or read. Any previously set values
will be ignored by the system.

Attempts to modify `default_report_months` through the
[/sys/internal/counters/config](/vault/api-docs/system/internal-counters#update-the-client-count-configuration)
endpoint, will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

  ```shell-session

  WARNING! The following warnings were returned from Vault:

  * default_report_months is deprecated: defaulting to billing start time

  ```

</CodeBlockConfig>

The `current_billing_period` toggle for `/sys/internal/counters/activity` is also deprecated, as this will be set
true by default.

Attempts to set `current_billing_period` will result in the following warning from Vault:

<CodeBlockConfig hideClipboard>

  ```shell-session

  WARNING! The following warnings were returned from Vault:

  * current_billing_period is deprecated; unless otherwise specified, all requests will default to the current billing period

  ```

</CodeBlockConfig>

### Auto-rolled billing start date

As of 1.17.3 and later, the billing start date (license start date if not configured) rolls over to the latest billing year at the end of the last cycle.

@include 'auto-roll-billing-start.mdx'

@include 'auto-roll-billing-start-example.mdx'

### Docker image no longer contains `curl`

As of 1.17.3 and later, the `curl` binary is no longer included in the published Docker container
images for Vault and Vault Enterprise. If your workflow depends on `curl` being available in the
container, consider one of the following strategies:

#### Create a wrapper container image

Use the HashiCorp image as a base image to create a new container image with `curl` installed.

```Dockerfile
FROM hashicorp/vault-enterprise
RUN apk add curl
```

**NOTE:** While this is the preferred option it will require managing your own registry and rebuilding new images.

#### Install it at runtime dynamically

When running the image as root (not recommended), you can install it at runtime dynamically by using the `apk` package manager:

```shell-session
docker exec <CONTAINER-ID> apk add curl
```
```shell-session
kubectl exec -ti <NAME> -- apk add curl
```

When running the image as non-root without privilege escalation (recommended) you can use existing
tools to install a static binary of `curl` into the `vault` users home directory:

```shell-session
docker exec <CONTAINER-ID> wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```
```shell-session
kubectl exec -ti <NAME> -- wget https://github.com/moparisthebest/static-curl/releases/latest/download/curl-amd64 -O /home/vault/curl && chmod +x /home/vault/curl
```

**NOTE:** When using this option you'll want to verify that the static binary comes from a trusted source.

### Product usage reporting

As of 1.17.9, Vault will collect anonymous product usage metrics for HashiCorp. This information will be collected
alongside client activity data, and will be sent automatically if automated reporting is configured, or added to manual
reports if manual reporting is preferred.

See the main page for [Vault product usage metrics reporting](/vault/docs/enterprise/license/product-usage-reporting) for
more details, and information about opt-out.

## Known issues and workarounds

@include 'known-issues/1_17_audit-log-hmac.mdx'

@include 'known-issues/ocsp-redirect.mdx'

@include 'known-issues/agent-and-proxy-excessive-cpu-1-17.mdx'

@include 'known-issues/config_listener_proxy_protocol_behavior_issue.mdx'

@include 'known-issues/transit-input-on-cmac-response.mdx'

@include 'known-issues/dangling-entity-aliases-in-memory.mdx'

@include 'known-issues/duplicate-identity-groups.mdx'

@include 'known-issues/manual-entity-merge-does-not-persist.mdx'

@include 'known-issues/aws-auth-external-id.mdx'

@include 'known-issues/sync-activation-flags-cache-not-updated.mdx'

@include 'known-issues/duplicate-hsm-key.mdx'

layout  docs page title  Upgrade to Vault 1 17 x   Guides description       Deprecations  important or breaking changes  and remediation recommendations   for anyone upgrading to 1 17 x from Vault 1 16 x         Overview  The Vault 1 17 x upgrade guide contains information on deprecations  important or breaking changes  and remediation recommendations for anyone upgrading from Vault 1 16    Please read carefully        Important changes   a id  audit headers          Allowed audit headers now have unremovable defaults  The  config auditing API endpoint   vault api docs system config auditing create update audit request header  tells Vault to log incoming request headers  when present  in the audit log   Previously  Vault only logged headers that were explicitly configured for logging  As of version 1 17  Vault automatically logs a predefined set of  default headers   vault docs audit default headers   By default  the header values are not HMAC encrypted  You must explicitly configure the  HMAC setting   vault api docs system config auditing hmac  for each of the default headers if required   Refer to the  audit request headers documentation   vault docs audit audit request headers  for more information    a id  pki truncate          PKI sign intermediate now truncates notAfter field to signing issuer  Prior to 1 17 x  Vault allowed the calculated sign intermediate  notAfter  field to go beyond the signing issuer  notAfter  field  The extended value lead to a CA chain that would not validate properly  As of 1 17 x  Vault truncates the intermediary  notAfter  value to the signing issuer  notAfter  if the calculated field is greater        How to opt out  You can use the new  enforce leaf not after behavior  flag on the sign intermediate API along with the  leaf not after behavior  flag for the signing issuer to opt out of the truncating behavior   When you set  enforce leaf not after behavior  to true  the sign intermediate API uses the  leaf not after behavior  value configured for the signing issuer to control truncation the behavior  Setting the issuer  leaf not after behavior  field to  permit  and  enforce leaf not after behavior  to true restores the legacy behavior    a id  request limiter          Request limiter deprecation  Vault 1 16 0 included an experimental request limiter  The limiter was disabled by default  Further testing indicated that an alternative approach improves performance and reduces risk for many workloads  Vault 1 17 0 includes a new  adaptive overload protection   vault docs concepts adaptive overload protection  feature that prevents outages when Vault is overwhelmed by write requests  Adaptive overload protection is a beta feature in 1 17 0 and is disabled by default   The beta request limiter will be removed from Vault entirely in a later release       JWT auth login requires bound audiences on the role  The  bound audiences  parameter of  jwt  roles is   mandatory   if the JWT contains an audience  which is more often than not the case   and   must   match at least one of the JWT s associated  aud  claims  The  aud  claim claim can be a single string or a list of strings as per  RFC 7519 Section 4 1 3  https   datatracker ietf org doc html rfc7519 section 4 1 3   If the JWT s  aud  claim is not set  then the role s  bound audiences  parameter is not required   Users may not be able to log into Vault if the JWT role is configured incorrectly  For additional details  refer to the  JWT auth method  API    vault api docs auth jwt  documentation       Activity Log Changes       Default Activity Log Querying Period  As of 1 17 9 and later  the field  default report months  can no longer be configured or read  Any previously set values will be ignored by the system    Attempts to modify  default report months  through the   sys internal counters config   vault api docs system internal counters update the client count configuration  endpoint  will result in the following warning from Vault    CodeBlockConfig hideClipboard        shell session    WARNING  The following warnings were returned from Vault       default report months is deprecated  defaulting to billing start time            CodeBlockConfig    The  current billing period  toggle for   sys internal counters activity  is also deprecated  as this will be set true by default   Attempts to set  current billing period  will result in the following warning from Vault    CodeBlockConfig hideClipboard        shell session    WARNING  The following warnings were returned from Vault       current billing period is deprecated  unless otherwise specified  all requests will default to the current billing period            CodeBlockConfig       Auto rolled billing start date  As of 1 17 3 and later  the billing start date  license start date if not configured  rolls over to the latest billing year at the end of the last cycle    include  auto roll billing start mdx    include  auto roll billing start example mdx       Docker image no longer contains  curl   As of 1 17 3 and later  the  curl  binary is no longer included in the published Docker container images for Vault and Vault Enterprise  If your workflow depends on  curl  being available in the container  consider one of the following strategies        Create a wrapper container image  Use the HashiCorp image as a base image to create a new container image with  curl  installed      Dockerfile FROM hashicorp vault enterprise RUN apk add curl        NOTE    While this is the preferred option it will require managing your own registry and rebuilding new images        Install it at runtime dynamically  When running the image as root  not recommended   you can install it at runtime dynamically by using the  apk  package manager      shell session docker exec  CONTAINER ID  apk add curl        shell session kubectl exec  ti  NAME     apk add curl      When running the image as non root without privilege escalation  recommended  you can use existing tools to install a static binary of  curl  into the  vault  users home directory      shell session docker exec  CONTAINER ID  wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        shell session kubectl exec  ti  NAME     wget https   github com moparisthebest static curl releases latest download curl amd64  O  home vault curl    chmod  x  home vault curl        NOTE    When using this option you ll want to verify that the static binary comes from a trusted source       Product usage reporting  As of 1 17 9  Vault will collect anonymous product usage metrics for HashiCorp  This information will be collected alongside client activity data  and will be sent automatically if automated reporting is configured  or added to manual reports if manual reporting is preferred   See the main page for  Vault product usage metrics reporting   vault docs enterprise license product usage reporting  for more details  and information about opt out      Known issues and workarounds   include  known issues 1 17 audit log hmac mdx    include  known issues ocsp redirect mdx    include  known issues agent and proxy excessive cpu 1 17 mdx    include  known issues config listener proxy protocol behavior issue mdx    include  known issues transit input on cmac response mdx    include  known issues dangling entity aliases in memory mdx    include  known issues duplicate identity groups mdx    include  known issues manual entity merge does not persist mdx    include  known issues aws auth external id mdx    include  known issues sync activation flags cache not updated mdx    include  known issues duplicate hsm key mdx


vault This page contains the list of deprecations and important or breaking changes page title Upgrading to Vault 1 10 x Guides for Vault 1 10 x Please read it carefully layout docs Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 1.10.x - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 1.10.x. Please read it carefully.
---

# Overview

This page contains the list of deprecations and important or breaking changes
for Vault 1.10.x compared to 1.9. Please read it carefully.

## SSH secrets engine

The new default value of `algorithm_signer` for SSH CA roles has been changed
to `rsa-sha2-256` from `ssh-rsa`. Existing roles will be migrated to
explicitly specify the `algorithm_signer=ssh-rsa` for RSA keys if they used
the implicit (empty) default, but newly created roles will use the new default
value (preferring a literal `default` which presently uses `rsa-sha2-256`).

## Etcd v2 API no longer supported

Support for the Etcd v2 API is removed in Vault 1.10. The Etcd v2 API
was deprecated with the release of [Etcd v3.5](https://etcd.io/blog/2021/announcing-etcd-3.5/),
and will be decommissioned in a forthcoming Etcd release.

Users of the `etcd` storage backend with the etcdv2 API that are
upgrading to Vault 1.10 should [migrate](/vault/docs/commands/operator/migrate)
Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1.10.
All storage migrations should have
[backups](/vault/docs/concepts/storage#backing-up-vault-s-persisted-data)
taken prior to migration.

## OTP generation process

Customers passing in OTPs during the process of generating root tokens must modify
the OTP generation to include an additional 2 characters before upgrading so that the
OTP can be xor-ed with the encoded root token. This change was implemented as a result
of the change in the prefix from hvs. to s. for service tokens.

## New error response for requests to perf standbys lagging behind active node

The introduction of [Server Side Consistent Tokens](/vault/docs/faq/ssct) means that
when issuing a request to a perf standby right after having obtained a token (e.g.
via login), if the token and its lease haven't yet been replicated to the perf
standby, an HTTP 412 error will be returned.  Before 1.10.0 this typically would've
resulted in a 400, 403, or 50x response.

## Token format change

Token prefixes were updated to be more easily identifiable.

- Service tokens previously started with s. now start with hvs.
- Batch tokens previously started with b. now start with hvb.
- Recovery tokens previously started with r. now start with hvr.

Additionally, non-root service tokens are now longer than before. Previously, service tokens
were 26 characters; they now have a minimum of 95 characters. However, existing tokens will
still work.

Refer to the [Server Side Consistent Token FAQ](/vault/docs/faq/ssct) for details.

## OIDC provider built-in resources

In Vault 1.9, the [OIDC identity provider](/vault/docs/secrets/identity/oidc-provider) feature
was released as a tech preview. In Vault 1.10, built-in resources were introduced to the
OIDC provider system to reduce configuration steps and enhance usability.

The following built-in resources are included in each Vault namespace starting with Vault
1.10:

 - A `default` OIDC provider that's usable by all client applications
 - A `default` key for signing and verification of ID tokens
 - An `allow_all` assignment which authorizes all Vault entities to authenticate via a
   client application

If you created an [OIDC provider](/vault/api-docs/secret/identity/oidc-provider#create-or-update-a-provider)
with the name `default`, [key](/vault/api-docs/secret/identity/tokens#create-a-named-key) with the
name `default`, or [assignment](/vault/api-docs/secret/identity/oidc-provider#create-or-update-an-assignment)
with the name `allow_all` using the Vault 1.9 tech preview, the installation of these built-in
resources will be skipped. We _strongly recommend_ that you delete any existing resources
that have naming collisions before upgrading to Vault 1.10. Failing to delete resources with
naming collisions could result unexpected default behavior. Additionally, we recommend reading
the corresponding details in the OIDC provider [concepts](/vault/docs/concepts/oidc-provider) document
to understand how the built-in resources are used in the system.

## Known issues

@include 'raft-retry-join-failure.mdx'

@include 'raft-panic-old-tls-key.mdx'

@include 'tokenization-rotation-persistence.mdx'

### Errors returned by perf standbys lagging behind active node with consul storage

The introduction of [Server Side Consistent Tokens](/vault/docs/faq/ssct) means that
when issuing a request to a perf standby right after having obtained a token (e.g.
via login), if the token and its lease haven't yet been replicated to the perf
standby, an HTTP 412 error will be returned.  Before 1.10.0 this wouldn't have
resulted in the client seeing errors with Consul storage.

### Single Vault follower restart causes election even with established quorum

We now support Server Side Consistent Tokens (See [Replication](/vault/docs/configuration/replication) and [Vault Eventual Consistency](/vault/docs/enterprise/consistency)), which introduces a new token format that can only be used on nodes of 1.10 or higher version. This new format is enabled by default upon upgrading to the new version. Old format tokens can be read by Vault 1.10, but the new format Vault 1.10 tokens cannot be read by older Vault versions.

For more details, see the [Server Side Consistent Tokens FAQ](/vault/docs/faq/ssct).

Since service tokens are always created on the leader, as long as the leader is not upgraded before performance standbys, service tokens will be of the old format and still be usable during the upgrade process. However, the usual upgrade process we recommend can't be relied upon to always upgrade the leader last. Due to this known [issue](https://github.com/hashicorp/vault/issues/14153), a Vault cluster using Integrated Storage may result in a leader not being upgraded last, and this can trigger a re-election. This re-election can cause the upgraded node to become the leader, resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded. Note that this issue does not impact Vault Community Edition users.

We will have a fix for this issue in Vault 1.10.3. Until this issue is fixed, you may be at risk of having performance standbys unable to service requests until all nodes are upgraded. We recommended that you plan for a maintenance window to upgrade.

### Limited policy shows unhelpful message in UI after mounting a secret engine

When a user has a policy that allows creating a secret engine but not reading it, after successful creation, the user sees a message n is undefined instead of a permissions error. We will have a fix for this issue in an upcoming minor release.

### Adding/Modifying Duo MFA method for enterprise MFA triggers a panic error

When adding or modifying a Duo MFA method for step-up Enterprise MFA using the `sys/mfa/method/duo` endpoint, a panic gets triggered due to a missing schema field. We will have a fix for this in Vault 1.10.1. Until this issue is fixed, avoid making any changes to your Duo configuration if you are upgrading Vault to v1.10.0.

### Sign in to UI using OIDC auth method results in an error

Signing in to the Vault UI using an OIDC auth mount listed in the "tabs" of the form will result
in the following error: "Authentication failed: role with oidc role_type is not allowed".
The auth mounts listed in the "tabs" of the form are those that have [listing_visibility](/vault/api-docs/system/auth#listing_visibility-1)
set to `unauth`.

There is a workaround for this error that will allow you to sign in to Vault using the OIDC
auth method. Select the "Other" tab instead of selecting the specific OIDC auth mount tab.
From there, select "OIDC" from the "Method" select box and proceed to sign in to Vault.

### Login MFA not enforced after restart

A serious bug was identified in the Login MFA feature introduced in 1.10.0:
[#15108](https://github.com/hashicorp/vault/issues/15108).
Upon restart, Vault is not populating its in-memory MFA data structures based
on what is found in storage. Although Vault is persisting to storage MFA methods
and login enforcement configs populated via /identity/mfa, they will effectively
disappear after the process is restarted.

We plan to issue a new 1.10.3 release to address this soon. We recommend delaying
any rollouts of Login MFA until that release.

layout  docs page title  Upgrading to Vault 1 10 x   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 1 10 x  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 1 10 x compared to 1 9  Please read it carefully      SSH secrets engine  The new default value of  algorithm signer  for SSH CA roles has been changed to  rsa sha2 256  from  ssh rsa   Existing roles will be migrated to explicitly specify the  algorithm signer ssh rsa  for RSA keys if they used the implicit  empty  default  but newly created roles will use the new default value  preferring a literal  default  which presently uses  rsa sha2 256        Etcd v2 API no longer supported  Support for the Etcd v2 API is removed in Vault 1 10  The Etcd v2 API was deprecated with the release of  Etcd v3 5  https   etcd io blog 2021 announcing etcd 3 5    and will be decommissioned in a forthcoming Etcd release   Users of the  etcd  storage backend with the etcdv2 API that are upgrading to Vault 1 10 should  migrate   vault docs commands operator migrate  Vault storage to an Etcd v3 cluster prior to upgrading to Vault 1 10  All storage migrations should have  backups   vault docs concepts storage backing up vault s persisted data  taken prior to migration      OTP generation process  Customers passing in OTPs during the process of generating root tokens must modify the OTP generation to include an additional 2 characters before upgrading so that the OTP can be xor ed with the encoded root token  This change was implemented as a result of the change in the prefix from hvs  to s  for service tokens      New error response for requests to perf standbys lagging behind active node  The introduction of  Server Side Consistent Tokens   vault docs faq ssct  means that when issuing a request to a perf standby right after having obtained a token  e g  via login   if the token and its lease haven t yet been replicated to the perf standby  an HTTP 412 error will be returned   Before 1 10 0 this typically would ve resulted in a 400  403  or 50x response      Token format change  Token prefixes were updated to be more easily identifiable     Service tokens previously started with s  now start with hvs    Batch tokens previously started with b  now start with hvb    Recovery tokens previously started with r  now start with hvr   Additionally  non root service tokens are now longer than before  Previously  service tokens were 26 characters  they now have a minimum of 95 characters  However  existing tokens will still work   Refer to the  Server Side Consistent Token FAQ   vault docs faq ssct  for details      OIDC provider built in resources  In Vault 1 9  the  OIDC identity provider   vault docs secrets identity oidc provider  feature was released as a tech preview  In Vault 1 10  built in resources were introduced to the OIDC provider system to reduce configuration steps and enhance usability   The following built in resources are included in each Vault namespace starting with Vault 1 10      A  default  OIDC provider that s usable by all client applications    A  default  key for signing and verification of ID tokens    An  allow all  assignment which authorizes all Vault entities to authenticate via a    client application  If you created an  OIDC provider   vault api docs secret identity oidc provider create or update a provider  with the name  default    key   vault api docs secret identity tokens create a named key  with the name  default   or  assignment   vault api docs secret identity oidc provider create or update an assignment  with the name  allow all  using the Vault 1 9 tech preview  the installation of these built in resources will be skipped  We  strongly recommend  that you delete any existing resources that have naming collisions before upgrading to Vault 1 10  Failing to delete resources with naming collisions could result unexpected default behavior  Additionally  we recommend reading the corresponding details in the OIDC provider  concepts   vault docs concepts oidc provider  document to understand how the built in resources are used in the system      Known issues   include  raft retry join failure mdx    include  raft panic old tls key mdx    include  tokenization rotation persistence mdx       Errors returned by perf standbys lagging behind active node with consul storage  The introduction of  Server Side Consistent Tokens   vault docs faq ssct  means that when issuing a request to a perf standby right after having obtained a token  e g  via login   if the token and its lease haven t yet been replicated to the perf standby  an HTTP 412 error will be returned   Before 1 10 0 this wouldn t have resulted in the client seeing errors with Consul storage       Single Vault follower restart causes election even with established quorum  We now support Server Side Consistent Tokens  See  Replication   vault docs configuration replication  and  Vault Eventual Consistency   vault docs enterprise consistency    which introduces a new token format that can only be used on nodes of 1 10 or higher version  This new format is enabled by default upon upgrading to the new version  Old format tokens can be read by Vault 1 10  but the new format Vault 1 10 tokens cannot be read by older Vault versions   For more details  see the  Server Side Consistent Tokens FAQ   vault docs faq ssct    Since service tokens are always created on the leader  as long as the leader is not upgraded before performance standbys  service tokens will be of the old format and still be usable during the upgrade process  However  the usual upgrade process we recommend can t be relied upon to always upgrade the leader last  Due to this known  issue  https   github com hashicorp vault issues 14153   a Vault cluster using Integrated Storage may result in a leader not being upgraded last  and this can trigger a re election  This re election can cause the upgraded node to become the leader  resulting in the newly created tokens on the leader to be unusable on nodes that have not yet been upgraded  Note that this issue does not impact Vault Community Edition users   We will have a fix for this issue in Vault 1 10 3  Until this issue is fixed  you may be at risk of having performance standbys unable to service requests until all nodes are upgraded  We recommended that you plan for a maintenance window to upgrade       Limited policy shows unhelpful message in UI after mounting a secret engine  When a user has a policy that allows creating a secret engine but not reading it  after successful creation  the user sees a message n is undefined instead of a permissions error  We will have a fix for this issue in an upcoming minor release       Adding Modifying Duo MFA method for enterprise MFA triggers a panic error  When adding or modifying a Duo MFA method for step up Enterprise MFA using the  sys mfa method duo  endpoint  a panic gets triggered due to a missing schema field  We will have a fix for this in Vault 1 10 1  Until this issue is fixed  avoid making any changes to your Duo configuration if you are upgrading Vault to v1 10 0       Sign in to UI using OIDC auth method results in an error  Signing in to the Vault UI using an OIDC auth mount listed in the  tabs  of the form will result in the following error   Authentication failed  role with oidc role type is not allowed   The auth mounts listed in the  tabs  of the form are those that have  listing visibility   vault api docs system auth listing visibility 1  set to  unauth    There is a workaround for this error that will allow you to sign in to Vault using the OIDC auth method  Select the  Other  tab instead of selecting the specific OIDC auth mount tab  From there  select  OIDC  from the  Method  select box and proceed to sign in to Vault       Login MFA not enforced after restart  A serious bug was identified in the Login MFA feature introduced in 1 10 0    15108  https   github com hashicorp vault issues 15108   Upon restart  Vault is not populating its in memory MFA data structures based on what is found in storage  Although Vault is persisting to storage MFA methods and login enforcement configs populated via  identity mfa  they will effectively disappear after the process is restarted   We plan to issue a new 1 10 3 release to address this soon  We recommend delaying any rollouts of Login MFA until that release


vault These are general upgrade instructions for Vault for both non HA and HA page title Upgrading Vault Guides setups Please ensure that you also read the version specific upgrade notes layout docs Upgrading Vault

Answer:
---
layout: docs
page_title: Upgrading Vault - Guides
description: |-
  These are general upgrade instructions for Vault for both non-HA and HA
  setups. Please ensure that you also read the version-specific upgrade notes.
---

# Upgrading Vault

These are general upgrade instructions for Vault for both non-HA and HA setups.
_Please ensure that you also read any version-specific upgrade notes which can be
found in the sidebar._

!> **Important:** Always back up your data before upgrading! Vault does not
make backward-compatibility guarantees for its data store. Simply replacing the
newly-installed Vault binary with the previous version will not cleanly
downgrade Vault, as upgrades may perform changes to the underlying data
structure that make the data incompatible with a downgrade. If you need to roll
back to a previous version of Vault, you should roll back your data store as
well.

Vault upgrades are designed such that large jumps (ie 1.3.10 -> 1.7.x) are
supported. The upgrade notes for each intervening version must be reviewed. The
upgrade notes may describe additional steps or configuration to update before,
during, or after the upgrade.

We also recommend you consult the
[deprecation notices](/vault/docs/deprecation). The notice page includes
a comprehensive list of deprecated features and the Vault versions where
the feature was removed or is scheduled to be removed.

@include 'versions.mdx'

## Integrated storage autopilot

Vault 1.11 introduced [automated
upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) as
part of the Integrated Storage Autopilot feature. If your Vault environment is
configured to use Integrated Storage, consider leveraging this new feature to
upgrade your Vault environment.

-> **Tutorial:** Refer to the [Automate Upgrades with Vault
 Enterprise](/vault/tutorials/raft/raft-upgrade-automation)
 tutorial for more details.

## Agent

The Vault Agent is an API client of the Vault Server. Vault APIs are almost
always backwards compatible. When they are not, this is called out in the
upgrade guide for the new Vault version, and there is a lengthy deprecation
period. The Vault Agent version can lag behind the Vault Server version, though
we recommend keeping all Vault instances up to date with the most recent minor Vault version
to the extent possible.

## Testing the upgrade

It's always a good idea to try to ensure that the upgrade will be successful in
your environment. The ideal way to do this is to take a snapshot of your data
and load it into a test cluster. However, if you are issuing secrets to third
party resources (cloud credentials, database credentials, etc.) ensure that you
do not allow external network connectivity during testing, in case credentials
expire. This prevents the test cluster from trying to revoke these resources
along with the non-test cluster.

## Upgrading from Community to Enterprise editions

Upgrading to Vault Enterprise installations follow the same steps as Community edition upgrades except that the Vault Enterprise binary is to be used and the license file [applied](/vault/api-docs/system/license#install-license), when applicable. The Enterprise binary and license file can be obtained through your HashiCorp sales team.

## Non-HA installations

Upgrading non-HA installations of Vault is as simple as replacing the Vault
binary with the new version and restarting Vault. Any upgrade tasks that can be
performed for you will be taken care of when Vault is unsealed.

Always use `SIGINT` or `SIGTERM` to properly shut down Vault.

Be sure to also read and follow any instructions in the version-specific
upgrade notes.

## HA installations

The recommended upgrade procedure depends on the version of Vault you're currently on and the storage backend of Vault. If you're currently running on Vault 1.11 or later with Integrated Storage and you have Autopilot enabled, you should let Autopilot do the upgrade for you, as that's easier and
less prone to human error. Please refer to our [automated
upgrades](/vault/docs/concepts/integrated-storage/autopilot#automated-upgrades) documentation for information on this feature and our
[Automate Upgrades with Vault
Enterprise](/vault/tutorials/raft/raft-upgrade-automation)
tutorial for more details.

If you're currently on a version of Vault before 1.11, or you've chosen to opt-out the Autopilot automated upgrade features when running Vault after 1.11 with Integrated Storage, or if you are running Vault with other storage backend such as Consul. Please refer to our [Vault HA upgrades Pre 1.11/Without Autopilot Upgrade Automation](/vault/docs/upgrading/vault-ha-upgrade) documentation for more details. Please note that this upgrade procedure also applies if you are upgrading Vault from pre 1.11 to post 1.11.

## Enterprise replication installations

<Note>

Prior to any upgrade, be sure to also read and follow any instructions in the
version-specific upgrade notes which are found in the navigation menu for this
documentation.

</Note>

Upgrading Vault Enterprise clusters which participate in [Enterprise
Replication](/vault/docs/enterprise/replication) requires the following basic
order of operations:

- **Upgrade the replication secondary instances first** using appropriate
  guidance from the previous sections
- Verify functionality of each secondary instance after upgrading
- When satisfied with functionality of upgraded secondary instances, upgrade
  the primary instance

<Note>

It is not safe to replicate from a newer version of Vault to an older version.
When upgrading replicated clusters, ensure that upstream clusters are always on
older versions of Vault than downstream clusters.

</Note>

Here is an example of upgrading four Vault replicated Vault clusters:

![Upgrading multiple replicated clusters](/img/vault-replication-upgrade.png)

In the above scenario, the ideal upgrade procedure would be as follows,
verifying functionality after each cluster upgrade.

1. Upgrade Clusters B and D. These clusters have no downstream clusters, so they
   should be upgraded first, but the ordering of B vs D does not matter.
2. Upgrade Cluster C, which now has an upgraded downstream cluster (Cluster D).
   Because Cluster C is a cluster, it should also use the HA upgrade process.
3. Finally, upgrade Cluster A. All clusters downstream of A will already be
   upgraded. It should be upgraded last, as it is a Performance Primary and a DR
   Primary.

layout  docs page title  Upgrading Vault   Guides description       These are general upgrade instructions for Vault for both non HA and HA   setups  Please ensure that you also read the version specific upgrade notes         Upgrading Vault  These are general upgrade instructions for Vault for both non HA and HA setups   Please ensure that you also read any version specific upgrade notes which can be found in the sidebar         Important    Always back up your data before upgrading  Vault does not make backward compatibility guarantees for its data store  Simply replacing the newly installed Vault binary with the previous version will not cleanly downgrade Vault  as upgrades may perform changes to the underlying data structure that make the data incompatible with a downgrade  If you need to roll back to a previous version of Vault  you should roll back your data store as well   Vault upgrades are designed such that large jumps  ie 1 3 10    1 7 x  are supported  The upgrade notes for each intervening version must be reviewed  The upgrade notes may describe additional steps or configuration to update before  during  or after the upgrade   We also recommend you consult the  deprecation notices   vault docs deprecation   The notice page includes a comprehensive list of deprecated features and the Vault versions where the feature was removed or is scheduled to be removed    include  versions mdx      Integrated storage autopilot  Vault 1 11 introduced  automated upgrades   vault docs concepts integrated storage autopilot automated upgrades  as part of the Integrated Storage Autopilot feature  If your Vault environment is configured to use Integrated Storage  consider leveraging this new feature to upgrade your Vault environment        Tutorial    Refer to the  Automate Upgrades with Vault  Enterprise   vault tutorials raft raft upgrade automation   tutorial for more details      Agent  The Vault Agent is an API client of the Vault Server  Vault APIs are almost always backwards compatible  When they are not  this is called out in the upgrade guide for the new Vault version  and there is a lengthy deprecation period  The Vault Agent version can lag behind the Vault Server version  though we recommend keeping all Vault instances up to date with the most recent minor Vault version to the extent possible      Testing the upgrade  It s always a good idea to try to ensure that the upgrade will be successful in your environment  The ideal way to do this is to take a snapshot of your data and load it into a test cluster  However  if you are issuing secrets to third party resources  cloud credentials  database credentials  etc   ensure that you do not allow external network connectivity during testing  in case credentials expire  This prevents the test cluster from trying to revoke these resources along with the non test cluster      Upgrading from Community to Enterprise editions  Upgrading to Vault Enterprise installations follow the same steps as Community edition upgrades except that the Vault Enterprise binary is to be used and the license file  applied   vault api docs system license install license   when applicable  The Enterprise binary and license file can be obtained through your HashiCorp sales team      Non HA installations  Upgrading non HA installations of Vault is as simple as replacing the Vault binary with the new version and restarting Vault  Any upgrade tasks that can be performed for you will be taken care of when Vault is unsealed   Always use  SIGINT  or  SIGTERM  to properly shut down Vault   Be sure to also read and follow any instructions in the version specific upgrade notes      HA installations  The recommended upgrade procedure depends on the version of Vault you re currently on and the storage backend of Vault  If you re currently running on Vault 1 11 or later with Integrated Storage and you have Autopilot enabled  you should let Autopilot do the upgrade for you  as that s easier and less prone to human error  Please refer to our  automated upgrades   vault docs concepts integrated storage autopilot automated upgrades  documentation for information on this feature and our  Automate Upgrades with Vault Enterprise   vault tutorials raft raft upgrade automation  tutorial for more details   If you re currently on a version of Vault before 1 11  or you ve chosen to opt out the Autopilot automated upgrade features when running Vault after 1 11 with Integrated Storage  or if you are running Vault with other storage backend such as Consul  Please refer to our  Vault HA upgrades Pre 1 11 Without Autopilot Upgrade Automation   vault docs upgrading vault ha upgrade  documentation for more details  Please note that this upgrade procedure also applies if you are upgrading Vault from pre 1 11 to post 1 11      Enterprise replication installations   Note   Prior to any upgrade  be sure to also read and follow any instructions in the version specific upgrade notes which are found in the navigation menu for this documentation     Note   Upgrading Vault Enterprise clusters which participate in  Enterprise Replication   vault docs enterprise replication  requires the following basic order of operations       Upgrade the replication secondary instances first   using appropriate   guidance from the previous sections   Verify functionality of each secondary instance after upgrading   When satisfied with functionality of upgraded secondary instances  upgrade   the primary instance   Note   It is not safe to replicate from a newer version of Vault to an older version  When upgrading replicated clusters  ensure that upstream clusters are always on older versions of Vault than downstream clusters     Note   Here is an example of upgrading four Vault replicated Vault clusters     Upgrading multiple replicated clusters   img vault replication upgrade png   In the above scenario  the ideal upgrade procedure would be as follows  verifying functionality after each cluster upgrade   1  Upgrade Clusters B and D  These clusters have no downstream clusters  so they    should be upgraded first  but the ordering of B vs D does not matter  2  Upgrade Cluster C  which now has an upgraded downstream cluster  Cluster D      Because Cluster C is a cluster  it should also use the HA upgrade process  3  Finally  upgrade Cluster A  All clusters downstream of A will already be    upgraded  It should be upgraded last  as it is a Performance Primary and a DR    Primary


vault This page contains the list of deprecations and important or breaking changes page title Upgrading to Vault 1 12 x Guides layout docs for Vault 1 12 x Please read it carefully Overview

Answer:
---
layout: docs
page_title: Upgrading to Vault 1.12.x - Guides
description: |-
  This page contains the list of deprecations and important or breaking changes
  for Vault 1.12.x. Please read it carefully.
---

# Overview

This page contains the list of deprecations and important or breaking changes
for Vault 1.12.x compared to 1.11. Please read it carefully.

## Changes

### Supported storage backends

Vault Enterprise will now perform a supported storage check at startup. There is no impact on Vault Community Edition users.

@include 'ent-supported-storage.mdx'

@include 'consul-dataplane-upgrade-note.mdx'

### External plugin loading

Vault 1.12.0 introduced a change to how external plugins are loaded. Prior to
Vault 1.12.0 plugins were lazy loaded on startup. This means that plugin
processes were killed after a successful mount and then respawned when a
request is routed to them. Vault 1.12.0 introduced auto mutual TLS for
secrets/auth plugins so we do not lazy load them on startup anymore.

## Known issues

### Pinning to builtin plugin versions may cause failure on upgrade

1.12.0 introduced plugin versions, and with it, the ability to explicitly specify
the builtin version of a plugin when mounting an auth, database or secrets plugin.
For example, `vault auth enable -plugin-version=v1.12.0+builtin.vault approle`. If
there are any mounts where the _builtin_ version was explicitly specified in this way,
Vault may fail to start on upgrading to 1.12.1 due to the specified version no
longer being available.

To check whether a mount path is affected, read the tune information, or the
database config. The affected plugins are `snowflake-database-plugin@v0.6.0+builtin`
and any plugins with `+builtin.vault` metadata in their version.

In this example, the first two mounts are affected because `plugin_version` is
explicitly set and is one of the affected versions. The third mount is not
affected because it only has `+builtin` metadata, and is not the Snowflake
database plugin. All mounts where the version is omitted, or the plugin is
external (regardless of whether the version is specified) are unaffected.

-> **NOTE:** Make sure you use Vault CLI 1.12.0 or later to check mounts.

```shell-session
$ vault read sys/auth/approle/tune
Key                  Value
---                  -----
...
plugin_version       v1.12.0+builtin.vault

$ vault read database/config/snowflake
Key                                   Value
---                                   -----
...
plugin_name                           snowflake-database-plugin
plugin_version                        v0.6.0+builtin

$ vault read sys/auth/kubernetes/tune
Key                  Value
---                  -----
...
plugin_version       v0.14.0+builtin
```

As it is not currently possible to unset the plugin version, there are 3 possible
remediations if you have any affected mounts:

* Upgrade Vault directly to 1.12.2 once released
* Upgrade to an external version of the plugin before upgrading to 1.12.1;
  * Using the [tune API](/vault/api-docs/system/auth#tune-auth-method) for auth methods
  * Using the [tune API](/vault/api-docs/system/mounts#tune-mount-configuration) for secrets plugins
  * Or using the [configure connection](/vault/api-docs/secret/databases#configure-connection)
    API for database plugins
* Unmount and remount the path without a version specified before upgrading to 1.12.1.
  **Note:** This will delete all data and leases associated with the mount.

The bug was introduced by commit
https://github.com/hashicorp/vault/commit/c36330f4c713b886a8a23c08cbbd862a7c530fc8.

#### Impacted versions

Affects upgrading from 1.12.0 to 1.12.1. All other upgrade paths are unaffected.
1.12.2 will introduce a fix that enables upgrades from affected deployments of
1.12.0.

### Mounts associated with deprecated builtin plugins will result in core shutdown on upgrade

As of 1.12.0 Standalone (logical) DB Engines and the AppId Auth Method have been
marked with the `Pending Removal` status. Any attempt to unseal Vault with
mounts backed by one of these builtin plugins will result in an immediate
shutdown of the Vault core.

-> **NOTE** In the event that an external plugin with the same name and type as
a deprecated builtin is deregistered, any subsequent unseal of Vault will also
result in a core shutdown.

```shell-session
$ vault plugin register -sha256=c805cf3b69f704dfcd5176ef1c7599f88adbfd7374e9c76da7f24a32a97abfe1 auth app-id
Success! Registered plugin: app-id
$ vault auth enable -plugin-name=app-id plugin
Success! Enabled app-id auth method at: app-id/
$ vault auth list -detailed
app-id/    app-id    auth_app-id_3a8f2e24    system         system     default-service    replicated     false        false                      map[]      n/a                        0018263c-0d64-7a70-fd5c-50e05c5f5dc3    n/a        n/a                      c805cf3b69f704dfcd5176ef1c7599f88adbfd7374e9c76da7f24a32a97abfe1    n/a
$ vault plugin deregister auth app-id
Success! Deregistered plugin (if it was registered): app-id
$ vault plugin list -detailed | grep "app-id"
app-id                               auth        v1.12.0+builtin.vault                                 pending removal
```

The remediation for affected mounts is to set the
[VAULT_ALLOW_PENDING_REMOVAL_MOUNTS](/vault/docs/commands/server#vault_allow_pending_removal_mounts)
environment variable and replace any `Pending Removal` feature with the
[preferred alternative
feature](/vault/docs/deprecation/faq#q-what-should-i-do-if-i-use-mount-filters-appid-or-any-of-the-standalone-db-engines).

For more information on the phases of deprecation, see the [Deprecation Notices
FAQ](/vault/docs/deprecation/faq#q-what-are-the-phases-of-deprecation).

#### Impacted versions

Affects upgrading from any version of Vault to 1.12.x. All other upgrade paths
are unaffected.

### `vault plugin list` fails when audit logging is enabled

If audit logging is enabled, Vault will fail to audit the response from any
calls to the [`GET /v1/sys/plugins/catalog`](/vault/api-docs/system/plugins-catalog#list-plugins)
endpoint, which causes the whole request to fail and return a 500 internal
server error. From the CLI, this looks like the following:

```shell-session
$ vault plugin list
Error listing available plugins: data from server response is empty
```

It will produce errors in Vault Server's logs such as:

```text
2022-11-30T20:04:22.397Z [ERROR] audit: panic during logging: request_path=sys/plugins/catalog error="reflect: reflect.Value.Set using value obtained using unexported field"
2022-11-30T20:04:22.398Z [ERROR] core: failed to audit response: request_path=sys/plugins/catalog
  error=
  | 1 error occurred:
  | 	* panic generating audit log
  |
```

As a workaround, [listing plugins by type](/vault/api-docs/system/plugins-catalog#list-plugins-1)
will succeed:

* `vault list sys/plugins/catalog/auth`
* `vault list sys/plugins/catalog/database`
* `vault list sys/plugins/catalog/secret`

The bug was introduced by commit
https://github.com/hashicorp/vault/commit/76165052e54f884ed0aa2caa496083dc84ad1c19.

#### Impacted versions

Affects versions 1.12.0, 1.12.1, and 1.12.2. A fix will be released in 1.12.3.

### PKI OCSP GET requests return malformed request responses

If an OCSP GET request contains a '+' character, a malformed request response will be
returned instead of properly processing the request due to a double decoding issue within the
handler.

As a workaround, OCSP POST requests can be used which are unaffected.

#### Impacted versions

Affects version 1.12.3. A fix will be released in 1.12.4.

@include 'tokenization-rotation-persistence.mdx'

@include 'known-issues/ocsp-redirect.mdx'

### LDAP pagination issue

There was a regression introduced in 1.12.6 relating to LDAP maximum page sizes, resulting in
an error `no LDAP groups found in groupDN [...] only policies from locally-defined groups available`.  The issue
occurs when upgrading Vault with an instance that has an existing LDAP Auth configuration.

As a workaround, disable paged searching using the following:
```shell-session
vault write auth/ldap/config max_page_size=-1
```

#### Impacted versions

Affects Vault 1.12.6.

### Slow startup time when storing PKI certificates

There was a regression introduced in 1.12.0 where Vault is slow to start because the
PKI secret engine performs a list operation on the stored certificates. If a large number
of certificates are stored this can cause long start times on active and standby nodes.

There is currently no workaround for this other than limiting the number of certificates stored
in Vault via the [PKI tidy](/vault/api-docs/secret/pki#tidy) or using `no_store`
flag for [PKI roles](/vault/api-docs/secret/pki#createupdate-role).

#### Impacted versions

Affects Vault 1.12.0+

@include 'pki-double-migration-bug.mdx'

layout  docs page title  Upgrading to Vault 1 12 x   Guides description       This page contains the list of deprecations and important or breaking changes   for Vault 1 12 x  Please read it carefully         Overview  This page contains the list of deprecations and important or breaking changes for Vault 1 12 x compared to 1 11  Please read it carefully      Changes      Supported storage backends  Vault Enterprise will now perform a supported storage check at startup  There is no impact on Vault Community Edition users    include  ent supported storage mdx    include  consul dataplane upgrade note mdx       External plugin loading  Vault 1 12 0 introduced a change to how external plugins are loaded  Prior to Vault 1 12 0 plugins were lazy loaded on startup  This means that plugin processes were killed after a successful mount and then respawned when a request is routed to them  Vault 1 12 0 introduced auto mutual TLS for secrets auth plugins so we do not lazy load them on startup anymore      Known issues      Pinning to builtin plugin versions may cause failure on upgrade  1 12 0 introduced plugin versions  and with it  the ability to explicitly specify the builtin version of a plugin when mounting an auth  database or secrets plugin  For example   vault auth enable  plugin version v1 12 0 builtin vault approle   If there are any mounts where the  builtin  version was explicitly specified in this way  Vault may fail to start on upgrading to 1 12 1 due to the specified version no longer being available   To check whether a mount path is affected  read the tune information  or the database config  The affected plugins are  snowflake database plugin v0 6 0 builtin  and any plugins with   builtin vault  metadata in their version   In this example  the first two mounts are affected because  plugin version  is explicitly set and is one of the affected versions  The third mount is not affected because it only has   builtin  metadata  and is not the Snowflake database plugin  All mounts where the version is omitted  or the plugin is external  regardless of whether the version is specified  are unaffected        NOTE    Make sure you use Vault CLI 1 12 0 or later to check mounts      shell session   vault read sys auth approle tune Key                  Value                                plugin version       v1 12 0 builtin vault    vault read database config snowflake Key                                   Value                                                 plugin name                           snowflake database plugin plugin version                        v0 6 0 builtin    vault read sys auth kubernetes tune Key                  Value                                plugin version       v0 14 0 builtin      As it is not currently possible to unset the plugin version  there are 3 possible remediations if you have any affected mounts     Upgrade Vault directly to 1 12 2 once released   Upgrade to an external version of the plugin before upgrading to 1 12 1      Using the  tune API   vault api docs system auth tune auth method  for auth methods     Using the  tune API   vault api docs system mounts tune mount configuration  for secrets plugins     Or using the  configure connection   vault api docs secret databases configure connection      API for database plugins   Unmount and remount the path without a version specified before upgrading to 1 12 1      Note    This will delete all data and leases associated with the mount   The bug was introduced by commit https   github com hashicorp vault commit c36330f4c713b886a8a23c08cbbd862a7c530fc8        Impacted versions  Affects upgrading from 1 12 0 to 1 12 1  All other upgrade paths are unaffected  1 12 2 will introduce a fix that enables upgrades from affected deployments of 1 12 0       Mounts associated with deprecated builtin plugins will result in core shutdown on upgrade  As of 1 12 0 Standalone  logical  DB Engines and the AppId Auth Method have been marked with the  Pending Removal  status  Any attempt to unseal Vault with mounts backed by one of these builtin plugins will result in an immediate shutdown of the Vault core        NOTE   In the event that an external plugin with the same name and type as a deprecated builtin is deregistered  any subsequent unseal of Vault will also result in a core shutdown      shell session   vault plugin register  sha256 c805cf3b69f704dfcd5176ef1c7599f88adbfd7374e9c76da7f24a32a97abfe1 auth app id Success  Registered plugin  app id   vault auth enable  plugin name app id plugin Success  Enabled app id auth method at  app id    vault auth list  detailed app id     app id    auth app id 3a8f2e24    system         system     default service    replicated     false        false                      map        n a                        0018263c 0d64 7a70 fd5c 50e05c5f5dc3    n a        n a                      c805cf3b69f704dfcd5176ef1c7599f88adbfd7374e9c76da7f24a32a97abfe1    n a   vault plugin deregister auth app id Success  Deregistered plugin  if it was registered   app id   vault plugin list  detailed   grep  app id  app id                               auth        v1 12 0 builtin vault                                 pending removal      The remediation for affected mounts is to set the  VAULT ALLOW PENDING REMOVAL MOUNTS   vault docs commands server vault allow pending removal mounts  environment variable and replace any  Pending Removal  feature with the  preferred alternative feature   vault docs deprecation faq q what should i do if i use mount filters appid or any of the standalone db engines    For more information on the phases of deprecation  see the  Deprecation Notices FAQ   vault docs deprecation faq q what are the phases of deprecation         Impacted versions  Affects upgrading from any version of Vault to 1 12 x  All other upgrade paths are unaffected        vault plugin list  fails when audit logging is enabled  If audit logging is enabled  Vault will fail to audit the response from any calls to the   GET  v1 sys plugins catalog    vault api docs system plugins catalog list plugins  endpoint  which causes the whole request to fail and return a 500 internal server error  From the CLI  this looks like the following      shell session   vault plugin list Error listing available plugins  data from server response is empty      It will produce errors in Vault Server s logs such as      text 2022 11 30T20 04 22 397Z  ERROR  audit  panic during logging  request path sys plugins catalog error  reflect  reflect Value Set using value obtained using unexported field  2022 11 30T20 04 22 398Z  ERROR  core  failed to audit response  request path sys plugins catalog   error      1 error occurred         panic generating audit log          As a workaround   listing plugins by type   vault api docs system plugins catalog list plugins 1  will succeed      vault list sys plugins catalog auth     vault list sys plugins catalog database     vault list sys plugins catalog secret   The bug was introduced by commit https   github com hashicorp vault commit 76165052e54f884ed0aa2caa496083dc84ad1c19        Impacted versions  Affects versions 1 12 0  1 12 1  and 1 12 2  A fix will be released in 1 12 3       PKI OCSP GET requests return malformed request responses  If an OCSP GET request contains a     character  a malformed request response will be returned instead of properly processing the request due to a double decoding issue within the handler   As a workaround  OCSP POST requests can be used which are unaffected        Impacted versions  Affects version 1 12 3  A fix will be released in 1 12 4    include  tokenization rotation persistence mdx    include  known issues ocsp redirect mdx       LDAP pagination issue  There was a regression introduced in 1 12 6 relating to LDAP maximum page sizes  resulting in an error  no LDAP groups found in groupDN       only policies from locally defined groups available    The issue occurs when upgrading Vault with an instance that has an existing LDAP Auth configuration   As a workaround  disable paged searching using the following     shell session vault write auth ldap config max page size  1           Impacted versions  Affects Vault 1 12 6       Slow startup time when storing PKI certificates  There was a regression introduced in 1 12 0 where Vault is slow to start because the PKI secret engine performs a list operation on the stored certificates  If a large number of certificates are stored this can cause long start times on active and standby nodes   There is currently no workaround for this other than limiting the number of certificates stored in Vault via the  PKI tidy   vault api docs secret pki tidy  or using  no store  flag for  PKI roles   vault api docs secret pki createupdate role         Impacted versions  Affects Vault 1 12 0    include  pki double migration bug mdx