Azure Linux 3.0 - Expected behavior in FIPS mode

[vermajit]

We are using AKS with Azure Linux 3.0 node pool. Our containers are based on AL 3.0 as well. Our applications are mix of Golang and .NET.
I am trying to understand all the changes needed at all layers of the software stack for FIPS compliance.

I updated the nodepool to enable FIPS (via enable-fips-image flag). I verified the following inside the one of the nodes and everything seemed as per documentation

kubectl debug node/aks-roxypool-27210205-vmss000000 -it --image=busybox

/ # cat /host/etc/os-release 
NAME="Microsoft Azure Linux"
VERSION="3.0.20260204"
ID=azurelinux
VERSION_ID="3.0"
PRETTY_NAME="Microsoft Azure Linux 3.0"
ANSI_COLOR="1;34"
HOME_URL="https://aka.ms/azurelinux"
BUG_REPORT_URL="https://aka.ms/azurelinux"
SUPPORT_URL="https://aka.ms/azurelinux"

/ # cat /proc/sys/crypto/fips_enabled
1

/ # chroot /host /usr/bin/openssl version -a
OpenSSL 3.3.5 30 Sep 2025 (Library: OpenSSL 3.3.5 30 Sep 2025)
built on: Sun Feb  1 11:05:57 2026 UTC
platform: linux-x86_64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/azl/default-hardened-cc1    -fcommon -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/azl/default-hardened-cc1 -fcommon -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/azl/default-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -DPURIFY -DDEVRANDOM="\\"/dev/urandom\\""
OPENSSLDIR: "/etc/pki/tls"
ENGINESDIR: "/usr/lib/engines-3"
MODULESDIR: "/usr/lib/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0xfffa32235f8bffff:0x415f46f1bf2fbb

But when I test to see if non-approved crypto functions are getting blocked, all requests are still allowed. Here are some sample

/ # echo "test" | chroot /host /usr/bin/openssl md5 -provider symcryptprovider
MD5(stdin)= d8e8fca2dc0f896fd7cb4cb0031ba249

/ # chroot /host /usr/bin/openssl req -new -newkey rsa:1024 -nodes
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
-----BEGIN CERTIFICATE REQUEST-----

# Started a server
chroot /host /usr/bin/openssl s_server \
  -accept 9443 \
  -cert /tmp/cert.pem \
  -key /tmp/key.pem \
  -min_protocol TLSv1.1 \
  -max_protocol TLSv1.2 &

# Client using tls 1.2 but un-approved cipher
/ # chroot /host /usr/bin/openssl s_client \
>   -connect 127.0.0.1:9443 \
>   -tls1_2 \
>   -cipher 'AES128-SHA'
Connecting to 127.0.0.1
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 C=US, ST=WA, L=Redmond, O=Test, OU=TLS, CN=localhost
verify error:num=18:self-signed certificate
verify return:1
depth=0 C=US, ST=WA, L=Redmond, O=Test, OU=TLS, CN=localhost
verify return:1
-----BEGIN SSL SESSION PARAMETERS-----
MF8CAQECAgMDBAIALwQABDA1Ff0s2oCzv0OGdtvzB6/x3BxyEKn+UHQphIS0XJdb

What am I missing? What are the additional changes i need to do at node/container/application level to enforce FIPS-only behavior? I would prefer non-FIPS usage to surface as errors rather than operate silently in non-approved mode.