$ echo | openssl s_client -connect "www.certera.io":443 -servername "www.certera.io" -verify_hostname "www.certera.io" 2>/dev/null | openssl x509 -noout -issuer
issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA
$ echo | openssl s_client -connect "certera.io":443 -servername "certera.io" -verify_hostname "certera.io" 2>/dev/null | openssl x509 -noout -issuer
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3https://github.community/t5/GitHub-Pages/Does-GitHub-Pages-S...
Hopefully when I make some money I can move to a hosted setup where I can control it all.
~# dig -t A +short www.certera.io
certera-io.github.io.
185.199.108.153
185.199.110.153
185.199.111.153
185.199.109.153
~# dig -t A +short certera.io
185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
Looks like https://www.certera.io is going to github of which is only returning a cert for itself, and not his domain name.https://www.certera.io fails the certificate check.
It's a good example of the difficulty of getting TLS perfectly right.
In theory this set up is fine; the default behavior of all the browsers when typing "www.certera.io" is to interpret it as a request for http://www.certera.io.
But if the client has anything in place that automatically upgrades http to https before submitting the request, you're going to need a valid cert for the www subdomain in place or you'll throw a cert error before reaching the redirect.
Even if your site omits the www subdomain in production (as certera does), a lot of users will just type it in anyway. So, you better be ready to handle that request via https.