does it check SNI at all?

[whSwitching]

I'm using msquic_2.0.0_windows_openssl dll, some experiments I did:

1. build sample.c from release/2.0 branch
2. generate self-signed certificate with openssl.exe req -nodes -new -x509 -keyout localhost.key -out localhost.pem
3. localhost.pem CN=localhost
4. run sample.exe -server -cert_file:localhost.pem -key_file:localhost.key
5. run sample.exe -client -target:localhost
6. got an error: 0x8041012A, after some searching, it's bad certificate from openssl, which is expected with self-signed certificate
7. run sample.exe -client -target:localhost -unsecure and they are talking to each other
8. run sample.exe -client -target:127.0.0.1 -unsecure, and they still talk! this is unexpected
9. generate NEW self-signed certificate with openssl.exe req -nodes -new -x509 -keyout somethingelse.key -out somethingelse.pem
10. somethingelse.pem CN=somethingelse.com
11. run server again
12. and run sample.exe -client -target:localhost -unsecure, THEY STILL TALK , even when the certificate common name NOT match

question, is this behavior expected or not? or I should handle it in my code ?

[nibanks]

When you do unsecure it turns off all certificate validation. If you do certificate validation, it should validate the name in the certificate.

[whSwitching]

when you do unsecure, it's on the client side,

    CredConfig.Type = QUIC_CREDENTIAL_TYPE_NONE;
    CredConfig.Flags = QUIC_CREDENTIAL_FLAG_CLIENT;
    if (Unsecure) {
        CredConfig.Flags |= QUIC_CREDENTIAL_FLAG_NO_CERTIFICATE_VALIDATION;
    }

why it matters the server side, the server should always check server name in TLS handshake message
and the server's certificate valid or not, is client's choice, just like I can still open a website in Edge when its certificate expired a few days ago

[nibanks]

We don't do any validation on the server side on the certificate you supply to the client. It's up to you to pick one that matches correctly.

[whSwitching]

We don't do any validation on the server side on the certificate you supply to the client.

Thank you for the confirmation.
I guess that's why INDICATE_CERTIFICATE_RECEIVED flag is there,
so client can

• accept a connection to the server that he wasn't intended to connect (because certificate CN not match requested domain), who would do that
• or reject a connection to the server when certificate CN not match requested domain, reasonable, but it suppose to be done on server side when handshake