DNS issues 3

I too clicked on “Enable DNSSEC” before checking to see if my registrar supported it - it does not.

Clicking “Cancel Setup” does not return it to its original state. The KB article on this essentially says to “try to convince the registrar of the error of their ways” - which is not an acceptable, technical solution.

So, here I am with my site serving up this error message:
Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP

Is there an evolution of it rolling back?(i.e. does it have to propogate back to the original setting?) If so, that should be noted somewhere in the KB.

I am all for DNS security, but I am also a fan of the old agile saying, “deliver working software”. This breaks my site with no visible method of rolling back that I can see… that does not sit well.

Oh nice, I just got an email from the support ticket that I just filed… essentially telling me that I am ‘on my own’… lovely way to treat your customers when they are trying your service out as a proof of concept.

Argh. Not happy at the moment.

So yes, it did propagate back after a period - as I expected it might.



This is an error received when the users are attempting to access your site over SSL and a certificate has not yet been issued. It’s not a DNSSEC error.


And your SSL cert has now been issued and the site is responding over SSL.


That is an AMAZING coincidence that it happened EXACTLY at the same time I tried to configure DNSSEC and it went away after a period where it rolled back.

Now, not sure how long you’ve been in the business, but nothing… happens by coincidence. Since the SSL had been set up for days - and working - not sure how it miraculously fixed itself afterward. Dave’s rule: nothing happens by coincidence and nothing fixes itself.

If you notice, the error was a cypher error. Doing some research (not just coming up with a knee jerk response to place blame on the customer), it seems that this is an algorithm mismatch error. But hey, why try to fix the problem when it is easier to blame the customer and other service providers.

so far, I am giving the support team a zero… not impressed at all.

First: calm down a bit, everyone here is trying to help out, for free, in their free time. This is not the standard support, but a user community.

Getting to the issue at hand, DNSSEC errors appear at DNS resolution time, it would have been an error of the type “can’t find the server” or something similar since a validating resolver failing the DNSSEC check for some reason would not return response for anything in your domain.

A SSL_ERROR_NO_CYPHER_OVERLAP, while completely plausible for it to be on Cloudflare’s end (I doubt that is the case as I have never seen one happen), is SSL related in the browser <-> server connection (with a response from DNS, so no DNSSEC errors). Could it be possible that for some strange reason your IP changed (the :orange: turned :grey:, the NS changed temporarily, etc.) and the certificate then failed since it wasn’t a valid one (if there was even one on your origin server).


Not particularly amazing. You made a lot of changes in a very short period of time and simply misattributed the cause of the error. Cloudflare has a lot of moving parts, it can be difficult to determine what is going on sometimes.

28 years.

It wasn’t a coincidence it was caused because your traffic was routing through Cloudflare for SSL and there wasn’t an SSL certificate on our edge for your domain. My response wasn’t a question or a guess.

Your zone was onboarded to Cloudflare yesterday, so it is not possible that an SSL certificate was issued by Cloudflare and pushed to our edge for your zone prior to that. It may be that you have an SSL certificate on your origin but when Cloudflare acts as a proxy it also acts as an SSL termination endpoint. Once Cloudflare issued an SSL certificate the issue was resolved (my second response wasn’t a guess either).

It is a pretty common error customers encounter when first onboarding to Cloudflare. I explained the cause and I’m sorry if you felt blamed when it was attributed to something else.

Well I’m not on the support team, so I hope you won’t hold my answers against them. However as far as technical accuracy goes… if you will inspect the certificate displayed for your site you should see that it was issued by Cloudflare which should confirm my assertion that Cloudflare acts as an SSL termination endpoint.

Remember: Life is pretty good.


I apologize that you were inconvenienced by the error, we do try to make the process as seamless as possible but there are a lot of moving parts and things don’t always go smoothly. We’ve made a number of changes to our SSL issuance pipeline and the process overall is much faster and more reliable than it was previously.


Determining if we could/should :orange: a record from the very beginning is a topic we debate quite often internally. The downside to not automatically :orange: a record is that it relies on the user to make a change later and since Cloudflare has a lot of moving pieces it is quite possible they may not make the change and that leaves them vulnerable for the long term.