GeoSolutions engineering brings FIPS compatibility to GeoServer 3

On October 19, 2026 the GeoServer project announced three releases: 3.0.2, 2.28.6 and 2.27.7. For most deployments these are maintenance and security updates. For organizations that must run their geospatial infrastructure under formal cryptographic requirements, 3.0.2 carries something more: a new FIPS community module, developed by GeoSolutions, that lets GeoServer run on top of a FIPS 140-3 validated cryptographic module. In this post we look at what the module enables, the engineering behind it, and what teams should plan before adopting it.

What FIPS compatibility enables

FIPS 140-3 is the United States government standard for cryptographic modules, and a hard requirement in many federal, defense and regulated environments. Software running in those environments is expected to perform all cryptographic operations inside a validated module, operating in its approved mode.

The new FIPS community module makes that possible for GeoServer. It replaces the standard Bouncy Castle library with the FIPS-validated Bouncy Castle build (bc-fips 2.1.2 as the cryptographic provider, bcpkix-fips 2.1.10 for certificates and CMS), registers it ahead of the default Java providers, and runs it in approved-only mode, where requests for non-approved algorithms fail instead of silently falling back. Configuration and user passwords are stored with AES-GCM, the keystore moves to the BCFKS format, and a new FIPS tab under Server Status shows the cryptographic setup at a glance: crypto module state, approved-only mode, operating system FIPS mode, provider position and the algorithms GeoServer needs. The same information is exposed in the module status returned by the REST resource /rest/about/status.json, which is convenient when several instances have to be checked.

The FIPS status page in GeoServer 3.0.2. Image from the GeoServer 3.0.2 release announcement, CC BY.

One distinction matters when evaluating this. FIPS validation applies to the cryptographic module and its conditions of use, not to the products that integrate it. As the NIST CMVP FAQ makes clear, embedding a validated module does not make the embedding product validated. The module gives GeoServer a concrete, reviewable path to FIPS compatibility; compliance of the overall deployment remains something each organization establishes through its own configuration and accreditation process.

The engineering behind it

Making a large Java application work under approved-only cryptography is not a matter of swapping a library. GeoSolutions developed the module together with the core changes and the build-level testing needed to support it. The work, led by Andrea Aime and visible in the public pull requests on the GeoServer repository (#9855 for the main branch and #9880 for the 3.0.x backport, both merged on August 27, 2026), covers three areas:

• Changes across the GeoServer core to make encryption pluggable and compatible with different algorithm sets, including the move from DES to AES for URL parameter encryption and a keystore named after its format.
• The module itself, which installs the validated provider through a new core extension point, reports what it found, and adds the status tab, together with the AES-GCM password encoder and master password provider that the core now offers next to the existing ones.
• The machinery to build and test under FIPS constraints: a Maven profile that builds GeoServer against the FIPS provider across the whole tree and fails if any dependency pulls the regular library back in, a second profile that makes a normal development machine behave like a FIPS one, and scripts for a virtual machine where the real thing is checked.

That last point deserves a word. The module is compiled and tested inside a Rocky Linux 9 virtual machine with FIPS mode enabled. A container is not enough: FIPS mode is a property of the kernel, and a container uses the kernel of its host. On the VM the build runs with FIPS mode active and executes the tests of every module, then the CITE suite (the OGC conformance tests) runs with the kernel, the system crypto policy and the Red Hat Java runtime all in FIPS mode. This is where modules using non-approved algorithms show up. Rocky Linux is a rebuild of RHEL and is fine for testing; organizations that need to pass an accreditation should run on a validated distribution.

Andrea Aime, who led the work, puts it this way: “Making GeoServer run under approved-only cryptography was less about the module and more about the core: encryption had to become pluggable, the tests had to stop assuming a particular set of algorithms, and we needed a build that fails the moment a dependency pulls non-FIPS cryptography back in. The FIPS virtual machine is what catches that; a container cannot, because FIPS mode is a property of the kernel.”

A GeoServer FIPS deployment: the module, the validated provider, and the operating environment. Deployment configuration and validation remain the responsibility of the organization.

The work was commissioned by a leading public safety and security technology company with formal FIPS requirements, which deployed the module in their development and staging environments and ran their own test suite against it before the public release. The result went upstream as a community module rather than staying a private fork, which is the approach we take whenever a customer requirement is of general interest: the customer gets a maintained feature, and every GeoServer user gets the option.

The release announcement also credits GeoSolutions engineers for release testing and the OGC API Maps work by Andrea Aime, and for the GeoFence integration for GeoServer 3 by Emanuele Tajariol. The releases themselves are a community achievement, with contributions and release duties shared with GeoCat, Camptocamp and the other organizations listed in the announcement.

What teams need to plan

The documented path for running GeoServer under FIPS is on Linux, with the operating system and the Java runtime properly configured and the module operating in approved-only mode. Three points deserve attention.

First, a FIPS instance requires a new data directory. An existing data directory cannot be opened in place, because password encoding and keystore format change, and there is no migration tool yet. Unencrypted configuration such as layers, styles and service settings can be carried over, while the security configuration is rebuilt. Second, the module does not configure the operating system: enabling FIPS mode at the OS level is a separate step, and the FIPS status page tells you whether it is active. Third, this is a community module: it is not part of the 3.0.2 extension downloads and is distributed through the GeoServer community builds, so plan the deployment with that in mind, and review extensions and external integrations, since anything performing cryptography outside the validated provider needs to be checked against your requirements.

Maintaining GeoServer in production

Work like this is one example of what it takes to keep GeoServer dependable in demanding environments: changes in the core, upstream maintenance, testing infrastructure, and the follow-through across releases. It is the same engineering that backs our day-to-day support work, from diagnosing production incidents to planning upgrades across versions. Our thanks go to everyone in the GeoServer community who contributed to these releases.

If you are interested in learning more about how we can help you achieve your needs with GeoServer, MapStore, GeoNode and GeoNetwork through our Enterprise Support Services, Professional Training Services and Subscription Services please contact us!

The GeoSolutions team