Hey folks,
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.
Looking at your Render service, I see that the y4ny.com and www.y4ny.com domains were never verified by Render as being correctly setup with DNS. This doesn’t mean DNS wasn’t correctly configured, just that we didn’t verify it. Once the verification happens, it should take a few minutes to provision the certificate and publish it.
If you visit your service’s settings page and scroll to the bottom, you can find the y4ny custom domains and click “Refresh” to reverify the domain. It might take a couple minutes for DNS changes to propagate so Render can see it.
After already dealing with downtime, I imagine it might be frustrating to think of incurring additional downtime to try the suggestion above. There’s a workaround to reduce the downtime, however, if you have control over the DNS for the domain. If you create the Render custom domain as *.y4ny.com (rather than y4ny.com or www.y4ny.com), Render will ask you to create an _acme-challenge.y4ny.com DNS record so it can verify and provision the certificate without needing to change the actual A records for y4ny.com or www.y4ny.com. Once the domain has been verified and you see the “Certificate Issued” badge, you can finally update DNS to point the records to Render.
I appreciate that this is a bit convoluted, and I’ve started a conversation internally to discuss how we can more-gracefully handle this sort of live migration in the future. In the mean time, hopefully this helps solve the problem at hand. Please do let me know if you have any questions about this.
Just to follow up here: we did the wildcard thing, and confirmed the certificate for *.y4ny.com was successfully issued by Render after creating the _acme-challenge.y4ny.com DNS record. However, when my user then later changed their A record again, they got the same behavior/security error as before. This time they waited it out and after around 2 hours everything seemed to start working, so we’re actually OK here. I wasn’t synchronously coordinating with them, so I never went to my settings page to force a refresh (at least, not after confirming the initial * certificate had been issued earlier in the day).
I’d also say that I do this for brand new domains several times a week and almost never go back and explicitly refresh the status on the custom domains added to the service, and it normally does work after 20 or 30 minutes max, so I still suspect there was some other ephemeral thing at play here too, perhaps? But I’m not sure, and just musing in case it’s helpful to you at this point, since the immediate issue is gone.
I’m glad things are working now, but the delay definitely seems curious. I’m going to create an internal issue to dig in to what might have gone wrong. Thanks for the helpful details!
