# Which Problems Are Solved
Enable FIPS 140-3 compliant build.
# How the Problems Are Solved
- Add runtime config validation, if the FIPS flag is enabled fail the
application when a non-compliant hasher is used, or throw a warning when
a legacy verifier is used
- Add a build matrix for FIPS certified build:
- Go binary is built with `GOFIPS140=certified`
- Login container uses a separate base:
[ubi9](https://catalog.redhat.com/en/software/containers/ubi9/ubi/615bcf606feffc5384e8452e)
from redhat which provides a FIPS certified OpenSSL (used by NodeJS TLS
stack)
- Non-FIPS images where already pushed to both Github Container Registry
and Google Artifact Repository (GAR). Fips images are only pushed to the
GAR.
- Tag versions are suffixed `-fips`. So on release the following images
will be additionally available:
```
europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel-login:vX.Y.Z-fips
europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel:vX.Y.Z-fips-debug
europe-docker.pkg.dev/zitadel-common/zitadel-repo/zitadel:vX.Y.Z-fips
```
# Other changes
- Bumb Go toolchain. At least v1.25.10 is required for a
GOFIPS140=certified setting.
# Additional Context
- Closes https://github.com/zitadel/zitadel/issues/4335
- Build [test
run](https://github.com/zitadel/zitadel/actions/runs/27253916052)
pushing FIPS and non-FIPS images
# Which Problems Are Solved
Invalid formatting in the login codebase due to invalid prettier
configuration
# How the Problems Are Solved
Fxed .prettierignore wildcards for login source files
# Additional Changes
Removed .prettierrc file because there is already a prettier.config.mjs
file
# Additional Context
# Which Problems Are Solved
The login container can only serve HTTP. In deployments where a reverse
proxy is not used, operators need the login container to terminate TLS
itself.
Closes#11473
# How the Problems Are Solved
The container now supports optional HTTPS via three environment
variables that match the pattern already used by the backend server:
`ZITADEL_TLS_ENABLED`, `ZITADEL_TLS_CERTPATH`, and
`ZITADEL_TLS_KEYPATH`. When `ZITADEL_TLS_ENABLED` is not set or set to
`false`, behavior is identical to before. When set to `true`, the server
reads the provided certificate and key files and serves HTTPS using the
lower-level `getRequestHandlers` API from Next.js.
The Docker healthcheck was updated to probe the correct scheme
automatically based on the same environment variable.
# Additional Changes
Added a dockerized integration test that verifies both HTTP and HTTPS
modes using testcontainers.
# Additional Context
The TLS path uses `getRequestHandlers` from
`next/dist/server/lib/start-server` instead of `startServer` because the
latter rejects self-signed certificates in production mode. This is the
same internal API that `startServer` itself calls.
---------
Co-authored-by: Copilot <[email protected]>
Tim MöhlmannandGitHub
RamonandGitHub
