[erlang-questions] Wildcard certificate rejected with hostname_check_failed
Dániel Szoboszlay
dszoboszlay@REDACTED
Thu Oct 3 00:22:15 CEST 2019
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
<http://erlang.org/doc/apps/public_key/using_public_key.html#the-verification-process>
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
> <https://tools.ietf.org/html/rfc6125#section-6.4.3>.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191003/4ced1c19/attachment.htm>
More information about the erlang-questions
mailing list