I had a very unexpected event today, when tried to generate a new TLS certificate, but did not want to apply it immediately, because just wanted to use it on my own nginx server to do some testing.
The new certificate that I created, got immediately applied the moment I purchased it, and there was no buttons to switch back to the old certificate (which had the right production names in it).
I think this part is very tricky, why there is no way to “toggle” which certificate is now being used on the edge servers? I did not expect the certificate to be applied immediately replacing the old one.
The question is, why this design choice, to make a new edge certificate one click away from getting applied to all servers? It’s pretty dangerous.
Unclear as to the steps involved here. By default Cloudflare issues a certificate for a domain (universal SSL) which covers *.example.com and example.com. You can also order custom certificates which are either dedicated (covers the same hostnames) or dedicated with custom hostnames, which covers the same plus additional explicit hostnames you define such as foo.bar.example.com. All of these take place immediately, but none of them deletes another certificate which might be in place and wouldn’t stop those from working on Cloudflare’s edge… instead the most specific certificate for a hostname would apply.
If you added a dedicated cert with custom hostnames for foo.bar.example.com it would take effect for that hostname, but the other certificates are still in place and would answer for requests to those hostnames. So nothing would break in that instance for previous hostnames even if the new one was incorrect/didn’t match what you intended, unless one had a previous certificate with other explicit hostnames covered by the universal (and you choose to delete it).
So not sure what happened here exactly, but adding a net new certificate on Cloudflare’s edge shouldn’t impact existing ones.
We had *.dev.example.com / *.stage.example.com / *.production.example.com certificate,
and I created a new one that had many other subdomains but did not include these ones.
So people started getting errors from cloudflare, it was a “unauthorized” permission, by nginx of cloudflare (as I remember from the error message the developers showed me).
Then I realized it’s my new cert got applied to all, also for their subdomains and for prod (like, a new cert doesn’t have *.production.example.com, so all sessions who already negotiated the TLS and are open, will break). Is that correct?
I am not sure I understand actually, does it mean that if I create 2 certificates, let’s say first I apply “.games.example.com", and after some time create another edge cert with only ".music.example.com”, cloudfront makes the “music” immediately available (which is what happened in my case because I saw it in browser where the error was), but also still keeps the old “*.games.example.com” active?
And both of them of course have the primary “.example.com" and “example.com” names. But the application (react UI) accesses both the sub and the sub-subdomains at the same time during same browser session when navigating the website. Maybe that behavior of the application was the problem at that point? It got a new certificate of only ".music.example.com” name in it, but page javascript was also trying to access “myaccount.games.example.com” and other subdomains, and that’s why it got an error?
lol the text formatter here ate up half of the asterisks, and left the other half o.O … but you see the point . I meant all of these subdomains are wildcards, and the UI accesses the TLD when you’re logged into a subdomain, and also might access sub-subdomains (don’t ask me why lol, let’s say “this is how the artist saw it” )
. I meant all of these subdomains are wildcards, and the UI accesses the TLD when you’re logged into a subdomain, and also might access sub-subdomains (don’t ask me why lol, let’s say “this is how the artist saw it” 
)