DirectAdmin 1.50.0 has been released

DirectAdmin Support said:
We also have to keep in mind that there is a request limit, so if you add a pile of subdomains, you might be over the limit before the first run is even done.
Click to expand...

Are you sure that the limit applies to subdomains too? Because when I was testing LetsEncrypt standalone, I could just tack a bunch of subdomains on a single request, and it worked fine. When I run the DA letsencrypt.sh script, the output suggests that different requests are done for each subdomain. Maybe there's the culprit?
 
zmippie said:
Are you sure that the limit applies to subdomains too? Because when I was testing LetsEncrypt standalone, I could just tack a bunch of subdomains on a single request, and it worked fine. When I run the DA letsencrypt.sh script, the output suggests that different requests are done for each subdomain. Maybe there's the culprit?
Click to expand...

https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769

Names/Certificate is the limit on how many domain names you can include in a single certificate. This is currently limited to 100 names, or websites, per certificate issued.
Click to expand...

1 domain/subdomain - 2 names, because of www prefix and non-www name. That means the limit in DA would be 1 domain + 49 subdomains (if there are no domain pointers included in certificate).
 
sfxdana said:
I created an custom letsencrypt script so that everyone of my subdomains is added to the request. This way I don't have to add every subdomain to Directadmin as an new domain. Which also mess up the DNS config.

Also added my old update-mail-certificates.sh script to add SNI support for Dovecot and Exim. See script for Dovecot and Exim config changes which are needed. Need to add this functionality to the letsencrypt script.

https://github.com/ictabc/directadmin

Still a work in progress, and haven't programmed in a while. So could need a clean-up I guess. But first get it working then clean it up.

Only testet on Centos 6. So you may need to tweak for other OS.

Axel Boersma.
Click to expand...

It would be so amazing if you would be able to request and install SSL for mail. I still have no idea how I could install certs for every mail. domain. Now I always have to ask people to select 'SSL/TLS (don't check cert)' in their mail apps.

@smtalk

I still can't get certs for my WordPress sites. This is my WordPress-specific config:

location ~ /\. {
deny all;
}

location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}

location = /favicon.ico {
log_not_found off; access_log off;
}

location = /robots.txt {
log_not_found off; access_log off;
}

# Cache static files for as long as possible
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
expires max; log_not_found off; access_log off;
}

location / {
try_files $uri $uri/ /index.php?$args;
}

rewrite /wp-admin$ $scheme://$host$uri/ permanent;
Click to expand...

I tried to disable the first one (with a #) but, then I would still get a 403. I was just able to request a cert by removing all the WordPress-specific config, but that's not usable because of the auto-renew. Any idea what exactly is breaking things and how I could create a way to both let WordPress work and the Let's Encrypt auto-renew?
 
Last edited:
It must be:
Code: 
location ~ /\. {
deny all;
}

Please make sure you restart nginx after taking this code out, also, please check if you don't have any other custom configs.
 
smtalk said:
It must be:
Code: 
location ~ /\. {
deny all;
}
Click to expand...

Euhm, what's different here? Looks the same as I have.

I think the restart you mention did the trick, I tried disabling that line again and now it works. Strange, because I tought I tried that before already. However: how would I make this work with the automated renewal now?. How important is that line? Does removing it forever really mean a security risk?
 
Last edited:
ZipperZapper said:
Euhm, what's different here? Looks the same as I have.

I think the restart you mention did the trick, I tried disabling that line again and now it works. Strange, because I tought I tried that before already. However: how would I make this work with the automated renewal now?. How important is that line? Does removing it forever really mean a security risk?
Click to expand...

It's not different, I'm just telling which part of code is the cause :) It's used to disable direct access to .htaccess/.htpasswd files. However, DirectAdmin default configs already has protection for them by default (in webapps.conf, webapps.ssl.conf):
Code: 
location ~ /(\.htaccess|\.htpasswd|\.user\.ini) {
	deny all;
}
 
When it's time to renew - 5 days before the actual expiration, will DA send an e-mail to the account owner (or even the reseller / admin?) if it fails to renew for whatever reason? That way we know a few days in advance and can still resolve the issue manually before the certificate expires due to failing renewals.
 
Currently, I've only managed to get a working certificate for the hostname of my VPS.

Trying to get a certificate for seperate domains on the server all fail with the "Challenge is invalid. Invalid response... 404" -error, for sites with a Wordpress-installation on it, or,
"Challenge is valid. Invalid response... 404" -error for sites without WP installed.

Running just Apache, no NGinx.

Also, I'm thinking the instructions aren't very clear here;
http://www.directadmin.com/features.php?id=1828

Code: 
ACTION REQUIRED
You must have the .well-known Alias pointing to /var/www/html/.well-known, so update your CustomBuild configs:
cd /usr/local/directadmin/custombuild
./build update
./build rewrite_confs


The way this reads, is; "You need to have an alias created, SO update custombuild configs;"
This doesn't work as no additional alias is being created in httpd-alias.
(I'm running CB 1.2)

Does one have to create an alias yourself manually?
 
BBM said:
Does one have to create an alias yourself manually?
Click to expand...

To answer my own question: YES

After adding...
Code: 
Alias /.well-known /var/www/html/.well-known
(Like Zeiter casually mentioned on the 1st page of this topic)
...to /etc/httpd/conf/extra/httpd-alias.conf

and a
Code: 
service httpd restart
... everything worked as intended.
 
BBM said:
To answer my own question: YES

After adding...
Code: 
Alias /.well-known /var/www/html/.well-known
(Like Zeiter casually mentioned on the 1st page of this topic)
...to /etc/httpd/conf/extra/httpd-alias.conf

and a
Code: 
service httpd restart
... everything worked as intended.
Click to expand...

So I had the same problem. If that's what needs to happen, it isn't very clear. I was under the impression that running those commands would do that for me. But that isn't the case? Or is it not working correctly?
 
Hi,

Me too was looking for the .well-known in httpd-alias.conf
But as an IT-er, i wanted to have my configs up-to-date before enabling an option in directadmin.

The correct way is to set the letsencrypt option in directadmin.conf and then update your config files through custombuild.
Since custombuild won't create the alias if the option is not enabled in the directadmin.conf file.

regards,
Stijn
 
It seems with

Code: 
./build rewrite_confs

an alias:

Code: 
Alias /.well-known /var/www/html/.well-known

gets added into /etc/httpd/conf/extra/httpd-alias.conf twice, the two very top lines.

Kindly check it and fix.
 
zEitEr said:
It seems with

Code: 
./build rewrite_confs

an alias:

Code: 
Alias /.well-known /var/www/html/.well-known

gets added into /etc/httpd/conf/extra/httpd-alias.conf twice, the two very top lines.

Kindly check it and fix.
Click to expand...

It's been fixed in rev. 1503 :) Please give it a try.
 
Somehow if I try to rewrite my configs it changes the port from apache to 80. Instead of 8080. (I'm using a nginx/apache setup.)

Also when validating it crashes with 403. Every domainname. Even domains that are empty. I've tryed option 1 and 2.

HTML: 
66.133.109.36 - - [02/Mar/2016:17:09:49 +0100] "GET /.well-known/acme-challenge/2ollFEWCvzpDcBcNYNntdT3WCcU4vkY4sobmi3R8Lxo HTTP/1.0" 403 553 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

HTML: 
webserver=nginx_apache
apache_ver=2.4

HTML: 
[root@server1 custombuild]# ./build rewrite_confs
Checking to ensure /etc/httpd/conf/ssl.crt/server.ca is set.
Using XX.XX.XX.XX for your server IP
Found /usr/local/directadmin/custombuild/mod_aclr2-1.0.0.tar.gz
Extracting /usr/local/directadmin/custombuild/mod_aclr2-1.0.0.tar.gz...
Installing mod_aclr2-1.0.0...
/var/www/build/libtool --silent --mode=compile gcc -std=gnu99 -prefer-pic -I/usr/local/include  -DLINUX -D_REENTRANT -D_GNU_SOURCE -pthread -I/usr/include/apache  -I/usr/include/apache   -I/usr/include/apache   -c -o mod_aclr2.lo mod_aclr2.c && touch mod_aclr2.slo
/var/www/build/libtool --silent --mode=link gcc -std=gnu99 -L/usr/local/lib   -o mod_aclr2.la  -rpath /usr/lib/apache -module -avoid-version    mod_aclr2.lo
/var/www/build/instdso.sh SH_LIBTOOL='/var/www/build/libtool' mod_aclr2.la /usr/lib/apache
/var/www/build/libtool --mode=install install mod_aclr2.la /usr/lib/apache/
libtool: install: install .libs/mod_aclr2.so /usr/lib/apache/mod_aclr2.so
libtool: install: install .libs/mod_aclr2.lai /usr/lib/apache/mod_aclr2.la
libtool: install: install .libs/mod_aclr2.a /usr/lib/apache/mod_aclr2.a
libtool: install: chmod 644 /usr/lib/apache/mod_aclr2.a
libtool: install: ranlib /usr/lib/apache/mod_aclr2.a
libtool: finish: PATH="/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/sbin" ldconfig -n /usr/lib/apache
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/lib/apache

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
chmod 755 /usr/lib/apache/mod_aclr2.so
[activating module `aclr' in /etc/httpd/conf/httpd.conf]
mod_aclr2 has been installed successfully.
Restarting apache.
Stopping httpd:                                            [  OK  ]
Starting httpd: AH00112:
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs

Checking to ensure /etc/httpd/conf/ssl.crt/server.ca is set.
Using X.XX.XX.XX for your server IP
Using X.XX.XX.XX for your server IP
Restarting nginx.
 
Last edited:
.well-known missing

In /var/www/html i have no ".well-known" directory. Should it be made by DA with ./build rewrite_confs?
How can i debug this? Alias to in /var/www/html/.well-known in /etc/httpd/conf/extra/httpd-alias.conf exist.
 
".well-known" directory in the public_html

avanderree said:
In /var/www/html i have no ".well-known" directory. Should it be made by DA with ./build rewrite_confs?
How can i debug this? Alias to in /var/www/html/.well-known in /etc/httpd/conf/extra/httpd-alias.conf exist.
Click to expand...

Now i've found a ".well-known" directory in the public_html dir of an account. First 1 had configured letsencrypt=2, but now it is letsencrypt=1. Can i make that change or is the problem that it's first configured for letsencrypt=2?
 
smtalk said:
Please open a ticket for that in tickets.directadmin.com. It'd be great if you could include login credentials to the server too, that way the issue could be found and fixed faster.
Click to expand...

Thanks for the advise, I have just created a ticket.
 
wattie said:
letsencrypt fails with me with:



p.s. both =1 and =2 options
Click to expand...


I found solution

your "curl" have problem, you can try

#curl https://helloworld.letsencrypt.org/

curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

something like that show, that mean certificate broken on curl

step1: wget https://curl.haxx.se/ca/cacert.pem /usr/ssl/cert.pem
step2: hardcode /usr/local/directadmin/scripts/letsencrypt.sh

find "curl" all file
sample
NONCE="`${CURL} --silent -I ${API}/directory | grep '^Replay-Nonce:' | cut -d' ' -f2 | tr -d '\n\r'`"
Click to expand...

and add --cacert /usr/ssl/cert.pem

NONCE="`${CURL} --cacert /usr/ssl/cert.pem --silent -I ${API}/directory | grep '^Replay-Nonce:' | cut -d' ' -f2 | tr -d '\n\r'`"
Click to expand...

is work! for me
FreeBSD 8.0 64 bit
 
smtalk said:
Please open a ticket for that in tickets.directadmin.com. It'd be great if you could include login credentials to the server too, that way the issue could be found and fixed faster.
Click to expand...

With the help of both Martynas an John I was able to resolve the issue.
The new script available in the pre-release binaries works for FreeBSD 9.3 as well :).
 
You must log in or register to reply here.
Back
Top