Wildcard certificate rejected with hostname_check_failed

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Wildcard certificate rejected with hostname_check_failed

Dániel Szoboszlay
Hi,

I'm trying to connect to the server foobar.example.com with ss from an Erlang node. The server presents a wildcard certificate with an ?'id-ce-subjectAltName' extension that looks like this:

{'Extension', {2,5,29,17}, false,
 [{dNSName, "*.example.com"},
  {dNSName, "example.com"}
 ]}

The peer verification (default one) fails with hostname_check_failed. I traced the problem back to public_key:verify_hostname_match_default0/2 which gets called like this:

public_key:verify_hostname_match_default0(
  {dns_id, "foobar.example.com"},
  {dNSName, "*.example.com"})

This check fails. The function has one clause for matching a dns_id against a dNSName, and it requires an exact match. It also has a clause that allows wildcards, but that's only for matching a (non-wrapped) fqdn against a cn tuple: https://github.com/erlang/otp/blob/5bf0a8a2a18a8e883792692bdc060e37552b0d08/lib/public_key/src/public_key.erl#L1672-L1675

Why isn't the wildcard matching enabled for the dns_id against dNSName case too? The fqdn against cn scenario is only used as a fallback when the certificate doesn't contain an ?'id-ce-subjectAltName' extension. But as far as I can tell wildcard certificates typically have the extension, instead of (or besides) using a wildcard in the CN (see for example the certificate presented by https://blog.hu/).

The public_key User's Guide says: 

In case where the Presented IDs are fetched from the Subject certificate field, the names may contain wildcard characters. The function handles this as defined in chapter 6.4.3 in RFC 6125.

But as I understand, chapter 6.4.3 speaks about presented ids in general. Where does this restriction to the subject field come from?

Thanks,
Daniel

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Wildcard certificate rejected with hostname_check_failed

Ingela Andin

You need to use the ssl option:
 
{customize_hostname_check,
                                          [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]}

to allow wildcard certs!

Regards Ingela Erlang/OTP team - Ericsson AB

Den tors 3 okt. 2019 kl 00:22 skrev Dániel Szoboszlay <[hidden email]>:
Hi,

I'm trying to connect to the server foobar.example.com with ss from an Erlang node. The server presents a wildcard certificate with an ?'id-ce-subjectAltName' extension that looks like this:

{'Extension', {2,5,29,17}, false,
 [{dNSName, "*.example.com"},
  {dNSName, "example.com"}
 ]}

The peer verification (default one) fails with hostname_check_failed. I traced the problem back to public_key:verify_hostname_match_default0/2 which gets called like this:

public_key:verify_hostname_match_default0(
  {dns_id, "foobar.example.com"},
  {dNSName, "*.example.com"})

This check fails. The function has one clause for matching a dns_id against a dNSName, and it requires an exact match. It also has a clause that allows wildcards, but that's only for matching a (non-wrapped) fqdn against a cn tuple: https://github.com/erlang/otp/blob/5bf0a8a2a18a8e883792692bdc060e37552b0d08/lib/public_key/src/public_key.erl#L1672-L1675

Why isn't the wildcard matching enabled for the dns_id against dNSName case too? The fqdn against cn scenario is only used as a fallback when the certificate doesn't contain an ?'id-ce-subjectAltName' extension. But as far as I can tell wildcard certificates typically have the extension, instead of (or besides) using a wildcard in the CN (see for example the certificate presented by https://blog.hu/).

The public_key User's Guide says: 

In case where the Presented IDs are fetched from the Subject certificate field, the names may contain wildcard characters. The function handles this as defined in chapter 6.4.3 in RFC 6125.

But as I understand, chapter 6.4.3 speaks about presented ids in general. Where does this restriction to the subject field come from?

Thanks,
Daniel
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions