FIPS 140-2 and Apache APISIX: Deployment Considerations

Jinhua Luo

January 6, 2023

Products

What is FIPS 140-2?

FIPS 140-2 defines security requirements for cryptographic modules. It was superseded by FIPS 140-3. NIST states that active FIPS 140-2 modules can be used for new systems through September 21, 2026; after that date, their certificates move to the Historical List and should not be selected for new federal systems.

The Cryptographic Module Validation Program (CMVP) is jointly operated by NIST and the Canadian Centre for Cyber Security. Accredited laboratories test cryptographic modules, and the CMVP publishes validation certificates for specific module versions and operational environments.

Validation applies to the cryptographic module named on a CMVP certificate. A product does not become FIPS validated merely because it implements an approved algorithm or embeds a validated library. Deployment teams should verify the module version, certificate status, configuration, and operational environment in the official CMVP records.

Security levels of FIPS 140-2

FIPS 140-2 and FIPS 140-3 specify security requirements in areas related to the design and operation of cryptographic modules, including interfaces, roles, authentication, key management, self-tests, and mitigation of attacks. FIPS 140-2 defines four increasing levels:

  • Level 1 sets the basic requirements and permits software implementations on general-purpose systems.
  • Level 2 adds requirements such as tamper evidence and role-based authentication.
  • Level 3 adds stronger physical protection, identity-based authentication, and separation for interfaces that handle sensitive security parameters.
  • Level 4 adds protection against environmental conditions and attempts to detect and respond to physical attacks.

The level alone does not tell you which algorithms, operating systems, or deployment configurations are approved. Those boundaries are defined by the module's validation certificate and Security Policy.

Why FIPS is important?

U.S. federal agencies must use cryptographic modules that meet applicable FIPS 140 requirements when cryptography protects sensitive information. Other organizations may also require a validated module through procurement policy, regulation, or contractual security controls.

Using Apache APISIX with a FIPS-Validated Module

Understand the Compliance Scope

Apache APISIX can use OpenSSL for TLS cryptographic operations. In a deployment with FIPS requirements, use an appropriate validated OpenSSL cryptographic module in its approved mode and confirm that the exact module, version, and operational environment match its CMVP certificate. Whether the complete deployed system satisfies an organization's compliance obligations depends on the full architecture and configuration, not APISIX alone.

Plan the OpenSSL FIPS Provider

Do not build the FIPS provider from a moving OpenSSL branch. OpenSSL publishes a list of validated versions and instructs users to follow the Security Policy for the selected certificate. A newer OpenSSL release may use a validated provider, but it must not build a different provider and represent it as validated.

For a production deployment:

  1. Determine whether the requirement is FIPS 140-2 or FIPS 140-3 and confirm the certificate is active for the intended system.
  2. Select the exact validated provider version and operational environment listed on the CMVP certificate.
  3. Follow that certificate's Security Policy for source, build, installation, integrity checks, and configuration.
  4. Build the OpenResty or APISIX runtime against the intended OpenSSL libraries, then verify the libraries and providers loaded by the running process.
  5. Document the module certificate, runtime versions, configuration, and approved-mode evidence for the compliance review.

The OpenSSL FIPS module guide shows how to load the FIPS and base providers and make approved implementations the default. A configuration for a validated OpenSSL 3 provider follows this structure; use the paths required by the selected Security Policy:

config_diagnostics = 1
openssl_conf = openssl_init

.include /usr/local/openssl-3.0/ssl/fipsmodule.cnf

[openssl_init]
providers = provider_sect
alg_section = algorithm_sect

[provider_sect]
fips = fips_sect
base = base_sect

[base_sect]
activate = 1

[algorithm_sect]
default_properties = fips=yes

Confirm that the expected providers are active and list the algorithms fetched with the fips=yes property:

openssl list -providers
openssl list -digest-algorithms -propquery 'fips=yes'

An MD5 failure by itself is not sufficient evidence of an approved deployment. Verification must also confirm the certificate, provider version, integrity status, configuration, operational environment, and the libraries loaded by APISIX.

Configure a test route

curl http://127.0.0.1:9180/apisix/admin/routes/httpbin -H 'X-API-KEY: YOUR-KEY' -X PUT -i -d '
{
    "uri": "/anything",
    "hosts": ["*.httpbin.org"],
    "methods": ["GET"],
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org": 1
        }
    }
}'

Test validate private key

Test normal case, we exepect it's successful.

Create an auxiliary python script to upload cert:

cfg_ssl.py

import sys
import requests

if len(sys.argv) <= 3:
    print("bad argument")
    sys.exit(1)

with open(sys.argv[1]) as f:
    cert = f.read()

with open(sys.argv[2]) as f:
    key = f.read()

sni = sys.argv[3]
api_key = "YOUR-KEY"

resp = requests.put("http://127.0.0.1:9180/apisix/admin/ssls/1", json={
    "cert": cert,
    "key": key,
    "snis": [sni],
}, headers={
    "X-API-KEY": api_key,
})
print(resp.status_code)
print(resp.text)

Create a bash function to ease key generation:

genkey() {
    keylen=${1:-4096}
    /usr/bin/openssl genrsa -out apisix.key $keylen
    /usr/bin/openssl req -key apisix.key -new -out apisix.csr -subj '/C=/ST=/L=/O=/OU=web/CN=*.httpbin.org'
    /usr/bin/openssl x509 -req -in apisix.csr -signkey apisix.key -out apisix.crt -days 3650 -sha256
}

Test:

cd $(mktemp -d)
genkey 2048
python3 cfg_ssl.py apisix.crt apisix.key '*.httpbin.org'
curl --resolve 'www.httpbin.org:9443:127.0.0.1' https://www.httpbin.org:9443/uuid -vvv -k

Output:

...
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=web; CN=*.httpbin.org
*  start date: Dec 22 05:52:58 2022 GMT
*  expire date: Dec 19 05:52:58 2032 GMT
*  issuer: OU=web; CN=*.httpbin.org
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e125a24e30)
> GET /uuid HTTP/2
> Host: www.httpbin.org:9443
> user-agent: curl/7.68.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< content-type: application/json
< content-length: 53
< date: Thu, 22 Dec 2022 06:35:04 GMT
< access-control-allow-origin: *
< access-control-allow-credentials: true
< server: APISIX/3.0.0
<
{
  "uuid": "1827f239-376f-47ec-9b54-d5addaa8c7f9"
}

Test key smaller than 2048 bits

FIPS does not support RSA keys smaller than 2048 bits. So, let's test if it fails with small key.

genkey 1024
python3 cfg_ssl.py apisix.crt apisix.key '*.httpbin.org'
curl --resolve 'www.httpbin.org:9443:127.0.0.1' https://www.httpbin.org:9443/uuid -vvv -k

Output:

...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error

Conclusion

FIPS validation provides evidence that a specific cryptographic module was tested against defined security requirements. For Apache APISIX deployments, the practical task is to select a validated OpenSSL module, operate it in the approved mode, verify the certificate details, and test that disallowed algorithms are unavailable.

This guide demonstrates a build and test flow, but it does not grant a FIPS certificate to Apache APISIX or to the complete deployment. Confirm the final compliance scope with your security and procurement teams.

For more information about API gateway, please visit our blogs or contact us.

Tags:
APISIX Basics
API Security
Data Management