let's encrypt *.cert.combined.combined not found.

vverloop

Verified User
Joined
Mar 30, 2010
Messages
35
Error when creating let's encrypt certificates. *.cert.combined.combined not found. How to fix this?


Certificate and Key Saved.

Details

Getting challenge for xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for ftp.xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for mail.xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for pop.xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for smtp.xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Getting challenge for www.xxxxx.nl from acme-server...
Waiting for domain verification...
Challenge is valid.
Generating 4096 bit RSA key for xxxxx.nl...
openssl genrsa 4096 > "/usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.key.new"
Generating RSA private key, 4096 bit long modulus
..............++
............................................................++
e is 65537 (0x10001)
Checking Certificate Private key match... Match!
Certificate for xxxxx.nl has been created successfully!


chmod: cannot access ‘/usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined’: No such file or directory Enabled mail SNI config for xxxxx.nl
 
Last edited:
After this Dovecot service can't start / restart. Mail is not working anymore.

[root@vps domains]# systemctl status dovecot -l
● dovecot.service - Dovecot IMAP/POP3 email server
Loaded: loaded (/etc/systemd/system/dovecot.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since di 2017-12-05 18:44:17 CET; 16s ago
Process: 31240 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 2889 ExecStart=/usr/sbin/dovecot -F (code=exited, status=89)
Main PID: 2889 (code=exited, status=89)

dec 05 18:44:17 vps.xxxxx.nl systemd[1]: Started Dovecot IMAP/POP3 email server.
dec 05 18:44:17 vps.xxxxx.nl systemd[1]: Starting Dovecot IMAP/POP3 email server...
dec 05 18:44:17 vps.xxxxx.nl dovecot[2889]: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/95-xxxxx.nl.conf line 2: ssl_cert: Can't open file /usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined: No such file or directory
dec 05 18:44:17 vps.xxxxx.nl systemd[1]: dovecot.service: main process exited, code=exited, status=89/n/a
dec 05 18:44:17 vps.xxxxx.nl systemd[1]: Unit dovecot.service entered failed state.
dec 05 18:44:17 vps.xxxxx.nl systemd[1]: dovecot.service failed.
[root@vps domains]#
 
Last edited:
Content of file 95-xxxxx.nl.conf:

local_name xxxxx.nl {
ssl_cert = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined
ssl_key = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.key
}
local_name mail.xxxxx.nl {
ssl_cert = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined
ssl_key = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.key
}
local_name pop.xxxxx.nl {
ssl_cert = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined
ssl_key = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.key
}
 
Faced the same issue today with Directadmin Version v.1.52.1 (it's possible that the issue happened before upgrading to v.1.52.1, and was found only now).

In order to fix it

0. update directadmin
1. edit /usr/local/directadmin/data/users/$username/domains/$domain.cert.conf
2. remove ending
.combined from the line SSLCertificateFile=
3. run:

Code:
cd /usr/local/directadmin/custombuild
./build update
./build rewrite_confs
./build dovecot_conf


That should fix the issue.


Or:

0. update directadmin
1. in directadmin interface disable cert for the domain -> save
2. enable/install cert for the domain -> save
 
Hi I have the same issue with one of the domains on my server. This problem occurred for the second time now. Only way for me to temporary fix this issue is to modify 95-xxxxx.nl.conf and delete the second .combined:

From:
ssl_cert = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined

To:
ssl_cert = </usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined

But as soon as the letsencrypt certificate is renewed this file is changed back to his original state.

I tried both fixes of zEitEr but both suggestions didn't fix the issue for me. Any help is appreciated!
 
Can you confirm the state of the domain's config? It might have the old setting in there, eg:
Code:
cd /usr/local/directadmin/data/users/xxx/domains
ls -la xxxx.nl.conf
cat xxxx.nl.conf
just to confirm it's set.

I have added more checks/fixes in the pre-release DA binaries, so ensure you're running them to confirm..
and when something is re-saved, DA should be removing the duplicate .combined.combined.

John
 
Hi John, here you have a screenshot of the requested output. Thanks for your help.

Screenshot.jpg
 
Last week I've update my DA version with the pre-release like explained on https://help.directadmin.com/item.php?id=408

Today I've created a new domain and wanted to attach a SSL certifcate to this particular new domain. The certificate is generated successfully but got the same error again: "(chmod: cannot access ‘/usr/local/directadmin/data/users/xxx/domains/xxxxx.nl.cert.combined.combined’: No such file or directory Enabled mail SNI config for xxxxx.nl )".

Resulting in a Dovecot error and the mailserver ain't available anymore. I can only temporary fix the issue by modifying the 95-xxxxx.nl.conf and delete the second '.combined:'. This file needs to be changed every time after a certificate is updated. Because Letsencrypt certificates are updated automatically I can't monitor when the dovecot server will be down. So this manual change can't be a fix for the long term...

Some extra help would be so nice. Please help!
 
This bug is still present in latest version. Upon resaving any SSL keys it happens. Seems to be related to decrepitated Dovecot SNI. Disabled SNI all together (also the new mail SNI) yet still DA is generating these damn wrong combined entries for domains. Don't get it as SNI is disabled ...

This is a pain in the @$$ bug for a while now ...
 
I can confirm the problem still exist. I have Directadmin version 1.53.0.

I tried both fixes of zEitEr but both suggestions didn't fix the issue for me.
 
A friend of my has installed the following mail sni script in the past: http://forum.directadmin.com/showthread.php?t=53967

What i read at that post, is that the script is deprecated. Starting with DirectAdmin version 1.515 this script is built into DirectAdmin itself.

So what i have to do is uninstalling that script. Maybe that's the solution.
 
My problem is solved now. This is what i did:

- In /usr/local/directadmin/conf/directadmin.conf add mail_sni=1 (assuming you want to use this feature) and remove dovecot_sni= and exim_sni= if these are present.
- In /etc/exim.variables.conf.custom remove the tls_certificate= and tls_privatekey= variables.
- In /usr/local/directadmin/scripts/custom/ remove the following files (or the changes made in them): domain_change_post.sh, domain_destroy_post.sh, domain_modify_post.sh, letsencrypt_post.sh, ssl_save_post.sh, user_destroy_pre.sh, mail_sni.sh
- Remove all 95-<domainname>.conf files from /etc/dovecot/conf.d/ (rm -f /etc/dovecot/conf.d/95-*.conf)
- Rebuild exim_conf (/usr/local/directadmin/custombuild/build exim_conf)
- Rebuild dovecot_conf (/usr/local/directadmin/custombuild/build dovecot_conf)
- Rewrite all exim and dovecot sni configs (echo "action=rewrite&value=mail_sni" >> /usr/local/directadmin/data/task.queue)
 
Im followed above because I had the same problem.

However after that all my save certificates are now shown as self-signed.

The message from DA after saving key+certificate ans/or CA certificate is:

Could not find 'X509v3 Subject Alternative Name:' in output

How will I be able to update my certificate(s) so they are trusted again?

By the way this is not about LEt's Encrypt certificates but COMODO certificates


 
Back
Top