Certificate not Valid, even though it says it is

Yesterday Jetpack sent me a message that my site was down. Upon inspection, it seems that my SSL certificate is at fault. It says it's not valid, but when I look at the details, it says it is.

It's a LetsEncrypt one installed by DreamHost. The site has been running fine for months without issue, and I haven't made any changes recently. So there's no known causes for why this is happening.

I've contacted Dreamhost, and they seem to be working on it, but I've seen them install 3 new certs all without changes to the issue. Was wondering if there was anyone who knows what could be going on.

Like I said, nothing should have changes on the site, service, or with the hosting. I'd disabled auto-update plugins with Wordpress so that nothing breaks the site without me knowing.

My domain is: wrkbks.co

My hosting provider, if applicable, is: DreamHost

The website wrkbks.co has the correct certificate. It redirects to https://www.wrkbks.co. However, the certificate is not the appropriate, it does no contain the name www.wrkbks.co. Normally one need a certificate that covers both the two kind of names, with and without the www prefix of the domain.


So question, I usually have Cloudflare enabled. I turned it off so that I could check the backend. Would that make a difference? Or does it still need the www also? Wonder what happened in the process? Its all been automated by Dreamhost and like I said, hasn't been an issue before.


1 Like

Someone has been messing around. See the certificate history for your domain:

Yesterday, there were 3 certificates isused, all without the www subdomain and today another one, also without the www subdomain. The previous certificate from 30 March however, does have both hostnames included..

So I don't know what triggered it, but looking at the amount of identical certificates since yesterday, they don't really know what they're doing it seems...


It's all been done by Dreamhost support. I sent them a message to let them know what the issue is. So hopefully they'll figure it out soon!

Thanks! This is just enough over my head.

1 Like

That's for sure. Just got an email from them saying they've changed the A Record to point to their server and not the CNAME for Cloudflare, and they removed redirect to www so that the domain will worth without the www in the certificate.

WTH? From what I understand, cloudflare requires WWW.

Your domain DNS is currently set to use Dreamhost DNS, so it's not using Cloudflare at all.

Cloudflare requires that you use them for DNS, then they can do things like automatically cache your website and provide a default https certificate for it etc, it's free and it's pretty handy. To return to Cloudflare you'd need to switch your domain nameservers back to Cloudflare again but that's up to you whether you want to do that.

1 Like

Got the site going last night. I don't know why, but Dreamhost wasn't installing LetsEncrypt properly. No other issues before that or with other domains. But, I went ahead and purchased their paid option for another SSL provider, and that one did the trick. I guess $15/yr was worth it enough to not mess with Dreamhost trying to install LE anymore.

Thanks for letting me know what was going on.

1 Like

This isn't correct. Cloudflare only works over HTTP/HTTPS, but it will work on any hostname you choose to use--www.whatever isn't necessary, valuable, or even relevant to them.


According to Dreamhost it is. Tested it on a domain I don't have Cloudflare installed, and know I remove the WWW.

I'm familiar with both Cloudflare and DreamHost, so some more context:

  • Unless you explicitly opt-in to an advanced setting, CloudFlare doesn't care about the validity of a backend server's certificate (e.g. DreamHost). By default, Cloudflare will connect to a HTTP backend, self-signed/untrusted SSL Certificate, or expired certificate.

  • By default, Cloudflare will obtain a certificate for your domain in the following format: example.com, *.example.com, sni.cloudflaressl.com

  • DreamHost only uses HTTP-01 authentication for LetsEncrypt, their systems don't do wildcards. The DreamHost dashboard has a domain configuration option to determine if a domain should redirect from www. to bare, from bare to www., or do nothing. If one of the first two options are selected, their system will get a LetsEncrypt certificate for both www.example.com and example.com - if the third option is selected, it will only get a certificate for the domain you selected to host. Those redirects are handled within their systems, not within any user-accessible .htaccess file.

  • DreamHost's IPs are not guaranteed/static and may change over time. They offer an integrated CloudFlare setup where their systems can control a cloudflare account for updates, but if you set up a domain with normal cloudflare - it can get out of sync. You can also pay for a static IP too. Their integration with the managed/enterprise cloudflare requires some weird things with subdomains.

Nah. It's an automated system. Unless things are escalated, their first line of support is to change a setting, clear the cache, re-trigger the order/build. That fixes most things.

Basically the Dreamhost/Cloudflare integration is a bit fragile. It's easy to break.

If Jetpack got a site down and there was a certificate issue, it's almost definitely because that traffic was not going through Cloudflare's network and was entirely on Dreamhosts. If the traffic were on Cloudflare's network, they would have served it with a valid cert they obtained. There was probably a DNS update or some hiccup within Dreamhost, and cloudflare's DNS was not updated correctly.


Then their support is rubbish. After one or two unsuccessful attempts, you'd think they would start doing something different to debug an issue, instead of just keep doing the same and same thing over and over again, failing every time.

1 Like

Then Dreamhost are a load of blithering idiots. For just one counterexample (though doubtless millions could be given), see:

Note where the certificate comes from:

And, of course, note the lack of www in the hostname.


That's called "job security".
Why fix it?
If they did, then they would have less to do and some employees would have to be let go.


Pretty much every tech company's support has done this: they'll try 2 or 3 minor adjustments, then re-queue the automated systems. If that fails, it gets escalated to a higher support level that will intervene. That sounds like what they did here - after a few automated attempts, they fixed DNS records to pass.

That's only needed when setting it up on a bare/registered domain, not subdomains. I was told in the past it's because of a conflict between both companies having www->bare redirect systems, and this messaging was the easiest way for the largest number of users to configure their systems in a compatible way.

I don't have any contacts at Dreamhost anymore though, so I don't get special help :(. They were founded in the college next to mine, and a few friends were the first employees. That really spoiled me on getting priority tech support. They jumpstarted the company by converting a dorm room into a server farm for a few months, and funded everything with cash one of the co-founders made from selling webring.


Ha. Webring. I remember that. I used to run one called, "The Ring of Cool Personal Pages." Had just over 1000 members I think. Without Geocities, I may not have gotten into this field.

Side topic. And what's really really cool, a few years ago I had another site where I made and sold necklaces out of subway tokens. The creator or co-creator of GeoCities had made two separate purchases from me.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.