ERR_CERT_COMMON_NAME_INVALID: cause e soluzione

Come appare il messaggio

NET::ERR_CERT_COMMON_NAME_INVALID – This server could not prove that it is www.example.com; its security certificate is from example.com.

Certificato solo per example.com, ma si apre www.example.com (o viceversa).
nginx serve il certificato di un altro vhost perché nessun server_name corrisponde e risponde il default_server.
Aggiunto un nuovo sottodominio senza estendere il certificato.
Accesso tramite indirizzo IP o hostname interno.
Il DNS punta a un altro server, ad es. vecchio hoster o CDN senza certificato adatto.

Mostra i nomi nel certificato servito (SAN)
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
Mostra i certificati Let's Encrypt esistenti e i loro domini
certbot certificates 2>/dev/null | grep -E 'Certificate Name|Domains'
Mostra server_name, percorsi dei certificati e default_server
nginx -T 2>/dev/null | grep -nE '^\s*(server_name|ssl_certificate|listen .*default_server)'
Verifica che entrambi i nomi puntino allo stesso server
dig +short A www.example.com; dig +short A example.com

Estendi il certificato con il nome mancante: certbot --nginx --expand -d example.com -d www.example.com.
Crea per ogni nome un server_name con il giusto ssl_certificate.
Configura un default_server separato con certificato fittizio e return 444;, così i nomi sbagliati non finiscono su un sito cliente.
Controlla il DNS se il certificato arriva da un server estraneo.
Dopo le modifiche nginx -t && systemctl reload nginx.

No. I browser moderni ignorano il CN e controllano solo la lista SAN. Anche i certificati autofirmati devono quindi avere un subjectAltName.

No. *.example.com copre www.example.com, ma non example.com né a.b.example.com. Il dominio principale va aggiunto.