| Previous | Next |
| RTC_E_SIP_TLS_INCOMPATIBLE_ENCRYPTION | RTC_E_SIP_DNS_FAIL |
RTC_E_SIP_INVALID_CERTIFICATE
Where the state changes: RTC_E_SIP_INVALID_CERTIFICATE
When RTC returns this result, the relevant contract is selecting an allowed authentication method, validating the challenge realm, and establishing a protected SIP transport, and it says that the certificate presented or selected for SIP TLS does not satisfy RTC validation requirements.
The stored value is 0x80EE0065 in the RTC interface facility 0xEE; keep both forms in telemetry so COM error wrapping does not erase whether RTC produced an interface result, mapped a SIP response, or surfaced a PINT outcome.
Collect enough state to record validation error, subject/SAN, issuer, validity period, trust chain, endpoint name, and UTC time; the result evidence should demonstrate why certificate rejection is identity/trust validation, not generic TCP or TLS reachability failure.
Protocol and object state
| RTC area | SIP authentication and TLS identity |
|---|---|
| Condition to prove | the certificate presented or selected for SIP TLS does not satisfy RTC validation requirements |
| Objects to correlate | profile authentication method, challenge headers, realm, credential source, TLS certificate and tunnel |
| Safe corrective direction | correct endpoint naming, trust, time, or certificate deployment; never suppress validation globally |
RTC profile rules tie some authentication methods to TCP or TLS; Basic authentication requires TLS in the legacy API contract. A certificate failure, a challenge mismatch, and invalid credentials occur at different layers and need different remediation.
Comparison with adjacent codes
Use “the certificate presented or selected for SIP TLS does not satisfy RTC validation requirements” as the discriminator when comparing the related RTC results below.
RTC_E_SIP_AUTH_FAILED | the selected SIP authentication attempt was rejected or could not validate for the challenge |
|---|---|
RTC_E_SIP_AUTH_HEADER_SENT | the RTC authentication state already sent authorization for this challenge path and will not repeat it blindly |
RTC_E_SIP_AUTH_TYPE_NOT_SUPPORTED | the challenge requests an authentication scheme the RTC profile or stack cannot use |
The comparison prevents this result from being flattened into a subsystem-wide error bucket with unsafe generic remediation.
Telemetry and packet evidence
Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate it with one RTC object instance and one transaction or media transition.
- Code-specific proof: record validation error, subject/SAN, issuer, validity period, trust chain, endpoint name, and UTC time.
- Addressing context: credential identity without secret material.
- RTC callback state: certificate subject and validation failure.
- Transaction boundary: client/server UTC time and
TLSphase. - Media or profile detail: 401 or 407 challenge source.
Step-by-step isolation
- Use protocol and object evidence to record validation error, subject/SAN, issuer, validity period, trust chain, endpoint name, and UTC time.
- Confirm the distinction that certificate rejection is identity/trust validation, not generic
TCPorTLSreachability failure. - Start a fresh operation after you correct endpoint naming, trust, time, or certificate deployment; never suppress validation globally, and compare its final state with the failing run.
Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.
Actions that do not address this condition
- Never record Authorization header contents or plaintext passwords.
- Do not disable certificate checking or lower transport security to make authentication appear successful.
Recovery
The owning RTC component should correct endpoint naming, trust, time, or certificate deployment; never suppress validation globally; it should also settle or cancel its previous operation before callers begin a replacement.
Example: The profile connects by alias not present in the registrar certificate identity.
Verification after a fix
Verify the fix with a minimal deterministic case that reaches “the certificate presented or selected for SIP TLS does not satisfy RTC validation requirements”; the failing case must assert the HRESULT and post-failure state; the passing case should alter one input and confirm both protocol outcome and cleanup.
Technical references
- Microsoft profile creation rules — authoritative context for this result.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP authentication and TLS — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.