Issue with Port 80 after TLS-SNI-01 update

Server
1

CentOS 7
Apache 2.4.6
Certbot 0.31.0

Hi,

I have an app called Superstar Band Manager which has the facility to load and save games from urls on http://superstar.band.

This has been working fine for years before using any SSL certificate and continued to work when I added the Letsencrypt SSL certificate a few months ago.

However, after recent emails from Letsencrypt, saying action is required as my "client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 7 days. " I set to work fixing this issue.

I updated Certbot to the latest version but when I tried a dry-run, I got the following error:

"Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80… Skipping.

All renewal attempts failed. The following certs could not be renewed…"

After some Googling, forum trawling etc, I added a file to the conf.d folder which consisted of:

NameVirtualHost *:80

<VirtualHost *:80>

ServerName superstar.band

ServerAlias www.superstar.band

DocumentRoot /var/www/html/superstar.band

</VirtualHost>

Bingo! After rebooting Apache, I did a dry run and the certificate renewed successfully.

However, a few days later, I’m getting complaints that the in-app loading and saving isn’t working.

I tried it myself and yes, loading and saving isn’t working.

So I deleted the new file from the conf.d folder, rebooted Apache and loading and saving is working again…

… but the Certbot dry run is failing again!

My question is: how can I set it up so that both loading and saving and Certbot will work correctly?

I have a Crontab set up that runs Certbot every night and have happily left it doing its thing until this recent change I had to make.

Hope you can help.

Many thanks,

Sean

2

Hi @SeanW

first, your certificate is ok (checked via https://check-your-website.server-daten.de/?q=superstar.band ):

CN=superstar.band
	11.03.2019
	09.06.2019
expires in 82 days	superstar.band, www.superstar.band - 2 entries

So both connections are secure.

But there are two problems:

Domainname Http-Status redirect Sec. G
• http://superstar.band/
104.239.144.77 200 0.410 H
• http://www.superstar.band/
104.239.144.77 200 0.383 H
• https://superstar.band/
104.239.144.77 200 1.693 I
• https://www.superstar.band/
104.239.144.77 200 1.476 I

You don't have redirects.

And you have mixed content, so your Grade is I.

This script

http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js

is loaded via http. But that's active content, so browsers block it. If you use this script to upload, your upload can't work.

And you should add redirects. There may be warnings if a user uses http and the upload function.

3

Hi Juergen,

Thanks for a quick and thorough response :slight_smile:

I’m pretty much a newbie when it comes to this side of stuff.

I can fix the jQuery issue by changing it to a https request, although that won’t effect my load/save scripts as they just call a PHP file on the server.

Could you point me in the direction of 1) why I need redirects and 2) how to do them on the server set up I’m using?

Also, once I’ve done all this, will this definitely mean my load/save scripts will still work within the app when I reinstate the <VirtualHost *:80> stuff in the conf.d folder?

Thanks again :+1:

Sean

4

It's a server side script that doesn't work with https?

Perhaps the port-443-vHost has different settings then the port-80-vHost.

Your users shouldn't use http if they upload something. But that requires server side redirects.

RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

in your port 80 vHost.

5

Thanks again Juergen.

I’ve changed the jQuery file to be loaded over https:

I’ve also added a temporary redirect (until I’m happy it’s all working) to my port 80 vHost.

I’m still getting an I Grade though.

Here’s the port 80 vHost. No idea where the port 443 vHost is:

NameVirtualHost *:80

<VirtualHost *:80>
ServerName superstar.band
ServerAlias www.superstar.band
DocumentRoot /var/www/html/superstar.band
RewriteEngine on
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R]

After rebooting Apache, the load functionality is working but there is a problem with the save functionality which I’m currently investigating.

6

In your css/styles.css, there is a http link

http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800

Change that to https.

Check your config:

/etc/apache2/
|-- apache2.conf
|       `--  ports.conf
|-- mods-enabled
|       |-- *.load
|       `-- *.conf
|-- conf-enabled
|       `-- *.conf
|-- sites-enabled
|       `-- *.conf
7

Great, updated the http link in styles.css and I’m now getting a C grade :smile:

I can’t see a folder called apache2 in the etc folder though :frowning:

8

Hi, still no sign of the apache2 folder in etc :slight_smile:

However, with the latest changes, we’re very close:

  • Android loads and saves data fine now
  • iOS loads fine but there is an error pop up when saving. This error message appears when the server has not received any POST data

For clarity: the load game method uses GET, the save game method uses POST and GET at the same time

I’m wondering if there are any extra flags for the rewrite rule that could fix this?

Thanks again,

Sean

9

I believe CentOS puts those files in /etc/httpd rather than /etc/apache2.

10

Hi, thanks for your reply.

I’ve had a good look in /etc/httpd and its subfolders but still no sign of any of those files.

See the screenshot:

54

11

Your configuration files are likely to be in the conf and conf.d subdirectories (and possibly conf.modules.d but those are more likely to be files managed by your operating system)

Incidentally, I’m still not seeing any redirect happening on your site. But… if the port 80 configuration is having any effect on your app, that would be a sign that the app is making its initial request over HTTP, which would be a problem in itself. It should make the request over HTTPS in the first place :slight_smile:

12

If you have a Grade C, then your certificate and your connections are ok.

It's a problem of your script, not a problem of missing redirects.

But you don't have a Grade C, you have now H ( https://check-your-website.server-daten.de/?q=superstar.band ).

You have removed the redirects http -> https, so users with http don't use https.

13

I have removed the redirects temporarily as users on iOS were having problems saving. Hence why it’s not Grade C at the moment.

I need to get to the bottom of the problem with iOS saving before I can leave the redirects.

How can I fix this problem?

Here are screenshots of the conf and conf.d folders. I can’t see those files I was asked to check so please advise how I can either find them to modify or advise what the perceived problem is with my script. Many thanks.

57 ![40|241x144]

14

40

15

It's a script problem, not a server configuration problem.

Looks that your script isn't able to handle https correct -> that's bad. Perhaps too old.

16

I changed the default 302 redirect to a 307 and that now sends the POST data on iOS.

Everything’s working correctly now - both Android and iOS load and save and the dry run for Letsencrypt is working too.

And the site is still getting the C grade :slight_smile:

Thanks guys for all your help.

Sean

17

Weeeeell...

I'm glad it's working. But if you were able to make it work by changing the 302 to a 307, then you're not getting the full security benefit of HTTPS, and you may not be getting any security benefit at all.

Here's how that works:

  1. Your app makes a POST request over HTTP, probably including your users' game save data. This request is not encrypted and can be observed or modified by anyone on the network between the user and your server.

  2. The server responds with a 307 telling the app "try again, but this time use HTTPS". The 307 code (as you've presumably figured out) tells the app to include the POST data when it makes the next request, while the 302 does not.

  3. With luck, the app receives this response and follows the redirect, POSTing the data again, this time to HTTPS. Unfortunately, it's too late as it's already been submitted over HTTP with no encryption in step 1! Worse, an active attacker on the network might modify the 307 response before it gets to the app. So they could send the redirect to their own server instead of yours, forward the second request through, and read the response to the POST request as well as the request itself.

The solution is to modify the app, so that it makes the POST request over HTTPS in the first place. But you might as well leave the 307 redirect in place so that the app continues to function in the meantime :slight_smile:

1 Like
18

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