SSL Certificate Not generating

Help! (Home for newbies)
1

Debian 10 (VPS at OVH)
Virtualmin 6.08
Webmin 1.941
Usermin 1.791

Reinstalled new O/S to my VPS. Debian 10.
Installed Webmin with the LAMP stack.
Generated new user as Server Admin User.
Installed main virtual server with ssl website option (Xorex.rocks). Could not generate SSL certificate.
installed additional virtual servers ns1.xorex.rocks and ns2.xorex.rocks with identical options to main server xorex.rocks.
Redirect set to always redirect http calls to https.
BIND enabled and name servers appear to be working (although I have not been able to cluster them but that will be a separate topic).
Tried to run Let’s Encrypt but got the same message:

I ran this command:

Virtualmin:Server Configuration:SSL Certificate:Let’s Encrypt:Request certificate for: Domain names listed here: xorex.rocks

It produced this output:
Requesting a certificate for xorex.rocks from Let’s Encrypt …
… request failed : Web-based validation failed : Failed to request certificate :
Traceback (most recent call last):
File “/usr/share/webmin/webmin/acme_tiny.py”, line 198, in
main(sys.argv[1:])
File “/usr/share/webmin/webmin/acme_tiny.py”, line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
File “/usr/share/webmin/webmin/acme_tiny.py”, line 143, in get_crt
raise ValueError(“Wrote file to {0}, but couldn’t download {1}: {2}”.format(wellknown_path, wellknown_url, e))
ValueError: Wrote file to /home/xorex.rocks/public_html/.well-known/acme-challenge/7chSbLPN08aQA_laf1bLbXcriW34paoJhWxrBccXn6Q, but couldn’t download http://xorex.rocks/.well-known/acme-challenge/7chSbLPN08aQA_laf1bLbXcriW34paoJhWxrBccXn6Q:Error:
Url: http://xorex.rocks/.well-known/acme-challenge/7chSbLPN08aQA_laf1bLbXcriW34paoJhWxrBccXn6Q
Data: None
Response Code: 404
Response:

404 Not Found

Not Found

The requested URL was not found on this server.

DNS-based validation failed : Failed to request certificate :
usage: acme_tiny.py [-h] --account-key ACCOUNT_KEY --csr CSR --acme-dir
ACME_DIR [–quiet] [–disable-check]
[–directory-url DIRECTORY_URL] [–ca CA]
[–contact [CONTACT [CONTACT …]]]
acme_tiny.py: error: argument --acme-dir is required

Took the issue to Let’s Encrypt and they tell me there is an issue with the script:

**> acme_tiny.py: error: argument --acme-dir is required

something you have to fix. May be a too old version of that client or of your VirtualMin.**

There is no .well_known directory written to public_html. This could either be because the script is making http calls or a permissions issue?

Can anyone help me resolve this please?

2

I checked and the key file has been written and the URL it says it cannot download from:

http://xorex.rocks/.well-known/acme-challenge/7chSbLPN08aQA_laf1bLbXcriW34paoJhWxrBccXn6Q

opens the web browser to show the two part key so I cannot understand why it cannot download the information it requires.

3

I’d recommend manually creating that folder (.well-known) in the root directory of that domain. It’s what resolved it for me on CentOS 8.

4

Thanks miklovestek. Tried that for just .well-known and for .well-known/acme-challenge but it did not resolve the problem.

Can anyone (esp. from the Virtualmin team) offer any guidance please?

5

In a web browser, can you visit that directory once it’s been created?

6

Try to exclude the well-known directory from your redirects:
Add this to the htaccess (should be correct if I recall it correctly):

RewriteCond %{REQUEST_URI} !^\.well-known/(.*)$

Make sure that thr RewriteEngine itself is enabled (which it should be in your case).

7

Yes miklovestech, and it opens the file to be read. I can read it whether I use http or https.

8

Thanks for the suggestion Carson.

I am a bit confused because under virtualmin redirects I have a /dav redirecting to the home directory and / redirecting to https://xorex.rocks/$1 which I assume should redirect all http calls to https. However,

http://xorex.rocks/.well-known/acme-challenge/7chSbLPN08aQA_laf1bLbXcriW34paoJhWxrBccXn6Q

takes me to a non secure version of the file. If I then add the s to the URL, it takes me to a secure version so it appears the redirect is only working at the domain level (http://xorex.rocks redirects automatically to https://xorex.rocks). [Just seen that the subdirectory redirect option is unticked so should I leave that as is for the let’s Encrypt activity or redirect all sub-directories as well?]

Also, there is no .htaccess file in the root (public_html) directory for the web server so how is virtualmin managing redirects if this file does not exist?

Should I build a .htaccess file from scratch and enter your suggestion or will that upset the virtualmin settings? Or can I add a redirect under virtualmin to achieve what you are suggesting? If so how, as the dialogue box is not entirely clear. To achieve your .htaccess entry via the virtualmin dialogue what do I enter as the source URL? Do I redirect to a website or a directory and which one? Should I include subpaths and should it be for both non ssl and ssl websites?

9

If the plugin uses webroot, then its sometimes necessary to use such a command because webroot doesnt like redirects and cant handle that properly.
Thats precisely the reason why mods and staffs from LE tell users to do that.
Edit:
Either put a .htaccess file directly into the public_html and enable RedirectEngine too or set the redirect exclude into the vhost file.

10

OK I prefer to use the virtualmin option but see my previous response as I am unsure how to reproduce your suggestion through that dialogue box.

11

You can also try to add this to the vhost file:

RewriteEngine on RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge(/[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-]*)?$ RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [last,redirect=301]

You can do that via webmin btw.
Simply go to webmin -> server -> apache-webserver -> select the host you want it for and select the port 80 vhost (it wouldnt hurt to add the lines to the corresponding 443 vhost too, even though it shouldnt be necessary). If you selected the desired vhost go to change directives and add that lines at the very end. You should just make sure that only one “RedirectEngine On” is in that file.

The error message you get is a classic one for the webroot thing. It can set the file but since webroot wants to use http and not https, it cant access the file.

12

OK, instead of the .htaccess file, the apache configuration files are handling the redirects (I am slowly learning so please be patient with me!). The two main extracts are below (which I assume Vmin enters for me). The second one appears to be a duplicate of the first but with some ssl entries added. I cannot find entries that allow a redirect for .well-known. I will add your suggestion but there are several redirect engine on and off commands. Should I leave the first and last and remove the rest? Should I remove the duplicated section of the two entries above to tidy it up?

Thanks for your patience.

[Hmm, the editor does not reproduce the formatting so it has mangled the entries together. Can you make sense of them or should I try to do them again for you?]. [OK, sorted. it was the tags around the directory statement that was messing the formatting up. I have removed them to reset it so it is readable.]

Should I put your suggested entry under a directory statement?

Directory

RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.xorex.rocks
RewriteRule ^(.) https://xorex.rocks:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.xorex.rocks
RewriteRule ^(.) https://xorex.rocks:10000/ [R]
RemoveHandler .php
RemoveHandler .php7.3
FcgidMaxRequestLen 1073741824
RedirectMatch ^/(?!.well-known)(.*)$ https://xorex.rocks/$1

Directory
RewriteEngine on
RewriteCond %{HTTP_HOST} =webmail.xorex.rocks
RewriteRule ^(.) https://xorex.rocks:20000/ [R]
RewriteCond %{HTTP_HOST} =admin.xorex.rocks
RewriteRule ^(.) https://xorex.rocks:10000/ [R]
RemoveHandler .php
RemoveHandler .php7.3
FcgidMaxRequestLen 1073741824
SSLEngine on
SSLCertificateFile /home/xorex/ssl.cert
SSLCertificateKeyFile /home/xorex/ssl.key
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

13

Carson, to be clear, there are three lines I need to enter and do I need to change the /[ABCD etc. statement to the certificate file entry or leave it as is? i.e., is it there as a wild card to indicate it should look for something that contains capital and lower case letters and numbers?

RewriteEngine on
RewriteCond %{REQUEST_URI} etc.
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [last,redirect=301]`

14

The “RewriteEngine On” from the already given entries are fine. Just put the rest:

RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge(/[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-]*)?$ RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [last,redirect=301]
into it.
I noticed that one of the vhosts (or is that fromone?) got an exclude already.
As a test, put a “#” infront of this line:

RedirectMatch ^/(?!.well-known)(.*)$ https://xorex.rocks/$1
15

Hi Carson,

I have been working all day and just got back to this. I commented out the line you suggested and inserted this to the sites-available/xorex.rocks cons file.

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge(/[ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-])?$
RewriteRule ^/(.) https://%{HTTP_HOST}/$1 [last,redirect=301]
RewriteEngine off

No difference I am afraid, the same message comes up. Fed up.

16

You shouldnt place the RewriteEngine off in a file if you use the RewriteEngine. Remove that, restart apache2 and retry.
If that doesnt work, then you should disable the automated redirect to SSL as a test.

17

Hi Carson, thanks for your continuing efforts of support. On top of everything else we are now having ongoing internet issues so not easy to keep a conversation going.

There are several rewrite engine on and rewrite engine off statements in the sites accessible.conf files for this server. Would it help if I posted the entire file (circa 200 lines)?

I tried with another server I set up and it almost writes the certificate but then tells me it cannot write to a temp file in the public_html folder. I was also having problems with this user not getting the proper access to webmin even though it is my main admin so decided to delete the server and this seems to have shot myself in the foot because as soon as I did that I lost access to my server and my webmin dashboard and it still has not come back whether I use the IP or reverse IP.

Reinstalled a default server via cli but still cannot access. I am sure Wmin/Vmin are great if you can get them to work but I have had nothing but problems with it thus far. I think I will have to start all over again and rebuild my server at OVH. All I want is a stable system to migrate all my servers to (from other hosts) but it is causing me nothing but frustration.

I will wait another 24 hours to see if it a DNS issue and then reset the server if I get no joy.

I will post back here to let you know how I get on.

18

Hello OVH gives a lot of problems with management panels, it has limited ports that do not let you use, so you can find problems.
I recommend you to change your company.
Then if your dns are not well resolved I think you will not be able to generate the ssl certificate.
I’ve had several problems with ssl and it’s always been because of dns issues, so you have to take it into account.
Greetings
Screenshot_1

19

@GeoffatMM Deleting a virutal host (website) shouldnt remove the admin login for virtualmin.
Can you still access the server via ssh directly?

20

Hi Carson, yes I can ssh in. That is how I rebuilt the xorex.rocks through cli. It is strange (and I suspect it is DNS issues as byte canaries says as now I can resolve to xorex.rocks (in a private window to avoid the cache) but not to xorex.rocks:10000 or :20000 yet both apache2 and webmin are running on the server. I can ssh into the server with @xorex.rocks but that may be because it is in my hosts file on the machine. I thought using the IP address would bypass the DNS and give access but it is not.

I will reboot at OVH and see what happens.