0

Curl returns curl: (60) SSL: no alternative certificate subject name matches target host name 'elasticsearch-0.elasticsearch' even if SAN clearly stands DNS:elasticsearch, DNS:*.elasticsearch

Wikipedia https://en.wikipedia.org/wiki/Wildcard_certificate points out that wildcards for top level domains are not allowed e.g. *.com but does not provide a proof

I looked at RFC 6125, RFC 2818 and RFC 2459 but could not find an evidence either

Improve this question
1
  • No authority will issue a certificate for *.com. Call a CA and ask them, that should be sufficient proof.
    – Greg Askew
    Jan 10, 2023 at 14:29

1 Answer 1

Reset to default
4

Certificates are designed to identify a single administrative entity. With public top level domains there is no single administrative entity for things like *.com, only for *.example.com or even more levels like in *.co.uk. The necessary level can be seen from the public suffix list and this is what browsers usually do to determine the minimum level for a wildcard certificate.

For privately used top level domains there is of course no such list since anybody can come up with these. Browsers fall therefore back to the common minimum level as seen for the public domains.

Note that while RFC 6125 does not explicitly address the issue the errata at least acknowledges it:

RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier
...
Likely the approach will need to consist of a "SHOULD" declaration and some hand-waving about how "matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations."

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .