Yesterday, Today on the Cloudflare Community

Welcome, welcome, welcome to Cloudflare TV.

Welcome, welcome, welcome everyone. My name is Tim Cloonan and welcome to Yesterday Today on the Cloudflare community.

Yesterday Today is a, if you're new to the show, and you are because today's our first episode.

Yesterday Today is a bit of background.

Every Friday we talk about what happened on the Cloudflare community and we give a rundown of the types of activities that we saw.

The community has thousands of members and while we have a lot of members and we have hundreds of visitors that visit the community every day, we have 17 folks that are in the community that are part of the community MVP program.

As part of the community MVP program, these are the 17 most active of the active users on the Cloudflare community.

Today we're joined by two. I'd like to welcome Mateo and Dom to Yesterday Today on the Cloudflare community.

We're going to talk a little bit with them about some of the things that have been going on with the Cloudflare community.

And we're going to join that discussion in a little bit. If you have questions that come up, we encourage you to email livestudio at Cloudflare.tv, livestudio at Cloudflare .tv.

And we'll be taking questions from the audience through the course of the presentation today.

First, I want to talk a little bit about what was going on in the community.

The most popular area for discussion last week was DNS and networking with questions about name server and expired domain names leading the category.

Other popular areas for discussion were the firewall and DDoS mitigation.

Overall traffic to the community was up slightly last week.

It's up dramatically over the course of the year.

And we had the top searches on the community last week were for 524 errors, which is a timeout, DNS, non-existing domain error, and a security error, a cipher mismatch.

These are three fairly common areas that we talk about. And with a 39% click-through rate, the 524 error was the most popular thing that was discussed on the community last week.

Normally, at this point in the show, what we would do is we would dive into a 524 error, we would talk about different ways to fix it, and we'd go into a lot of detail about what you can do when you encounter that error.

The reality of it is that a 524 error just isn't that interesting, and it's fairly easy to fix.

And so we're not actually going to focus on the 524 today.

We probably will in a future episode. But for today, what we would like to talk about is something that affects a lot of people.

It affects people every day.

We see it quite commonly, and it wastes a lot of time. And ultimately, it's rather easy to fix.

And that's why we want to talk about broken SSL. And broken SSL manifests itself in a whole bunch of different ways.

We see it quite frequently, and we understand that it's quite a frustrating issue when it occurs.

So we're going to delve into why is broken SSL happened and what we can do about it.

Joining me today, we have two of our community MVPs, as I mentioned earlier.

Dom, Matteo, welcome to Yesterday Today on Cloudflare Community.

Thanks, Tim. It's great to be here.

Thanks, Tim. Welcome. Happy to be here as well. Thank you. Fantastic.

Welcome.

Matteo, do you have some thoughts in terms of what can folks do when they see broken SSL?

Where do we start? Yeah, sure. We have a lot of possibilities at the start. But what we do first is usually check if the domain is actually working.

So let me share my screen for a moment, and I'm going to show you exactly what I do and what we do, because usually the first step is usually common to everyone.

So the first thing we do here is we are going to check if the domain is active.

So to check that, we need to check if the name servers are applied and these name servers are correctly set up.

So we're going to check a domain like this one, which we set up today.

In this case, it's this domain. And you can see the domain name servers are georgia.ns.Cloudflare.com and jonah.ns .Cloudflare.com.

In this case, we are going to see and check they are correctly spelled, correctly working.

These are often misspelled, more often badly written.

There are often errors. Like the other day, Chris said something that we should always do, and we are chanting about it, so we should always copy and paste this.

And this is the best thing that you can do, because that's always the most common error.

You should set them up correctly at the registrar.

You should set them up in the DNS currently. There are a lot of things that you should and can do.

Just for example, if you do like Google's search and we search that, we can see that name servers in that case are different.

So if we see something like this, we're going to see and say, okay, there's an error there.

Probably the first thing to do is fix that. But if this is correctly configured, and often it is, but if it's correctly configured, then we need to check if the actual domain is correctly configured in the DNS settings.

So we need to check if it's replying to actual DNS queries.

And this is done easily and with a big comment.

You're going to see this is an example. So in this case, we're going to see three IPs.

It's normally three or two if you are proxied by Cloudflare. It depends on the plan level, on the timing, on whatever issues there are at the moment.

It varies a lot, but usually it's two or three IPs. And these are almost always recognizable.

I can tell these are Cloudflare IPs, but sometimes you can't because, for example, this 172 version has been added lately.

And that IP may be strange.

You can wonder what it is. So you can do something like this using the same way as before.

You can search for the same IP. And in this case, you're going to see that it's Cloudflare.

You can see Cloudflare.ink and so on. In those cases, you're going to be sure that they are correctly configured and that the traffic is proxied.

So in this case, this is the most common setup. This is the full setup, the full working setup.

There are some possibilities like the partial DNS setup, which is normally only for business and app customers.

So it's normally rare to see.

But that's an example in which you can see a name server different from the Cloudflare version.

And you're going to see name servers randomly. But the one thing that you can check for is doing the dig comment as I did before.

Instead of showing IPs, you're going to show a CNAME to a subdomain of cdn.Cloudflare.net.

In that case, you're going to see that it's actually configured, but it's just in a different setup.

This obviously requires that the user can share the domain name. Sometimes it's not possible.

Sometimes they are, for privacy reasons or for security reasons, they can't share the domain because they don't want it publicly available or they don't want people looking at it.

Or maybe it's something that they've blocked for some regions and we are not allowed to enter it for some specific case.

So in that case, we are going to say to them these steps and we're going to basically tell them what to do.

And they are going to reply to us with the actual checks and if they pass and so on.

Normally, this works if this is the issue. It's going to be a quick fix, but sometimes it's not going to be.

And so you're going to see some specific errors, for example, in some specific subpages.

And in that case or in the case that the actual configuration is perfect, we need to dig a little bit deeper.

So I'm going to switch it off and pass it to Dom to see if it's actually what we can do if we dig deeper.

And so please go ahead, Dom. Thanks, Matteo.

So, yeah, once you verify that the domain is correctly configured with Cloudflare, as Matteo said, with the name servers and checking that it's proxied through Cloudflare, then there are a few steps that you can take if SSL is still not working.

So the first one is if you want your website to appear with HTTPS all the time, then you need to redirect visitors to the secure version of your site.

And Cloudflare has a really easy setting to do this called always use HTTPS, which will redirect any visitors to the HTTP version of your site to the secure version.

And it's a simple toggle that you can find under SSL TLS edge certificates in your dashboard.

And you can just turn that toggle on and it will redirect all your users to HTTPS.

If you find that correctly configured and you've already got that enabled, then the next thing to check is whether you're actually going through Cloudflare.

It may be that others can see your site OK with the Cloudflare certificate, but you have some previous values configured or cached on your device.

So you can tell if requests are going through Cloudflare in two ways, either in the terminal using curl or using developer tools in your browser.

So the first way I'm going to share is in the terminal.

So in this example, I'm just going to use the curl command, which sends an HTTP request to this domain broken SSL1 .cf.

And that's going to return the headers. So in this case, you can see the server is showing as NGINX, which means that it's not going through Cloudflare.

But if I use the second domain, broken SSL2.cf, you can see here that we have the server Cloudflare header, and we can also see some other Cloudflare headers like the CF request ID, the ray.

But the easiest way to check is if you see this server Cloudflare header.

The other way, if you don't want to use the command line, is to use developer tools in your browser.

And so on this example here, we're back to broken SSL1.cf, the one that's not going through Cloudflare.

You can open developer tools in a few different ways.

You can use F12, the shortcut in Chrome, or Control Shift K in Firefox, or you can access it through the browser menu.

Once you've got developer tools open, if you go to the network tab in there, then you'll see all the requests.

In this case, it's just a simple HTML page. There are not many requests.

But if we just click on the request for the main page, you can see the response headers over here on the right -hand side.

And you can see, again, you've got server nginx.

But if I go to this domain, I've got the Cloudflare headers, and I've got server Cloudflare.

So that's how you tell if your requests are going through Cloudflare or if you're bypassing Cloudflare.

If you don't see the Cloudflare header, then there are a few reasons that that might be caused by.

You might have an entry in your device's hosts file, which would configure your browsers to send requests to a specific IP address, usually, for that domain.

And so if you've got that configured, then your requests will not be going through Cloudflare, and so any of the settings you apply won't take effect.

The other thing is your device might have saved the IP address of your site in its DNS cache before you configured Cloudflare.

And if you think that might be the issue, then you can search how to clear your DNS cache on your specific operating system, which should help to resolve that.

Once you've verified that your requests are going through Cloudflare, the next thing to check for is if you have a padlock like this.

So the site's loading over HTTPS, but you've got a broken padlock like this.

In Firefox, it shows that parts of this page are not secure.

There are different error messages in different browsers, but it's generally a message, something like partially secure or not fully secure, and this is generally caused by mixed content.

But we'll dig into that a little later, and I'm sure that that will come up in some questions.

The last thing to check is if you get this error, which is one of the most popular ones searched from the community that Tim mentioned earlier, which in Chrome is the error SSL version or cipher mismatch, and in Firefox, it shows like this, SSL error and no cipher overlap.

It could mean two things. It might mean that your Cloudflare certificate is not yet provisioned.

So in your Cloudflare dashboard, if you go to SSL TLS edge certificates again, you can see here that the status of the universal certificate is active, but this might show as pending, and it can take up to 24 hours for the free universal certificate to issue, but it's normally much faster than that.

So if after 24 hours, this is still showing as pending and not active, if you scroll all the way to the bottom of this tab, you can disable universal SSL, wait a few minutes and re-enable it again, which will restart the process and should get you your active certificate.

The other reason you might see this error is if it's on a subdomain.

So Cloudflare's universal certificates support one level lower than the main domain.

So they would support www .example.com, and they would support subdomain.example.com, but they wouldn't support www.subdomain.example.com or a.b .example.com.

So they would only support one level below the main domain, and that can be another issue that can cause this error.

Now, if you do want to have host names that are multi-level subdomains, you can do this in Cloudflare, but you'll need to purchase an advanced certificate, which you can configure custom host names on that one.

So that's about it. I've just run through the most common fixes that you can see with SSL issues.

That's pretty amazing to see you take that apart like that.

There's a lot of trouble that folks have with this, and in the community it seems like people thrash when they see this, and it's almost like they don't associate a flaw in their code with a security break or something about that, and it seems like there's a lot of frustrations that's expressed around this.

Mateo, where do folks start?

This comes up. You're not around in the community for that minute.

What do people do? Well, first of all, as I said before, and I'm going to repeat it forever, it's going to be double and triple check your name servers, copy and paste them again, and be sure that they are correctly set up.

That's the main issue that people don't get because their site doesn't become active until those name servers are correctly there.

Then you need to check if there are no possible loops because sometimes it happens that websites loop again and try to redirect you to the HTTPS version while you're already on the HTTPS version because maybe you have the setup as flexible on the backend, and so you're going to connect to the origin in HTTP, but the actual user is connecting via HTTPS, and so you're redirecting yourself to the same page, and that's not going to work.

Obviously, that's not the best configuration you can have. You should probably have something like a full or full strict configuration, but for some specific reasons, maybe you don't have the ability to do that.

You should really try, though.

Obviously, if that's the case, you can maybe toggle that setting, maybe set it to full or remove the redirect on the origin, and it's going to work again.

Then sometimes, as Dom said, maybe there is propagation issues, so maybe you're not going to see the DNS records already there.

Maybe you have set up something in your auth file, so you are going to connect directly to your origin forever, so try another device, try another network, maybe possibly complete a different device on a different network.

That's the best idea. You can ask a friend somewhere else to try, do something, and so in that case, it's going to work.

So those are the main issues.

Then the other possibilities, the other specific things you're going to do later, and they are not always the case.

These are the main things that are going to cover the vast majority of things.

Okay. There's a lot of things that folks have to do.

Dom, do you have any sense of what folks are doing to try to help themselves?

I mean, what should people do? Ah.

Okay, so there's some assets that folks have. Do you want to talk to what folks should do when they encounter this?

Yeah, sorry. So there are lots of different resources that you can find if you're facing any issue, not just broken SSL.

These are examples with mixed content, but on the Cloudflare community, there are lots of resources like the community tips, which collate information into a post on the community that cover best practices when you're configuring and using Cloudflare and how to fix any issues that you might find.

There are tutorials, which are posts that are written by the MVPs and other community members, which are intended to help you help yourself, and they cover a wide range of topics, everything from adding your first site and troubleshooting DNS issues to redirecting with page rules and best practices to prevent domain hijacking.

And then there are the expert tips, which are highlighted answers in the community from people in the know about frequently asked questions.

And then elsewhere off the community, you've got the Cloudflare Help Center, which is a great resource to help people find answers to common questions, and the Welcome Center, which is really good to help people get set up and get the most from Cloudflare, along with the Learning Center, which has got some really good resources with information on cybersecurity and how the Internet works.

And then you've also got the Cloudflare Developer Docs, which is documentation on the Cloudflare API and everything else that a developer needs to work Cloudflare, really.

Wow. That is fantastic. There are a lot of resources that are available. Where should – I mean, what do folks do when they encounter this mixed content?

And this did come up as a question in the community in terms of – or a question on the chat, that I've got mixed content.

Why is it broken in Cloudflare and it's not broken elsewhere?

Or I didn't encounter it earlier, I think, is kind of the notion of the question.

Yeah. Go ahead, Chris. I'm going to go ahead and reply. It's going to be – probably the issue most often is they don't know what to search.

Because, as you saw before, when Dom showed it to you, probably it's not specified that it's mixed content.

It's specified maybe in the console. You're going to need and go ahead and search for it.

But if you don't know what it is, the error, it's going to be hard to search and find exactly what the issue is.

So you're going to go ahead and try and search something which you don't know the name exact to it.

What's the name of it?

So it's going to be hard. And so that's probably the main issue. So once people know exactly what it is, there is tons of options around.

There is websites that help you.

There is community tips. There is tools inside the actual browser. There is tons of help.

But if you don't know exactly what it is, it's going to be tough.

So maybe, Dom, can you explain a bit about what exactly mixed content is so people know about it a little bit more?

Yeah. So mixed content is basically when your main site is loading over HTTPS, but there are some elements of your page that load over HTTP.

So I've got a demo site here that's just a really simple page again.

And in this case, it would be quite easy to see where the mixed content is, but there's a really easy way of doing it using developer tools, again, that I showed you earlier.

But instead of being on the Network tab like we were earlier, if you go into the console, you can see on this page that the reason we have the padlock with the warning symbol up here is because we're loading mixed content, and the mixed content in this case is brokenssl4.cf slash image.png.

And so if we go ahead and look at the source code of this page, you can see that although it's an HTTPS page, the link that's highlighted here to the image is specifying HTTP, which is why you see the mixed content warning because you've got the main page over HTTPS and then this image being loaded in securely.

And so this is fairly simple to fix in this case in that you can just replace the HTTP with HTTPS.

So on this version of the site, you can see we have the padlock and we don't have any warnings down in the console.

And if I have a look at the source code of this, you can see that I haven't replaced it with HTTPS, but what I've done here is just removed the protocol altogether.

And what this means is that the browser will use whichever protocol is being used to view the page.

So if you're viewing the page over HTTPS, then it will load the image securely over HTTPS.

And if you're viewing the page over HTTP, then likewise it will load the image in securely.

But if you have a larger site, then it can be time consuming to go through and fix every mixed content error individually like this.

So Matteo, are there some other options that require less work on the side of the web developer?

For sure there are, yeah.

Let me show you some of them. So if I go here where I was before, for example, here, I am going to go to the website we were on before, broken SSL 4, it's going to show the error.

It's going to not show the padlock. If I go in the dashboard, go in the SSL TLS tab inside here, edge certificates, if you scroll down, there is this automatic HTTPS rewrite setting.

If you set this to on, Cloudflare is going to change all HTTP references to HTTPS for links that they know is going to work on HTTPS.

So most CDNs, most services is going to work just fine. Obviously, it's not going to cover everything, but the vast majority of things is going to be fine.

In that case, if you have a lot of content and not everything can be automatically done because for some reason we have a website or something that's not technically supporting HTTPS fully or something, you can go ahead and use the other options.

So this is the actual test for the automatic HTTPS rewrites you're going to see.

It's HTTPS here, even though the page, the actual page is HTTP. This is one of the options.

You're going to go ahead and use the content security policy header.

This can be done also as a meta tag inside the HTML page. It's usually recommended to do as an HTTP header, but that is not going to be always the case because you need access to a modified HTTP header, which is not always easy to find.

You can use a worker to do that, but it's the easiest way is actually modify the source.

So it's there for everything. And in case like this, you're going to see the image.

It's not loading. There is an error here, which is blocked mixed content because all mixed content appears in the content security policy.

So if you go ahead in the network and go and look at the request of the HTML page, you're going to see in the response, there's going to be a content security policy header.

This is going to block all content.

This is not always the best solution because you're going to break the page in case there's something wrong.

So there is an alternative solution.

This can be done. As you can see, it's going to show the image, but it's going to still require, it's going to still work on HTTP requests.

And then it's going to show as a header inside the content security policy, but instead of block all mixed content, it's going to be, sorry, it's here.

It's going to be upgrading secure requests.

In that case, the browser is going to try all requests to HTTP instead of HTTPS.

It's going to go direct to HTTPS instead of HTTP. And in that case, it's going to basically force all requests to go there.

So if nothing, if it's not working for some reason, because the other service is not supporting HTTPS, the request will break, but otherwise it's going to load just fine.

So that's the best solution. Usually you shouldn't apply both of them together because you don't know exactly what the browser will do.

You should probably stick with upgrading secure requests, but that's a decision for each one, for each person.

Ideally, as I said, basically stay as an HTTP header, do not use the meta tag if at all possible, but maybe if it's your case, you need to do that, please do because it's best to do and not have the error.

So these are all the options that you can find.

There are some, the issue is probably, there are some edge cases in which this is the best solution.

So this is all for me. I'm going to hand it back to you, Tim, I believe.

Fantastic. Thanks Matteo. So we had another question that came in and first of all, I think that we have a large number of people viewing today that, and a range of skills, and which is consistent with what we see on the community.

We have kind of a range of skills that are there. We have people who are doctors and lawyers and accountants that have a website.

And we also have web engineers that have websites and we get questions from both of them.

I think this question came in from probably somebody who's, whose website is their, their nighttime job or their second job.

And the question was just netted out and maybe from each of you, maybe comment to what do I check first?

Like, where do I, what do I look at first?

That gets me most mileage out of this. If you're fine, I'm going to go ahead and start on, I'm going to take the case.

Now let's imagine that the website works.

If the website works, I would go ahead and check actually the console.

That's the first thing you do. You go and check the console. If the console shows some errors, that's usually the best way to fix things.

That's for me. If it doesn't work, then you need to go through and listen basically to what they said before and do the basic steps.

But I'm sure Dom has something else that is fine.

It is found useful because we are actually coming up on the half an hour. Yeah.

I would say just very similar to what you've already said, Matteo in that the first step is to see where the website works at all.

So if it works and you've got some warning in your browser, then use developer tools to look into that.

But if you can't open your website at all, then that's when you need to start looking at things like name servers and checking all the first steps that Matteo mentioned at the start.

So, but panicking isn't something that they should worry about doing.

It sounds like this is something that we can get fixed. Just taking apart and going through the steps that you've outlined.

Yeah, sure. Exactly. Exactly. Fantastic.

All right. We are just about at our time. Dom, Matteo, thanks for joining and everybody.

Thanks for viewing today. You can catch us every Friday on yesterday, today on the Cloudflare community.

Every week we start this day with the community.

We talk about what happened yesterday on the community, the popular topics.

We dig into a very, very meaty topic and we take that apart and we actually kind of diagnose how we can solve the problem.

So if you like what you saw today, we encourage you to come back again in a week and we'll see you next Friday.

Thank you very much.

Thank you. Thank you. Thanks. Thank you.

Thank you.