I have a web service with a very large number of custom domains–it’s a link redirection tool specifically geared for this use case, in fact–and in general adding a new domain is not an issue; but for one of these domains which previously was used as a bit.ly custom domain (i.e. also for link redirection), when the domain’s owner sets the A record to the render IP and waits (over 2 hours in the last attempt), when the DNS record propagates, they get a err_cert_common_name_invalid error when they try to visit:
If they click ‘proceed’ the behavior is otherwise as expected.
Any ideas here? Unfortunately because the domain owner is trying to migrate a live service with user traffic, they can’t leave this live long enough for an extended debug–they’ve since switched the DNS records back to pointing to bit.ly. I have over 100 other domains set up the same way (mostly with ALIAS records instead of A records, but some A records also working properly). The one difference here versus my other domains is that this is a switch from a previous use of the domain with a different SSL certificate, rather than a brand new domain, so I am wondering if there is somehow a caching component to this/it may be specific to browsers that are expecting a different SSL cert for this domain, but even if that’s true we’d need to figure out how to resolve for those users.