Key establishment
Key establishment creates a shared secret. Classical groups such as X25519 can be replaced by hybrid groups such as X25519MLKEM768; AES can remain the traffic cipher.
No server evidence received.
Contacting the configured status endpoint…
Key establishment creates a shared secret. Classical groups such as X25519 can be replaced by hybrid groups such as X25519MLKEM768; AES can remain the traffic cipher.
No server evidence received.
Signs messages and verifies their integrity and origin with a trusted public key. A signature detects changes; it does not encrypt the page.
No server evidence received.
These are server-reported details of the browser-to-terminator connection serving this status request. It may differ from the original page connection. A proxy must report its browser-facing TLS, not its connection to the VM.
For example, AES-GCM or ChaCha20-Poly1305 protects TLS application data. The negotiated group identifies key establishment. The server’s handshake signature authenticates the connection; it is separate from the CA signature on a certificate.
Correlate endpoint results with your TLS terminator’s handshake logs and the test client. ML-KEM support alone does not establish ML-DSA authentication.
The issuer's certificate signature is separate from the TLS handshake signature and key establishment.
The first live response establishes a baseline for this tab.
After rotating a certificate, reload Apache and establish a fresh browser connection. Refreshing the page may reuse an existing TLS session.
This page automatically requests /api/pqc-status on its own origin. The TLS terminator must populate schema version 2 from this request’s connection. Empty algorithm values mean unknown, never a successful PQC result.