go-openssl-fips

packaged by Chainguard

Chainguard Container for go-openssl-fips

Container image for building Go applications with FIPS

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/go-openssl-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Go FIPS with OpenSSL

The flexible Go image that allows runtime configuration of FIPS-validated cryptography. By default, this image uses the host's OpenSSL FIPS provider (i.e., the Chainguard FIPS Provider for OpenSSL on Chainguard hosts), and the Go Cryptographic Module as a fallback. The choice between them is configurable at deploy time. This image is for teams running multiple workflows across mixed environments, or teams that want to continue using Chainguard’s FIPS-validated OpenSSL provider to avoid changing CMVP numbers.

The runtime behaviour can be controlled with GODEBUG:

• GODEBUG=cgr_fips=openssl+geomys - the default behaviour of attempting to use the host native OpenSSL in fips mode, and fallback to Go Cryptographic module when OpenSSL is not available
• GODEBUG=cgr_fips=openssl - only use OpenSSL and do not perform fallback to the Go Cryptographic module
• GODEBUG=cgr_fips=geomys - only use the Go Cryptographic Module and do not use OpenSSL.
• GODEBUG=cgr_fips=openssl,fips140=off - use OpenSSL for cryptography, even if it is not in FIPS capable
• GODEBUG=cgr_verbose=1 - can be used to print at binary startup if OpenSSL or Go Cryptographic module is used at runtime

CGO_ENABLED=0 and cross-compliation is also supported, it creates portable binaries that are still dynamically linked and still perform dlopen() to discover OpenSSL at runtime.

This toolchain is based on the microsoft/go and further documentation is available from upstream:

• README covering build and runtime options
• User Guide covering changes to individual golang standard library APIs

Whilst Chainguard FIPS provider for OpenSSL is recommended, the resulting binaries are vendor-agnostic and can be used at runtime with many other OpenSSL FIPS providers on foreign OpenSSL FIPS hosts.

Algorithm Compliance

The following table is derived from Chainguard's cryptographic compliance test suite, run against the upstream Go toolchain in FIPS mode and the RENO_NAME build. It shows, for a subset of algorithms and operations, whether each is permitted at runtime — highlighting the key differences in what is blocked.

A ⚠️ Allowed marker indicates an operation that upstream Go in FIPS mode permits but which is legacy, deprecated, non-approved, or disallowed — it is a hazard that these remain available by default. The go-openssl-fips build blocks all of them.

TLS stack in upstream Go does not adhere to the requirements of RFC 9151 Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 as well as the Draft 5 Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3. Chainguard FIPS hardening updates the default TLS server and client configuration to adhere those standards. This ensures that binaries compiled using this toolchain can be deployed in National Security Systems without modification.

Note that raw MD5 and SHA-1 digests remain available in both builds for legacy, non-security-sensitive use (e.g. checksums); this is permitted under FIPS 140-3 I.G. 2.4.A. It is only their use in HMAC and digital signatures that is blocked in go-openssl-fips. For more detail, see the Chainguard Academy article on non-approved algorithms. They can be blocked in GODEBUG=fips140=only mode.

SHA-1 has been deprecated for security purposes such as digital signatures for well over a decade — by the IETF in RFC 6194 and by NIST, which retired SHA-1 in 2022.

MD5 is a non-FIPS algorithm, and NIST has never permitted HMAC or digital signatures with MD5. Its only sanctioned use was the MD5-SHA1 combination in TLS 1.0 — itself long obsolete. DES, Triple DES (3DES), and RC4 are all broken algorithms that no longer provide any cryptographic security. DSA was obsoleted by NIST with the publication of FIPS 186-5 in 2023; the transition period for generating DSA signatures ended in 2024, one year after publication.

Golang chooses to allow insecure and broken cryptography by default — even when disallowed by NIST FIPS requirements — owing to its strong backwards compatibility guarantees. This unfortunately pushes the burden of building secure software onto the end developers, requiring them to inspect and audit all of their own code and all of their dependencies. The go-openssl-fips build removes that burden by blocking these algorithms outright. The WithoutEnforcement API remains wired up, so developers who genuinely require a blocked algorithm can still access it explicitly — for legacy or non-security purposes that are compliant with the relevant NIST SP references and implementation guidance.

Runtime availability of the PQC algorithms such as ML-KEM and ML-DSA is dependent on the runtime OpenSSL FIPS provider capabilities or the Go Cryptographic module capabilities. Full support is expected with future upgrades to Chainguard FIPS Provider for OpenSSL 3.6 and Go Cryptographic module 1.26.

Interactive build with FIPS operation validation

This section contains two examples of how you can use the Go FIPS Chainguard Image to build an example Go application. For more information on working with this Image, check out our Getting Started with the Go Chainguard Image guide.

Start interactive shell in the go-openssl-fips image:

docker run --rm -ti --user root -w /root --entrypoint bash cgr.dev/ORGANIZATION/go-openssl-fips:latest

User root is used here, to perform tampering with the FIPS module selfcheck after compiling and running the application.

Install a golang demo application helloserver:

# go install golang.org/x/example/helloserver@latest
go: downloading golang.org/x/example v0.0.0-20240205180059-32022caedd6a
go: downloading golang.org/x/example/helloserver v0.0.0-20240205180059-32022caedd6a

Observe build settings used to build the binary:

$ go version -m go/bin/helloserver
go/bin/helloserver: go1.27.0
	path	golang.org/x/example/helloserver
	mod	golang.org/x/example/helloserver	v0.0.0-20250915201037-7f05d217867b	h1:L1/RGavMQ9j3t6h8ownBfFJhAw3V5LTzLFolyKREC4U=
	build	chainguard_go_package=go-msft-1.27-1.27.0.1-r0
	build	chainguard_cryptographic_module=openssl+geomys
	build	chainguard_entropy_source=openssl+geomys
	build	microsoft_systemcrypto=1
	build	microsoft_toolset_version=go1.27.0-microsoft
	build	-buildmode=exe
	build	-compiler=gc
	build	-tags=fips140v1.0
	build	DefaultGODEBUG=cgr_fips=openssl+geomys,cgr_verbose=0,containermaxprocs=0,cryptocustomrand=1,decoratemappings=0,fips140=on,gotestjsonbuildtext=1,httpcookiemaxnum=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,multipathtcp=0,panicnil=1,randseednop=0,rsa1024min=0,tlsmlkem=0,tlssecpmlkem=0,tlssha1=1,tracebacklabels=0,updatemaxprocs=0,urlmaxqueryparams=0,urlstrictcolons=0,winreadlinkvolume=0,winsymlink=0,x509negativeserial=1,x509rsacrt=0,x509sha256skid=0,x509sslcertoverrideplatform=0,x509usepolicies=0
	build	CGO_ENABLED=1
	build	CGO_CFLAGS=
	build	CGO_CPPFLAGS=
	build	CGO_CXXFLAGS=
	build	CGO_LDFLAGS=
	build	GOARCH=amd64
	build	GOFIPS140=v1.0.0-c2097c7c
	build	GOOS=linux
	build	GOAMD64=v2

Observe the following settings are in place:

• build chainguard_go_package=go-msft-1.27-1.27.0.1-r0 indicates the Chainguard Go toolchain package name and version that was used to create this binary
• build chainguard_cryptographic_module=openssl+geomys indicates the cryptographic modules possible to use
• build chainguard_entropy_source=openssl+geomys indicates the entropy sources used by this binary
• build microsoft_systemcrypto=1 indicates microsoft/go based toolchain is in use
• build microsoft_toolset_version=go1.27.0-microsoft indicates microsoft/go upstream patchset
• build DefaultGODEBUG=cgr_fips=openssl+geomys,cgr_verbose=0 indicates the default GODEBUG mode for the binary, try openssl and fallback to Go Cryptographic Module
• build GOFIPS140=v1.0.0-c2097c7c indicates the Go Cryptographic module version in use when fallback is activated

Verify that OpenSSL symbols are used by the binary:

$ go tool nm go/bin/helloserver | grep -e OpenSSL_version
  405cf0 T _cgo_d709473f4dfc_Cfunc__mkcgo_OpenSSL_version
  405d30 T _cgo_d709473f4dfc_Cfunc__mkcgo_OpenSSL_version_num
  4061a0 T _cgo_d709473f4dfc_Cfunc__mkcgo_available_OpenSSL_version_num
  a83be0 B _g_OpenSSL_version
  a83bd8 B _g_OpenSSL_version_num
  40e7d0 T _mkcgo_OpenSSL_version
  40e800 T _mkcgo_OpenSSL_version_num
  40e7e0 T _mkcgo_available_OpenSSL_version_num
  518e60 T vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._Cfunc__mkcgo_OpenSSL_version.abi0
  518f00 T vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._Cfunc__mkcgo_OpenSSL_version_num.abi0
  5197c0 T vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._Cfunc__mkcgo_available_OpenSSL_version_num.abi0
  a51e70 D vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._cgo_d709473f4dfc_Cfunc__mkcgo_OpenSSL_version
  a51e78 D vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._cgo_d709473f4dfc_Cfunc__mkcgo_OpenSSL_version_num
  a51ee8 D vendor/github.com/microsoft/go-crypto-openssl/internal/ossl._cgo_d709473f4dfc_Cfunc__mkcgo_available_OpenSSL_version_num

Note that microsoft/go-crypto-openssl are the underlying bindings for all the available APIs, even if individual binary may not use all of them.

When cross-compiling to Windows and MacOS - bindings to native cryptography for those Operating Systems will be in use instead.

Verify binary execution with suitable OpenSSL FIPS provider (use Ctrl+C to terminate):

# GODEBUG=cgr_verbose=1 go/bin/helloserver 
cgr_fips: openssl
2026/08/31 20:33:31 serving http://localhost:8080
^C

Now tamper with the fips provider to observe failure to start the application in OpenSSL-only and FIPS mode:

# cp /etc/ssl/fipsmodule.cnf /etc/ssl/fipsmodule.cnf.back
# sed -i 's|:*|:00|' /etc/ssl/fipsmodule.cnf
# GODEBUG=cgr_fips=openssl go/bin/helloserver 
panic: opensslcrypto: FIPS mode requested (environment variable GODEBUG=fips140=on) but not available: OpenSSL 3.6.4 25 Aug 2026

goroutine 1 [running]:
vendor/github.com/microsoft/go/cryptobackend.useGeomys({0x17cb6ef92310, 0x6a}, 0x0)
	/usr/lib/go/src/vendor/github.com/microsoft/go/cryptobackend/backend_openssl.go:70 +0x28b
vendor/github.com/microsoft/go/cryptobackend.init.1()
	/usr/lib/go/src/vendor/github.com/microsoft/go/cryptobackend/backend_openssl.go:52 +0x1ef

Observe that binary still works with Go Cryptographic Module fallback even without working OpenSSL:

# GODEBUG=cgr_fips=openssl+geomys,cgr_verbose=1 go/bin/helloserver 
cgr_fips: openssl attempted, fallback to geomys: FIPS mode requested (environment variable GODEBUG=fips140=on) but not available: OpenSSL 3.6.4 25 Aug 2026
2026/08/31 20:35:31 serving http://localhost:8080

As well as directly requesting to use Go Cryptographic Module only:

# GODEBUG=cgr_fips=geomys,cgr_verbose=1 go/bin/helloserver 
cgr_fips: geomys
2026/08/31 20:35:58 serving http://localhost:8080

Now restore fipsmodule.cnf to get OpenSSL FIPS back into operational state:

cp /etc/ssl/fipsmodule.cnf.back /etc/ssl/fipsmodule.cnf

Dockerfile example

The following example Dockerfile builds a helloserver program in Go and copies it on top of the cgr.dev/ORGANIZATION/glibc-openssl-fips:latest base image to ensure OpenSSL is used at runtime for FIPS:

FROM cgr.dev/ORGANIZATION/go-openssl-fips:latest:latest AS build

RUN go install golang.org/x/example/helloserver@latest

FROM cgr.dev/ORGANIZATION/glibc-openssl-fips:latest

COPY --from=build /home/nonroot/go/bin/helloserver /helloserver
CMD ["/helloserver"]

Run the following command to build the demo image and tag it as go-helloserver-fips:

docker build -t go-helloserver-fips .

Now you can run the image with:

docker run go-helloserver-fips

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.