I was told by my TL today that replacing the Edge certificate by mistake with a wrong one, and then after one hour reverting it back (to correct subdomain names) will cause errors for all users, for the next 48 hours, because the DNS propagates too long (no idea how DNS is related, that’s why I’m asking here, he did not explain, just said I broke everything for the next 48 hours and that’s it).
Everything got back to normal immediately after I reverted the TLS cert, so I wonder what could really cause problems for a few days for all users when just the TLS cert gets rotated back and forth? After all, the certificate gets presented to client browser during negotiation and establishment of a new session, so the only thing which can go wrong - is a broken session, until a new one is established, so it will be different from browser to browser, is that correct?
The full story is: I generated a cert, thinking I am going to just download it and use for my nginx to try something on a new subdomain, but instead, the newly bought cert got applied to all edge servers - because this is apparently how cloudfront works, and I didn’t know that, and probably missed a warning if there was one… Long story short, one of our engineers noticed broken production homepage, I immediately realized it’s about the cert, went to “Edge” tab and recreated a new certificate.
But now I am worried what if cloudflare Edge servers work in some special way, like from now on, both the bad and the good certificates will randomly be served from some servers or others? But it doesn’t sound possible, if it would be the case, CloudFlare would not be worth a penny as a CDN, so I don’t believe it can be like that.
What was the actual issue, respectively error? Certificates are unrelated to DNS and changing the certificate won incur any propagation time, so that information was incorrect.
What you wanted was an Origin certificate for your server but you got an Edge certificate for the proxies instead.
I issued a certificate with new subdomain names, and it didn’t include the production subdomains.
It caused broken TLS sessions for some users who had session open. But it cannot last more than 10 minutes (average for browsers, the session time), after the correct certificate was reverted back, right?
How long on average does it take for CF to propagate the newly create TLS edge, to all proxies? I wonder if my ‘bad’ certificate was hanging there longer than expected… or something like 2-3 minutes at most?, because it’s just a tiny file which is easily distributed (like when using consul-template, a small file is easily rendered in matter of seconds from the moment it changed in the source of truth).
Alright, though my question was rather geared towards the actual error message. If the hostnames actually resolved and you only got an error regarding a mismatch of the certificate name, it wasnt DNS related as you were told.
Deploying new certificates should be pretty instantaneous. If not within seconds, I’d expect it to be within minutes but definitely not days. Of course there is the possibility that something hung, but thats difficult to say at this point and most definitely difficult for the community . You could contact support for clarification.
However, without knowing the actual error message it will be difficult to debug, especially in retrospect.
Thanks @sandro! I just wanted a confirmation from others in the industry, that a DNS story is not related here and there is no chance to actually break many connections for a few days. I’m glad he was wrong about this certificate issue. Indeed there were no problems, we haven’t received a single support ticket since then so all systems work as usual. Phew, I was scared I didn’t know something about how cloudflare works .
It might be an idea to clarify what he actually meant. DNS and SSL generally are not connected at all and certificates do not really know any lengthier propagation issues which one sometimes encounters in a DNS context. So if you just issued an incorrect certificate and fixed that straight away, that should have been undone equally fast.
The only connection between DNS and certificates are CAA records, whereby one can specify via DNS records which CAs are authorised to issue a certificate, however that shouldnt have played a role here.
Yup, I tried to clarify but he didn’t explain yet. I think it was a confusion with a recent DNS migration they did from route53 to cloudflare DNS. Am still waiting for the explanation, probably will get one tomorrow.
. You could contact support for clarification.