Integrate hybrid transport and mutual certificate trust

Map the cryptographic boundary

Begin with the route, not the algorithm name. A client may connect through an explicit proxy, TLS inspection device, load balancer, gateway, and application connector. List which component terminates each TLS leg. A hybrid client-to-gateway session does not automatically protect the gateway-to-origin leg.

Classify data by confidentiality lifetime and exposure to traffic capture. Prioritize connections carrying long-lived sensitive information and establish the rollback owner for each application. NIST’s migration project provides a useful starting point for discovery and interoperability planning. NIST migration project ↗

Verify the gateway with OpenSSL

Use OpenSSL 3.5 or a compatible later release for the named hybrid group. Supply certificates issued by your test PKI, with the correct client purpose and service name. This command is a protocol diagnostic, not the Antara client installer. Replace gateway.example with the test gateway name covered by its certificate.

openssl version
openssl s_client -connect gateway.example:443 \
  -servername gateway.example -tls1_3 \
  -groups X25519MLKEM768 \
  -CAfile gateway-roots.pem \
  -verify_hostname gateway.example \
  -verify_return_error \
  -cert device.pem -key device.key

Inspect the negotiated group and verification result. Repeat with an untrusted issuer, wrong hostname, missing client certificate, and unsupported group. The negative cases should fail for the expected reason. A successful invocation alone is not proof that production policy rejects invalid peers. OpenSSL s_client ↗

Prepare a certificate interoperability lab

Generate test material in an isolated working directory with restrictive file permissions. Private keys stay on the endpoint or in its managed key provider. Submit the CSR through your authorized test CA workflow; signing policy should assign the subject alternative name, certificate purpose, lifetime, and tenant binding.

umask 077
openssl genpkey -algorithm ML-DSA-65 -out device.key
openssl req -new -key device.key -out device.csr \
  -subj "/CN=device-001"

OpenSSL 3.5 introduced ML-KEM, ML-DSA, and SLH-DSA support. Validate your distribution and providers before using these commands. The CSR does not by itself authorize enrollment or determine the CA’s issued extensions. OpenSSL 3.5 release ↗

openssl s_server -accept 127.0.0.1:8443 -tls1_3 \
  -groups X25519MLKEM768 \
  -cert server.pem -key server.key \
  -Verify 2 -verify_return_error \
  -CAfile client-roots.pem -www

This loopback-only diagnostic server requires pre-issued server and client certificates. The capitalized Verify option requests and requires a client certificate. Use the matching service name when testing it; keep this diagnostic listener out of production. OpenSSL s_server ↗

Move from lab to fleet

Keep application teams involved in failure triage. Browser access, native clients, and workload connectors can use different TLS stacks and certificate facilities. Promote a tested combination rather than advertising universal compatibility from a single successful handshake.