Skip to content

Conversation

julianoes
Copy link

@julianoes julianoes commented Sep 18, 2025

Problem

I'm using quic_load_sdk_config like so:

memset(&_quicConfig, 0, sizeof(_quicConfig));
_quicConfig.tls.enable = true;  // Enable TLS for secure QUIC
_quicConfig.tls.cafile = strdup("./mqtt-server.pem");  // CA certificate file for server verification
_quicConfig.tls.certfile = strdup("");  // Empty - no client certificate needed
_quicConfig.tls.keyfile = strdup("");   // Empty - no client private key needed
_quicConfig.tls.key_password = strdup("");  // No password needed
_quicConfig.tls.verify_peer = true;
_quicConfig.tls.set_fail = false;
...

This fails for me with error -1.

It turns out that the quic_load_sdk_config() function in src/supplemental/quic/quic_api.c unconditionally sets
QUIC_CREDENTIAL_TYPE_CERTIFICATE_FILE and QUIC_CREDENTIAL_FLAG_INDICATE_CERTIFICATE_RECEIVED when
TLS is enabled, even when no client certificate files are provided (empty certfile and keyfile
strings).

This doesn't seem to match the msquic API spec which requires:

  • QUIC_CREDENTIAL_TYPE_NONE for client-only scenarios without client certificates
  • QUIC_CREDENTIAL_TYPE_CERTIFICATE_FILE only when actual certificate files are provided

The causes MsQuic->ConfigurationLoadCredential() to fail with error (-268435457) for a (presumably?) legitimate client-only TLS configurations where only server certificate verification is needed.

Solution

  • Add conditional check to only set up certificate file credentials when certfile and keyfile
    contain non-empty paths
  • Keep QUIC_CREDENTIAL_TYPE_NONE (set at initialization) for client-only scenarios with empty
    certificate paths
  • Move QUIC_CREDENTIAL_FLAG_INDICATE_CERTIFICATE_RECEIVED flag inside the certificate file
    conditional block
  • Remove the unconditional credential type override that was breaking client-only configurations

Testing

Fix resolves ConfigurationLoadCredential failures for client-only QUIC TLS configuration that I'm trying to use.

Question

Is this a valid use case and I hit a bug, or am I doing this all wrong?

The quic_load_sdk_config function was unconditionally setting
QUIC_CREDENTIAL_TYPE_CERTIFICATE_FILE even when certfile/keyfile
were empty strings, causing ConfigurationLoadCredential to fail
for client-only TLS scenarios.

Per Microsoft QUIC API spec, QUIC_CREDENTIAL_TYPE_NONE should be
used for client-only scenarios without client certificates.

Fixes client-only QUIC TLS connections while preserving mutual TLS.
@julianoes
Copy link
Author

Hello, anyone there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant