HTTP Verification - Apache Not Service Extensionless Files


#1

Hi everyone,
I am trying to generate a SSL Certificate for our Dedicated University Server (Debian 8.5 and Plsk 12.5) using the FREE SSL Certificate Wizard provided by zerossl.com, at the stage of domain ownership using HTTP verification, it asks you to upload files to

webroot/.well-known/acme-challenge/

but with no file extensions such as .txt or .html, when I click on the URL I get 403 (Forbidden; You do not have permission to access this document.) but if I add files extension it works. I have permission 0755 on the folder and the files as well. Any idea how I can solve this issue please?


#2

Please fill out the fields below so we can help you better.

My operating system is (include version):

My web server is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):


#3

Thank you

  1. My operating system is (include version): Debian 8.5

  2. My web server is (include version): Dedicated Websever

  3. My hosting provider, if applicable, is: By https://www.hetzner.de/en/

  4. I can login to a root shell on my machine (yes or no, or I don’t know): Yes I can access my server viw PUTTY

  5. I’m using a control panel to manage my site (no, or provide the name and version of the control panel): Yes I have PLESK 12.5 to manage the server most of the time


#4

hi @dorshani

this question My web server is (include version): is about what type of web server is it apache/nginx/iis

Some web servers do not know how to serve extensionless files

Andrei


#5

Hi

Sorry, the webserver is Apache Web Server but I am not sure what version. It is the latest stable one. Also the Debian is version 8.6

DRR


#6

I am an ignorant user, but it seems to me it’s easier to install automatically w a script than manually using zerossl. IIUC, you are the sysadmin, so you have root, can use one of the Certbot or acme.sh, or autossl scripts.

The problem I had was I didn’t know what my hosting provider considered the webroot. Ask your hosting provider about where/how you can access these
files.
Is there a LE autoinstall plugin for Plesk?? Probably easiest if so.

I used acme.sh, recommend it.

?? (This may be a dumb question.) When you tried to access the URL webroot/.well-known/acme-challenge/ did you try to access a file or a directory?

If you run PHP, there’s a PHPinfo.php file:
Contents:

<?php phpinfo(); ?>

which will give you lots of info what you’re running.
Good luck!


#7

hi @dorshani

Have a look at this article on Apache behavior when trying to serve extensions it doesn’t know about

I would recommend that you use the application/text mime rather than the PHP one.

The other thing the people doe is a test file such as test (with no extension) to their directory and share the link so others can throubleshoot

Andrei


#8

Hi, Thank you for the tips. I am not a system admin and I do not want to mess up the server. I did put other files on the folder and I could access all those files but the one without extension.

The command line apachectl -V gives
Server version: Apache/2.4.10 (Debian)

You mentioned (acme.sh), do you have the instruction for installation somewhere please?


#9

Please check

http://www.koyauniversity.org/.well-known/acme-challenge/README.txt

and in the same folder

http://www.koyauniversity.org/.well-known/acme-challenge/test


#10

Hi,

I have solved the issue by adding a .htaccess to the same folder with content below, I hope this will work

RewriteEngine on

#remove the need for .php extension
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.*)$ $1.php


#11

For less technical folks there is a somewhat simpler way that will
satisfy your needs to get your site on SSL:

  1. Sign up at Cloudflare for their free service. This is a ‘Content
    Distribution Network’ (CDN) that stores your website in their
    servers around the world to speed it up, and _also _puts it on
    SSL. (Other CDNs probably do SSL too, but Cloudflare has
    terrific support.)
    1. That should take care of 95% of your needs to present https://
      to the world.
    2. To get the last 5%, create an “Origin SSL” at Cloudflare, and
    3. Install your “Origin SSL” certificate on your web hosting
      service using your panel access (Plesk or cPanel,etc.) or
      instructions on CF.
    4. You could also use a “self-signed SSL certificate” w
      Cloudflare instead of Cloudflare’s “Origin SSL” certificate,
      but why complicate your life?


DONE!!

For acme.sh–and Let’s Encrypt certificate:

  1. You find acme.sh at https://github.com/Neilpang/acme.sh
  2. You will need “SSH access” to the computer running your website on
    digitalocean.
    1. Ask your hosting support for SSH access
  3. find and download PuTTY; read the FAQ to use it.
  4. the ‘webroot’ you want is where you can put a file "test.txt and
    read it by URL: www.yourWebsite.edu/test.txt
  5. SSH into your host server, run acme.sh with the --staging switch
    for testing, and the -w switch set to the webroot directory
    in(4.) You do not need root.
  6. Once that works, run acme.sh with the --force switch (&
    without–staging)
  7. Take the certificate generated and install using Plesk/cPanel etc.
    on your host.

Good luck!

Peter


#12

One thing to note here is that this (very effective) approach is trusting an additional company with access to your communications and user data. While providing HTTPS for your site, any content delivery network, like Cloudflare, will have access to your unencrypted data.


#13

yes it does now work


#14

Thank you everyone, it shows that there is an extension for Plesk and I have now added that to our server. It went well for all domains and subdomains but the our MAIN DOMAIN. I click to create, and it stop without any warning. I am working on it

https://ext.plesk.com/packages/f6847e61-33a7-4104-8dc9-d26a0183a8dd-letsencrypt


#15

be very careful recommending services - for less technical folks…etc.

Unfortunately those folks are usually the ones that are up in arms first when something goes wrong.

SSL and TLS is a skillset. A good skillset that needs investment like anything else (fixing cars, carpentry etc). Having a skillset also allows you to evaluate services more carefully.

@schoen points out there is a danger of using other providers for SSL encryption and private keys

This is not a theoretical danger it actually happend :smiley:

saying that I exclusively use CloudFlare for my DNS servers. They have things like DNSSEC down pat and really fast propagation times (e.g. adding a record and then being able to use it 5 minutes later) but find the way they do their SSL not to my liking.

Andrei


#16

Right, and they fixed 90% of it in FORTY-SEVEN MINUTES!

What undiscovered vulnerabilities exist in LE?

The bottom line is that for most people using shared hosting LE is too
hard to implement. I’m sorry if you don’t want to hear that, but
consider the differences in difficulty of implementation. LE is
hugely virtuous, with a noble motive- getting the whole web on https.

Cloudflare is more time-effective for the vast majority of people with
small websites on shared hosting. It has far better useability. It
just works.

LE and CLoudflare are intended for different audiences. Those who are
able to use LE easily will find it’s their best solution. But LE is
only useful for very technically able users. I -finally!-got it to
work, but it took me three weeks. Cloudflare was up and running in 15
minutes.
UI is important.

And derogatory comments about less technically able users are what Tom
Peters calls, “Contempt for the Customer.”


"The greatest period of impact was from February 13 and February 18
with around 1 in every 3,300,000 HTTP requests through Cloudflare
potentially resulting in memory leakage (that’s about 0.00003% of
requests).

We are grateful that it was found by one of the world’s top security
research teams and reported to us.

This blog post is rather long but, as is our tradition, we prefer to
be open and technically detailed about problems that occur with our
service."


#17

Glad that worked! Congratulations on securing your sites!!


#18

Well, if they have sensible shared hosting, implementing LE on a given site can be as simple as pushing a button (or even easier; some default to an LE cert as soon as the domain is provisioned). But if the host is stuck in the GoDaddy/HostGator model of imposing nickel and dime charges for everything a customer might want, yes, it’s going to be harder to implement. Ultimately, to work the way it’s intended to work, LE support needs to be implemented by the server admin.


#19

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