| Previous | Next |
| SEC_I_SIGNATURE_NEEDED | SEC_I_MESSAGE_FRAGMENT |
SEC_I_NO_RENEGOTIATION
Peer rejected security-context renegotiation
SEC_I_NO_RENEGOTIATION is HRESULT 590688 (0x00090360) from winerror.h. AllStat describes it as “The recipient rejected the renegotiation request.” The severity bit indicates a nonfailure result, but the value carries a specific condition that must not be collapsed into plain S_OK.
In the SSPI authentication or message-protection state machine, this result means that the recipient rejected the renegotiation request. Acceptance depends on the returned state and outputs, not only on the cleared severity bit.
What must be true before accepting it
Verify that the existing context remains safe for permitted traffic or the connection is closed before different security parameters are required. This check separates a legitimate this result outcome from code that ignores an incomplete or altered operation.
Before retrying this result, classify its effects as completed, partial, pending, cancelled, adapted, or terminal.
Where the status is encountered
- This result can be returned during InitializeSecurityContext or AcceptSecurityContext loops; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during Schannel or another security package; log the exact method and object state instead of interpreting the constant outside that contract.
- It can be returned during message signing, fragmentation, or asynchronous SSPI processing; log the exact method and object state instead of interpreting the constant outside that contract.
Because it is informational, a language binding may expose it as success and hide the symbolic distinction. Keep the original HRESULT available until the code-specific branch has run.
Evidence and telemetry
- preserve security package and protocol version.
- preserve current cipher and context attributes.
- preserve renegotiation trigger.
- preserve peer response bytes.
- preserve decision to continue or reconnect.
Also record sec_i_no_renegotiation_operation, sec_i_no_renegotiation_state_before, sec_i_no_renegotiation_state_after, UTC time, process and thread identifiers, component version, and a correlation ID. When logging it, redact secret payloads but preserve stable identifiers and hashes needed for correlation.
Correct handling and recovery
Do not loop on renegotiation. Continue only if the current protocol and policy allow it; otherwise establish a fresh connection and security context.
Retry it only when a documented input or state has changed. Do not immediately repeat it when the same stable state would produce the same informational result.
Practical scenario
A TLS peer rejects renegotiation requested for a client certificate. The server closes the session and requires a new handshake rather than retrying renegotiation indefinitely.
A regression test should reproduce it, assert the relevant outputs and state, then change only the decisive condition and verify the expected neighboring result or ordinary completion.
Difference from nearby results
It must be distinguished from ordinary S_OK and from failure-severity values in the same API family; its documented state changes control the next action.
The distinction around it determines whether the caller stops, waits, consumes output, or changes state.
References
- Microsoft: SSPI status codes — official Microsoft material used to interpret it.
- Microsoft: SSPI context semantics
- Microsoft: InitializeSecurityContext
- Microsoft: DecryptMessage
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.