0

Problem:

Server: Subject Alternative Name(SAN) in server certificate: *test.example.com

Client: Server Name Indicator(SNI) given from client side: mytest.example.com

Result: handshake fail!

Although for similar scenario,

Subject Alternative Name(SAN) in server certificate: *.example.com

Client: Server Name Indicator(SNI) given from client side: mytest.example.com

Result: handshake successful!

Query:

I need to conduct successful handshake for SAN *test.example.com. I'm guessing Openbsd must have an option to make the first match (which is failing now) valid. Can someone please help me with this.

What RFC has to say: (RFC 6125 Sec: 6.4.3) The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and baz.example.net and bz.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO].

Thanks in advance.

s-ghansiala
  • 67
  • 5
  • 1
    As the RFC says, the client MAY match. Most probably this particular client does not. If you want to have portable code, then you should not rely on this behavior. With that said, I don't know if libressl has an option to change that. – g_bor Sep 17 '20 at 06:59
  • 1
    This question does not provide any code to reproduce the problem. Note that the specific behavior you describe is traditionally only done for HTTPS, i.e. wildcard verification in other protocols (LDAP, SMTP, ...) either did not support wildcards at all or required the asterisk to match the full label instead of only a part. The MAY instead of SHOULD or even MUST in the RFC reflects this. – Steffen Ullrich Sep 17 '20 at 07:08
  • @g_bor Actually I'm coding both client and server TLS communication using libressl, and its a requirement that these kinds of SAN are validated from client side. I guess I should have written it in query itself, my bad. Thanks though. – s-ghansiala Sep 17 '20 at 07:12
  • 1
    @s-ghansiala: If you need help with the behavior of your code then please provide code to reproduce your issue. See [How to create a Minimal, Reproducible Example](https://stackoverflow.com/help/minimal-reproducible-example). – Steffen Ullrich Sep 17 '20 at 07:58
  • @Steffen Ulliich, thanks for you reply. I guess your first comment almost solves my problem. I'm using DICOM protocol. As you suggested in your comment, I think the protocol itself is not supporting this kind of wildcard usage. Still if this inference can be confirmed, it will be a great help. Thanks for your second comment too, the link is helpful, but I think your previous comment shall be enough, code won't be required. Thanks again! – s-ghansiala Sep 17 '20 at 08:20

0 Answers0