Important News:SafeLogic Announces General Availability of CryptoComply BoringCrypto! Read the announcement.

Request Consultation
Request Consultation

CryptoComply Cryptography Software

Key Capabilities

Entropy

Extended Support

FIPS 140

Cryptography Compliance

Post-Quantum Cryptography

Industries

Use Cases





Apache FIPS 140-3 Implementation with CryptoComply Core


Deploy Apache HTTP Server (TLS termination / reverse proxy) with a FIPS 140-3 validated cryptographic software foundation—without turning your build pipeline and compliance evidence into a custom engineering effort.

Request Technical Walkthrough

 

 

Developer Summary:

What it is: Apache built so TLS operations rely on a FIPS 140-3 validated cryptographic software foundation (OpenSSL-compatible via CryptoComply Core).

What changes?  Build Apache against the validated OpenSSL-compatible foundation, enable SSL modules, and constrain TLS policy (e.g., approved curves).

How to verify: Start Apache and use openssl s_client -tls1_3 to confirm the server reports the CryptoComply OpenSSL version.

What you get:  Validation artifacts, build provenance, and configuration guidance for audit workflows.

The_ASF_Oak_Leaf_Logo_(2025).svg

Talk to an Expert

Quickstart: Build Apache FIPS with CryptoComply Core

This workflow builds Apache from source and links it against SafeLogic’s CryptoComply Core OpenSSL libraries, providing a validated cryptographic foundation.

Prerequisites

tls-1-3-FIPS-use-case-who-is-it-for

Log-In to the Portal

Set environment variables


export OPENSSL_DIR=/usr/local
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
export CPPFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"


Update the dynamic linker


export OPENSSL_CONF=/usr/local/ssl/openssl.cnf
echo "/usr/local/lib" > /etc/ld.so.conf.d/openssl.conf
ldconfig


Download and extract Apache source


wget https://dlcdn.apache.org/httpd/httpd-<version>.tar.gz
tar xzf httpd-<version>.tar.gz
cd httpd-<version>


Configure and build Apache (link against CryptoComply OpenSSL)


export LDFLAGS="-Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags"

./configure \
  --prefix=/opt/apache \
  --enable-ssl \
  --enable-so \
  --with-ssl=/usr/local

make -j"$(nproc)" && make install


Enable SSL modules + TLS policy (example)

This snippet loads the SSL modules, includes the SSL config, and shows an example TLS policy constraint for approved NIST curves.

(Use the same structure as your portal guide; keep certificate paths aligned to your org’s policy.)

Verify the build

1) Run Apache in the foreground


/opt/apache/bin/httpd -DFOREGROUND


2) Connect using OpenSSL with TLS 1.3


openssl s_client -connect localhost:443 -servername localhost -tls1_3


Expected: the response includes the CryptoComply OpenSSL version in the Apache server string (not the system OpenSSL), e.g.


OpenSSL/3.5.5+SL_CC-3.0.0.

Want the Automated Scripts?

SafeLogic provides OS-specific automated build scripts in the portal-delivered use case package to perform the same steps and automatically update openssl.cnf to ensure the FIPS provider is enabled.

Request Consultation

Technical Overview

Validated cryptographic foundation, TLS policy constraints, and evidence requirements

Component / Area Default Behavior (standard Apache) SafeLogic-Approved Approach Notes / Compliance Impact

Cryptographic Foundation

Apache commonly links against the system OpenSSL

 CryptoComply Core (validated cryptographic software for OpenSSL applications; OpenSSL-compatible) Standardizes the TLS cryptographic implementation on a validated foundation.

TLS Policy (curves/groups)

Broad curve support possible depending on defaults

 Constrain to approved NIST curves (example: P-256/P-384) Prevents negotiation of disallowed groups in regulated contexts.

TLS Protocol Version

TLS 1.2/1.3 depending on server config

 Confirm TLS 1.3 is negotiated where required Use openssl s_client -tls1_3 to validate the negotiated protocol and server string.

Evidence & Provenance

Self-asserted build/config

 Validation artifacts + build provenance + configuration guidance Provides a verifiable trail for audits and regulated procurement.

The Compliance Gap with Standard Apache

Apache does not include a built-in “FIPS switch,” and FIPS 140 validation isn’t enforced at the application level. In practice, whether Apache is running in a FIPS-ready way depends on external factors—operating system FIPS enablement, the OpenSSL cryptographic implementation Apache is linked against, and how both OpenSSL and Apache are configured.

That fragmentation means simply enabling TLS (even TLS 1.3) does not guarantee FIPS compliance; you need a validated cryptographic foundation plus verifiable configuration and provenance to make compliance implementable and auditable.

How SafeLogic closes the gap: CryptoComply Core provides a FIPS 140-3 validated, OpenSSL-compatible cryptographic software foundation so Apache can run TLS on a validated implementation without redesigning your deployment. SafeLogic also provides verification steps and an evidence bundle (validation artifacts, build provenance, configuration guidance).

Request Consultation

Access, Rollout, and Evidence

tls13-fips-140-access-rollout-and-evidence

 

How Customers Access it

Customers access required build artifacts through SafeLogic’s Customer Portal and integrate them into internal artifact repositories and CI/CD pipelines.

  • Delivery formats: pre-built artifacts and/or build toolchain integration (based on workflow)
  • Supported platforms (OS/architectures): Portal-provided builds across operating systems and CPU architectures (customers see what they're licensed for)
  • Selecting the right build: locate artifacts by product/version/operating system/architecture and pull into internal repositories/pipelines

Need the exact OS/architecture matrix for your environment?

Talk to an Expert

Typical Rollout

Proof of Concept

Confirm Apache’s role (edge termination vs reverse proxy), TLS policy constraints, and target platforms.

Integration

Build Apache against the validated OpenSSL-compatible foundation and apply policy constraints.

Verification

Confirm TLS 1.3 negotiation and CryptoComply OpenSSL version; assemble evidence.

Deploy

Deploy via standard rollout/monitoring with repeatable build pipelines.

Evidence for Auditors

  • Security policy / validation artifacts for the underlying validated cryptographic implementation (as applicable)
  • Build provenance (versions/config flags) and repeatable build description
  • Configuration/operation guidance (TLS policy constraints, verification steps)

cryptography-security-policy-fips-140-validation-artifacts

Frequently Asked Questions

Is this interoperable with standard TLS clients?

Generally, yes—TLS remains standard. Interoperability depends on the policy constraints you enforce (approved suites/curves).

Does Apache “come FIPS validated”?

No. FIPS 140 validation applies to the underlying cryptographic implementation. The goal is to run Apache TLS on validated cryptographic software and maintain an evidence trail.

How do we verify the server is using the right OpenSSL?

Use openssl s_client -tls1_3 and confirm the response includes the CryptoComply OpenSSL version in the Apache server string.

What artifacts do we get for auditors?

Typically: validation artifacts, build provenance, and configuration guidance aligned to your program requirements.

Does this meet FIPS 140-3 requirements?

CryptoComply provides FIPS 140-3 validated cryptographic software for OpenSSL applications, which teams can use as a validated foundation. Whether your overall deployment “meets FIPS” still depends on your program definition and how the system is built/configured/operated.

For certificates in your company’s name, SafeLogic positions RapidCert to accelerate timelines and MaintainCert to keep certifications current.

What is the impact of the September 2026 FIPS deadline?

NIST will move all FIPS 140-2 certificates to the "Historical List" on September 21, 2026. For Apache teams, this means any new procurement or major FedRAMP updates must use FIPS 140-3 validated cryptographic software. SafeLogic’s approach is designed to bridge this transition seamlessly.

What performance impact should we expect?

Performance depends on workload and platform. Enforcing certain suites/groups can change behavior, so benchmark during POC with your expected configuration and load.

What artifacts do we get for auditors?

Typically:

  • Security policy/validation artifacts (as applicable)
  • Build provenance and repeatable build description
  • Configuration guidance aligned to your program
  • Integration notes mapping runtime/configuration to the validated foundation

Explore More Use Cases

NGINX-logo-small
NGINX-logo-small

NGIX FIPS
Node.js FIPS
Node.js FIPS

Node.js FIPS
wireguard-logo-1
wireguard-logo-1

Wireguard-go FIPS

Ready to Run Apache in Regulated Environments?

Get guidance on approved TLS policy constraints, supported platforms, and the evidence your program requires. Call us at 844-436-2797 or complete the form below.