Running in FIPS Mode#
The Curity Identity Server runs in FIPS mode only from the dedicated FIPS Docker image that Curity distributes. This page describes that image, how the server is started within it, and how to confirm that FIPS mode is active.
The FIPS Docker image#
FIPS mode depends on a cryptographic environment that cannot be assembled reliably from arbitrary components. To guarantee it, Curity distributes a dedicated FIPS Docker image in which:
- The base is Ubuntu Pro configured for FIPS operation, so that the operating system runs in FIPS mode.
- OpenSSL uses the FIPS-validated provider, and the default (non-validated) provider is disabled.
- The FIPS-validated cryptographic provider and its libraries are bundled, and the server’s native cryptography links against the operating system’s validated OpenSSL.
Running the Curity Identity Server in FIPS mode is supported only from this image. Standard distributions, other base images, and manually assembled environments are not supported for FIPS, because they do not provide the validated cryptographic environment that FIPS mode requires.
Enabling FIPS mode#
Inside the FIPS image, the server is started with the --fips-mode flag:
$IDSVR_HOME/bin/idsvr --fips-mode
The --fips-mode flag can only be used within the FIPS image. Starting the server with it in any other environment is not supported: a standard distribution has neither the bundled FIPS libraries nor a FIPS-configured operating system, and the startup verification described below causes the server to refuse to start.
Enabling FIPS mode causes the server to:
- Restrict the JVM to the FIPS-validated cryptographic provider in approved-only mode, so that only FIPS-approved algorithms are available.
- Use the FIPS keystore format for keys and trust, in place of PKCS#12. See FIPS-approved cryptography for details.
- Enforce approved cryptography when configuration is applied, rejecting any non-approved algorithm.
Startup verification#
Before completing startup, the server confirms that it is genuinely operating in FIPS mode. It checks that the FIPS cryptographic library is present and that the operating system’s OpenSSL reports strict FIPS operation. If either check fails, the server refuses to start.
These checks ensure that a deployment labeled as FIPS cannot silently fall back to non-validated cryptography, and they are the reason --fips-mode only succeeds inside the FIPS image.
Confirming FIPS mode is active#
When FIPS mode is active, the startup log records that the FIPS providers were installed, and the current FIPS state is reported through the Admin API environment information and in the Admin UI.

Performance considerations#
FIPS-validated cryptography can be slower than the cryptography used in a non-FIPS deployment, because operations are restricted to approved algorithms and performed by the validated module. How noticeable this is depends on how much cryptographic work each request involves — such as password hashing, token signing, and TLS handshakes.
Where TLS is a significant part of that cost, terminate TLS in a sidecar or reverse proxy in front of the Curity Identity Server rather than in the server itself. Offloading the TLS handshake reduces the cryptographic work the Identity Server performs per connection.
Installation and command-line tools#
The command-line tools included in the FIPS image — for tasks such as generating keys or bootstrapping a cluster — detect the FIPS environment automatically and run in approved-only mode without a flag. Two commands behave differently in FIPS mode, which is worth noting when scripting an installation, including on Kubernetes:
- The
installcommand skips the interactive database-initialization prompt, so make sure the database is initialized as part of your deployment. - The
convertkskeystore-conversion command is not available, because it produces PKCS#12. See Importing FIPS-compliant keystores for the supported way to import a key.