I have an S3-hosted static website and a Cloud Front distribution. THere is an A record in Route 53 pointing to the Cloud Front distribution. When I created the distribution, I accepted the default setting for the certificate. That is, I did not enter a certificate ID or request a certificate. When I attempt to browse to the site with Chrome, I get NET::ERR_CERT_COMMON_NAME_INVALID.
How can I view or modify the common name of the default certificate? It doesn't appear in Certificate Manager.
This is not programming or development and may need to be deleted but:
to answer as asked:
For most builds of curl (but not the Microsoft-supplied curl.exe on Windows, which uses schannel) curl -v https://host will display the subject and some other attributes of the (server/leaf) cert; the CN= part is the CommonName. Pretty much all Linux and most other Unix will have suitable curl preinstalled; on Windows you can either find and install a non-schannel build for Windows (which may not be so easy as it was when I was younger), or use WSL (which gives you a Linux build).
If you have OpenSSL, echo Q | openssl s_client -connect host:443 (for versions below 1.1.1 you may need to add -servername host) will show the subject and issuer names of all certs in the chain (as validated, which may differ from sent in the CA(s) but not the leaf); you want the '0 s:' line, or the repeated info at Server certificate / subject= a page or two down. Again nearly all Linuxes and Unixes have OpenSSL; for Windows you can get a port from http://www.slproweb.com/products/Win32OpenSSL.html or again use WSL. (Instead of echo Q | you can use </dev/null on Unix or <NUL on Windows.)
If you have Java, keytool -printcert -sslserver host shows a lot of info about the cert chain; the first lines Certificate #0 / ===== / Owner: are the ones you want. 15 or 20 years ago when Java was considered the wave of the future it was available almost everywhere; today not so much. I wouldn't install Java just for this, but if you want it for any better reason(s), go for it.
but you don't want to.
That error code in Chrome is very misleading. Decades ago it was the standard or at least usual convention to use (and verify) CommonName in Subject to be the server hostname. Since about 2010 all public CAs, and most others as well, switched to using the SubjectAlternativeName aka SAN extension instead. Initially browsers continued to accept CommonName if SAN is absent, but since about 2017 Chrome only uses SAN and never ever looks at CommonName. So that error code now actually means SAN doesn't match or is missing; CommonName may well be correct, and even if it is wrong fixing it won't fix the Chrome error.
so how do you fix SAN in CloudFront? I can't help there.