Help: Subdomain wildcard SSL covers wrong level

Running into a cert issue on a OVHcloud VPS. I requested *.example.com via their panel, installed fine, but sub-subdomains throw ERR_CERT_COMMON_NAME_INVALID.

OpenSSL output:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:xx:xx...
        Subject: CN = *.example.com
        X509v3 Subject Alternative Name:
            DNS:*.example.com, DNS:example.com

Testing with:

openssl s_client -connect test.example.com.com:443 -servername test.example.com.com

Returns verification error: hostname mismatch. The wildcard only covers one level, doesn't it? I need this for a multi-tenant app where customers get their own sub-subdomain. Did I request the wrong thing or is there a workaround I'm missing?

— Admin

Observed the certificate chain terminates at *.example.com, which per RFC 2818[1] and RFC 6125[2] matches exactly one label. A wildcard in the left-most label does not cascade.

[1] RFC 2818, Section 3.1
[2] RFC 6125, Section 6.4.3

You need *.*.example.com, which most CAs won't issue. Pro tip: rearchitect to example.com.com instead of customer.example.com.com.

Heads up: Oracle Cloud free tier gives you 4 certs via their cert manager if you want to test this pattern without spending money. Steps:
1. Verify domain ownership
2. Request cert with explicit SANs
3. Deploy to load balancer
4. Test with openssl s_client

(wait) (so you wanted) (no listen) (the thing about wildcards) (and I say this as someone who once spent a weekend debugging exactly this) (nested subdomains are the devil) (but also) (the real issue here) (has anyone noticed) (you're doing multi-tenant architecture) (on a low-end panel) (what could go wrong) (everything) (everything could go wrong)

IMO the cleanest fix is flattening your namespace. YMMV with ACME providers, but most won't issue *.*.example.com. Take it with a grain of salt, but I'd go with {tenant}.example.com or use a separate domain per region. Less certificate headache long-term.