Letsencrypt SSLCertificateFile: file does not exist or is empty

linuxpl

Verified User
Joined
Mar 13, 2015
Messages
23
Location
Poland
Hi,

I can't solve one error with letsencrypt:

When uses try generate letsencrypt cert, but domain is not delegated (yet) to server, letsencrypt script not report an error and enable ssl in vhost, but cert file is not created. Certificate field in ssl configuration is checked, but empty.

After try reload apache can't refresh configuration and reload is exit with error 1:

maj 10 11:41:01 hostname httpd[12763]: AH00526: Syntax error on line 47 of /usr/local/directadmin/data/users/user/httpd.conf:
maj 10 11:41:01 hostname httpd[12763]: SSLCertificateFile: file '/usr/local/directadmin/data/users/user/domains/domain.com.cert' does not exist or is empty
maj 10 11:41:01 hostname systemd[1]: httpd.service: control process exited, code=exited status=1
maj 10 11:41:01 hostname systemd[1]: Reload failed for The Apache HTTP Server.

How this may be solved?
 
Last edited:
Any ideas?

I've got 10 servers with DA and all works the same:

Domain is not yet delegated to server, and when user try enable Let's Encrypt SSL, then receive message like this:
Subject: LetsEncrypt request successful

Requesting new certificate order...
Processing authorization for domain.com...
Waiting for domain verification...
Trying again...
1..2..3..4..5..
Challenge status: invalid. Challenge error: "type": "http-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:unauthorized", "detail": "Invalid response from http://www.domain.com [123.123.123.123]: "\u003chtml xml:lang="pl-PL" lang="pl-PL"\u003e
\u003chead\u003e
\u003ctitle qtlid="28806"\u003e any text from current site...\u003c/title\u003e"", "status": 403 . Exiting...

This error is right because domain at this moment work on another server, but in SSL settings is checked certificate field - whis is empty.

From this time any changes in vhosts are impossible because httpd can't reload configuration. If httpd try restart then stop work and I must check for this domain "use certificate from server" in ssl settings, and save.

I'm still try find what make it wrong, but I can't.
 
Let's encrypt won't allow to issue a cert if a domain is not delegated to the target server.
 
I know, but why DA make changes in users vhost with ssl configuration when cert is not issued? This is problem.
 
If this is the case and you use default templates you should open a ticket with Directadmin support via tickets and report it as a possible bug.
 
OK, will post this to DA support.

I'm use default templates, and this issue I see on all my servers with Directadmin. I thought that someone already had the same problem.
 
Thanks for the report.

Try the pre-release binaries as it has extra checks.

We had 2 other reports of some Debian boxes that are running "dash" for /bin/sh -> dash, returning exit code 0 when an error occurs with the letsencrypt.sh script.
Swapping it over to /bin/sh -> bash (from dash) seems to solve it. You'll know this is the case if you have a "succeeded" subject line (based on exit 0) but there is clearly error message, then that's related.

The pre-release binaries simply provide an extra check for this case, where an empty or missing cert won't be used, even if DA thinks the letsencrypt.sh returned 0.
The new binaries also log exactly what the error code was for any given le.sh run, so we can better track what's going on (although /bin/dash seems to be the culprit).

Should we get enough reports (which, we may have reached at this point), we may do a check at install time for /bin/sh -> dash, and should /bin/bash exist, we can just swap it over (again, just at install time, we wouldn't touch existing installs)
If anyone is seeing this (success subject, with error message), let us know.

In any case, if you wish to switch over, first confirm you're running dash, confirm you have bash, then switch it over:
Code:
ls -la /bin/sh
ls -la /bin/bash
ln -sf bash /bin/sh
*BEFORE YOU LOGOUT* be sure to test a new login to ensure you have not just bricked your system.
If you cannot login, go back to dash, eg:
Code:
ln -sf dash /bin/sh
If you're not comfortable swapping your shell around, do not proceed, as breaking /bin/sh can essentially brick your system (definitely do not reboot if you have issues)

John

John
 
Thank you - this solved my problem.

Hmm, I'm always change dash to bash after install fresh Debian, but now I see that /bin/sh is link to /bin/dash again. Probably any system update changed this to dash.

After change again to bash letsencrypt script work properly:

Code:
Subject: Error with LetsEncrypt request

Requesting new certificate order...
Processing authorization for domain.com...
Error: [url]http://domain.com/.well-known/acme-challenge/letsencrypt_1563396301[/url] is not reachable. Aborting the script.
dig output for domain.com:
Please make sure /.well-known alias is setup in WWW server.

BTW. Safe and right way to change shell in Debian is command:
Code:
dpkg-reconfigure dash

Thank you!

Arek.

EDIT:
I think, better is stay with dash (more speed and security). Change shebang line to #!/bin/bash in letsencrypt script solved this too. (I know - must remember to change it after le script updates).
 
Last edited:
Just wanted to mention we had the same issue today on an Ubuntu system:

- certificate created succesfully according to the ticket system
- httpd goes down with the same syntax error message as the one above
- fixed (for now) by disabling SSL for this domain, restarting httpd, changing #/bin/sh to #!/bin/bash in letsencrypt.sh and recreating the certificate
 
Ubuntu use dash too.

I think most portable Linux/Unix scripts shoud use #!/usr/bin/env as a shebang - not #!/bin/sh or #!/bin/bash too.

For bash scripts: #!/usr/bin/env bash

For perl: #!/usr/bin/env perl

etc.
 
Back
Top