关于通配符证书的两类技术疑问：顶级域名可用性及curl SSL匹配异常

Hey everyone, let's tackle these two wildcard certificate questions one by one—they're both common gotchas that trip up even experienced devs!

第一个问题：curl SSL匹配异常，明明SAN包含对应通配符却报错 #

First off, that curl: (60) SSL: no alternative certificate subject name matches target host name error is super frustrating when you swear your SAN has the right entries. Let's break down why this might be happening:

• Double-check your certificate's actual SAN entries: Sometimes what you think is in the certificate isn't what's really there. Run openssl x509 -in your-cert.pem -text -noout and verify the X509v3 Subject Alternative Name section explicitly lists DNS:elasticsearch and DNS:*.elasticsearch—no typos, no hidden extra suffixes you might have missed (like .svc.cluster.local in Kubernetes setups).
• RFC wildcard matching rules: Remember that wildcard certificates only match single-level subdomains (per RFC 6125). Your target host elasticsearch-0.elasticsearch is a single-level subdomain of elasticsearch, so *.elasticsearch should technically match it. That said, older versions of curl might have stricter or non-compliant matching logic—try updating curl to the latest stable release and see if the error vanishes.
• Hostname parsing edge cases: If your cluster uses a split DNS setup, or the hostname is resolving to an IP tied to a different certificate, that could also cause this mismatch. Use curl -v https://elasticsearch-0.elasticsearch to get verbose output and check exactly which certificate is being presented during the handshake.

第二个问题：顶级域名通配符（如*.com）的禁止依据 #

You're spot-on that the RFCs (6125, 2818, 2459) don't explicitly ban wildcard certificates for top-level domains (TLDs) like *.com—but the restriction comes from CA/Browser Forum Baseline Requirements, not IETF standards.

These are the industry-enforced rules that all public CAs must follow to have their certificates trusted by browsers and tools. The baseline requirements prohibit issuing wildcard certificates for TLDs because they pose massive security risks: a *.com certificate would let an attacker impersonate any domain on the .com TLD, which is obviously unacceptable.

While Wikipedia mentions this restriction, it doesn't dive into the industry standards context—that's why you couldn't find it in the RFCs you checked!

备注：内容来源于stack exchange，提问作者Vladimir Tiukhtin