ERR_CERT_COMMON_NAME_INVALID error for HTTPS subdomain despite wildcard subdomain certificate configuration

I am experiencing an ERR_CERT_COMMON_NAME_INVALID error when accessing an HTTPS subdomain https://portainer.app/ (but in general any subdomain), even though the certificate has been configured for app and *.app SAN.

TLDR: I created new Debian server for docker with hostname app and IP 10.1.1.51. Every computer in domain see both hostname and ip without problems (checked with ping and nslookup). In XCA I created Root CA, Intermediate CA and Servers endpoint certificate signed with Intermediate CA. Root and Intermediate Public Keys are deployed on all devices in network. Servers Certificate detail showing many SANs, including:

...
DNS Name=terminal
DNS Name=*.terminal
DNS Name=app
DNS Name=*.app
DNS Name=localhost
IP Address=127.0.0.1
IP Address=10.1.1.50
IP Address=10.1.1.51
...

On app I created 2 docker-compose.yml for nginx and portainer. Portainer docker-compose:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    restart: unless-stopped
    ports:
      - 9810:9443
      - 8000:8000
    volumes:
      - ./data:/data
      - ./ssl:/certs
      - /var/run/docker.sock:/var/run/docker.sock.
    command:
      - --ssl
      - --sslcert
      - /certs/Servers-Public.crt
      - --sslkey
      - /certs/Servers-Private.pem

Portainer is configured for nginx in portainer.conf like this:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name portainer.app;

    ssl_certificate /etc/ssl/certs/Servers-Public.crt;
    ssl_certificate_key /etc/ssl/private/Servers-Private.pem;

    location / {
        proxy_pass https://10.1.1.51:9810/;
    }
}

Primary app site is configured in default.conf:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name app localhost 10.1.1.51;

    ssl_certificate /etc/ssl/certs/Servers-Public.crt;
    ssl_certificate_key /etc/ssl/private/Servers-Private.pem;

    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
    }

    location /portainer/ {
        proxy_pass https://10.1.1.51:9810/;
        proxy_set_header X-Forwarded-Prefix /portainer;
        proxy_set_header Host $host;
    }
}

There is http to https redirect in booth files (with correct server_name):

server {
    listen 80;
    listen [::]:80;
    server_name portainer.app;
    return 301 https://$host$request_uri;
}

After browse https://app/ Chrome shows correct webpage and that certificate is valid and everything is ok. Also, even if I browse app/portainer or 10.1.1.51/portainer everything works on ssl and secure.

However, as soon as I enter any subdomain (https://portainer.app or random.app) I get an error ERR_CERT_COMMON_NAME_INVALID. The same certificate which is valid for app is now invalid for any *.app.

I have already done this: I have checked the Nginx configuration, docker-compose files, DNS settings, and everything appears to be correct. I tried to make an certificate again for all original domains, but also a simpler certificate only for 2 CN: portainer.app and *.portainer.app... It always behaves the same way.
DNS correctly resolves to the server's IP address 10.1.1.51, and after open site in browser there are no log entry in the Nginx docker logs. I use ESET antivirus, but when I try it directly on a server where ESET is not installed, the result is the same there as well. Any idea where the error is?

A wildcard certificate should not be issued if it covers domains under different administrative control (i.e. different owners). Otherwise it would be possible that one owner could use its own certificate to impersonate domains which belong to somebody else.

This means it is not possible to have a wildcard for *, not for *.com but also not for *.co.uk (which basically is the UK form of *.com). The same as true for *.app or *.dev.

In general - there is no wildcard for any public top-level domain. For everything at a lower level consult the public suffix list.

These rules are enforced in the browser when validating a certificate. This means browsers don't only rely on certificate authorities to not issue such certificates, they also make sure that they don't work even if issued. Certificate validation outside of browser is often not that strict.

See also Can a wildcard SSL certificate be issued for a second level domain?.