domain is registered at namecheap
site hosted at dreamhost
namecheap points to ns1.dreamhost.com ns2.dreamhost.com ns3.dreamhost.com
enabled cloudflare free via dreamhost
site no longer works
contacted dreamhost support and they suggested pausing cloudflare: it works
when i unpause cloudflare, it no longer works
the error i get is SSL_ERROR_NO_CYPHER_OVERLAP
the error from dreamhost support screenshot is ERR_SSL_VERSION_OR_CIPHER_MISMATCH
any help or suggestions appreciated thank you!
Hi there,
You should change your nameservers at Namecheap since they’re the authoritative DNS for your domain, not DreamHost.
Take care.
1 Like
thank you should i point them to cloudflare?
Hi there,
Yes, as long as you have a valid certificate at your origin server, or you set your encryption to Flexible in your Cloudflare dashboard, or you create and install at your origin a Cloudflare origin certificate.
As it stands, traffic is not even going through Cloudflare, so there’s not much we can do about it.
Take care.
Sorry, but this is quite bad advice, as that’s an insecure legacy encryption mode which will break the site and keep the OP’s site without encryption.
The encryption mode should always be Full Strict and the OP seems to have a working SSL setup anyway, considering that he said it works when paused.
2 Likes
hello i did as you mentioned and copied all my dns records from dreamhost over to namecheap and it didn’t work
namecheap support identified:
> Type CNAME| Host mta-sts| Value mta-sts.<DOMAIN>.org.cdn.cloudflare.net.
> Type CNAME| Host www | Value www.<DOMAIN>.org.cdn.cloudflare.net.
> Type CNAME| Host www.mta-sts| Value www.mta-sts.<DOMAIN>.org.cdn.cloudflare.net.
> These records seems to be created correctly, however, they resolves to nowhere, so it will be needed to clarify them.
> Also, these A records:
> Type A | Host @| Value 173.236.159.206
> and
> Type A | Host @| Value 2607:F298:0005:103F:0000:0000:0E17:36DB
> Type A| Host ssh| Value 173.236.159.206
> Type A| Host ssh| Value 2607:F298:0005:103F:0000:0000:0E17:36DB
> Sorry for such kind of records 2607:F298:0005:103F:0000:0000:0E17:36DB it has AAAA type of record.
> As they are created for the same Host, there can be a conflict between records. Exception is when the IP address is provided with one IP provider.
dreamhost identified:
Ah, from what I can see, this is still the legacy setup for Cloudflare when using DreamHost’s nameservers
both namecheap and dreamhost support suggested i use cloudflare dns instead so i deleted the previous dreamhost integration setup of my domain and started from scratch by clicking add new domain which imported some but not all of dreamhost dns records. i made sure all the A MX and TXT records matched but deleted AAAA and CNAME records
i am currently awaiting dns propagation but did receive an email from cloudflare saying my domain is now active on Cloudflare Free Plan
can you check to see if everything is setup correctly? do I need to add AAAA and CNAME records?
thank you!
this seems to work now
it didn’t initially so i disabled ip6 on dreamhost as i didn’t bring the AAAA over as it was flagged by namecheap support
still didn’t work
but noticed in cloudflare there was suggestion to add www A record which i seemed to have forgotten to add and that did the trick!
the site now works
i will try to re-enable IPv6 and add AAAA record
as a sidenote cloudflare also suggested to add a DMARC record so i added that
seems adding AAAA record breaks the site again
i removed them
website hosted at dreamhost
using cloudflare nameservers
when i enable ipv6 address on dreamhost and add AAAA record(s) to cloudflare dns my site stops working
do i need to remove the corresponding A record(s)?
You don’t need A and AAAA records for the same hostname. Cloudflare will always publish A and AAAA records for any 
hostnames. When A and AAAA records exist for the same hostname, Cloudflare will always send traffic to the A record IP address.
Unless your area trying to solve an articulable problem by using both, I would choose only one, preferably the one that works.
1 Like
thank you!
i removed the corresponding A records and now everything works!
thank you all for your insight and assistance!
1 Like
Hi there,
I’m not analyzing if it’s the ideal or not, simply replying to OPs question of what can fix the issue. It’s not my decision to make.
When replying I try to cover all aspects, and although Flexible might not make sense to you, believe it or not, there are still reasons to use it, depending on use case, that’s why Cloudflare still has that option for customers to choose from.
Take care.
1 Like
This topic has been discussed endlessly and the conclusion is always the same. Recommending an insecure legacy mode is counterproductive in every sense and will not only keep the OP’s site insecure but will also break it.
1 Like
There was never a reason to use it, and it is easily the one thing that Cloudflare offers that dramatically reduces the security of the internet. It has convinced the technologically unsophisticated that they can secure a site while still sending unencrypted traffic across the public internet. Worst of all, it is indistinguishable to the visitor from traffic that has been properly secured.
Without even considering the MITM angle, which we know is required to deliver services, all traffic that uses the Cloudflare proxy could reasonably be considered insecure since there is no way for vistors to differentiate Flexible from Full (strict). Flexible puts all Cloudflare client visitor traffic at unnecessary risk. It really should show the same browser warning that an HTTP connection does.
Any problem that can be solved using Flexible can usually be solved using Full (strict) with negligible effort.
2 Likes
Hi there,
I can’t say that I agree or not with you both. However, I would not be a very good support engineer if I only presented my preferred solution instead of giving users the freedom to choose for themselves.
As for if Cloudflare should or not have the option available, as you might imagine, it’s not my decision to make, but in our defense, the default mode when you add a new zone is Full and the Flexible mode has proven useful at times for testing and debugging purposes (usually pointed to unimportant/test subdomains or zones).
Either way, the user issue is fixed and that’s all that matters.
Take care.
1 Like
It’s not so much about subjectively preferred solutions, but about proper solutions. Especially as a support engineer of a company who prides itself of making the Internet better, it is naturally important to provide secure solutions, which Flexible unfortunately is not. As with the dozens of other cases the forum gets every day, that legacy mode would have actually made the OP’s site inaccessible. In short, Flexible is an insecure mode and should never be selected. As mentioned, this has been discussed endlessly and always with the same conclusion. @epic.network beautifully summarised a half decade long topic in one posting.
But yes, the issue has been fixed and should we want to continue the discussion we should probably do so at a more adequate location.
3 Likes