LetsEncrypt (wrong certificate will be served)

mekmek

Verified User
Joined
Mar 12, 2021
Messages
14
Location
Netherlands
Hi @all

Good morning.

I have some issue with letsencrypt certificate on one of my subdomains.domain.com . It worked smoothly, but for some reason letencrypt auto renew has not worked. For other domains, I have no issues at all at this moment (auto renew was also enabled). So I renewed the letsencrypt certificate manually several times and this works for almost all the subdomains.domain.com instead of the mail.subdomain.com . For this domain, the default https ssl certicate will be served with a valid time of: Sat, 10 Oct 2048 07:47:07 GMT .

When I navigate to my: https://mail.domain.com:2222 address, the correct valid certificate will be served. So it looks ik my opinion a configuration
thing, related to letsencrypt in my apache configuration. The certificate is vallid now till: Sun, 12 Sep 2021 19:03:10 GMT at this moment.

I did some research on the forum here, and the Apache configuration, should be here:
/usr/local/directadmin/data/users/admin/httpd.conf (in my case)

When I open this file, it looks like the certificate is correctly configured:

<VirtualHost 192.168.137.254:443 >
SSLEngine on
SSLCertificateFile /usr/local/directadmin/data/users/admin/domains/domain.com.cert.combined
SSLCertificateKeyFile /usr/local/directadmin/data/users/admin/domains/domain.com.key
SSLCACertificateFile /usr/local/directadmin/data/users/admin/domains/domain.com.cacert
ServerName mail.domain.com
ServerAlias webmail.domain.com smtp.domain.com imap.domain.com
ServerAdmin [email protected]
DocumentRoot /home/admin/domains/domain.com/private_html/mail
ScriptAlias /cgi-bin/ /home/admin/domains/domain.com/private_html/mail/cgi-bin/
UseCanonicalName OFF
<IfModule !mod_ruid2.c>
SuexecUserGroup admin admin
</IfModule>
CustomLog /var/log/httpd/domains/domain.com.mail.bytes bytes
CustomLog /var/log/httpd/domains/domain.com.mail.log combined
ErrorLog /var/log/httpd/domains/domain.com.mail.error.log
<Directory /home/admin/domains/domain.com/private_html/mail>
<FilesMatch "\.(inc|php|phtml|phps|php73)$">
<If "-f %{REQUEST_FILENAME}">
#ProxyErrorOverride on
AddHandler "proxy:unix:/usr/local/php73/sockets/admin.sock|fcgi://localhost" .inc .php .phtml .php73
</If>
</FilesMatch>

when I check this, the files are also in the directory: /usr/local/directadmin/data/users/admin/domains


-rw-r----- 1 diradmin mail 5509 Jun 14 22:03 domain.com.cert.combined
-rw-r----- 1 diradmin access 288 Jun 14 22:03 domain.com.key
-rw-r----- 1 diradmin mail 3751 Jun 14 22:03 domain.com.cacert

My host-system is:


Compiled onDebian 10.0 64-bit
Compile DateJun 17 2021, 12:58:40
Server Version1.62.2

This issue was also in the earlier release, before I did a recent upgrade.

Someone a good tip to solve this problem, will be appreciated.

Many thanks!

Have a good day,

Met vriendelijke groet,
Kind regards,
Mek.
 
Hi Realcryptonight,

Good morning.

Thanks for the reply. My dns has been hosted on other dns-servers.

Grtz,
Mek.
Do you maybe know how many certificates are requested by the server? (As this might be a Let's Encrypt limit.)
Do you have any messages in the messages system that say Let's Encrypt fail? (They maybe give some more info.)
If all of the above does not help, did you try to reissue and restart the auto renewal process?
 
Hi Realcryptonight,

Selected entries count: 8
Maximum requests per week: 200

For the webmail.domain.com , smtp.domain.com & webmail.domain.com, there are no problems. When I check the details of the LetsEncrypt certificate the mail.domain.com is also shown, but when navigate to this throuh https, the default ssl certificate will se served for some reason.

I did several renew attempts (save) under: SSL Certificates > Let's Encrypt Certificate Entries >

mail.domain.com
smtp.domain.com
webmail.domain.com
imap.domain.com

> Save

There is no specific re-issue button here, but the current (valid) certificate will be renewed, because the expire date will go further
since the last renew.

I will look further in the logging, maybe here will something appears.

Grtz,
Mek.
 
Hi Realcryptonight,

Selected entries count: 8
Maximum requests per week: 200

For the webmail.domain.com , smtp.domain.com & webmail.domain.com, there are no problems. When I check the details of the LetsEncrypt certificate the mail.domain.com is also shown, but when navigate to this throuh https, the default ssl certificate will se served for some reason.

I did several renew attempts (save) under: SSL Certificates > Let's Encrypt Certificate Entries >

mail.domain.com
smtp.domain.com
webmail.domain.com
imap.domain.com

> Save

There is no specific re-issue button here, but the current (valid) certificate will be renewed, because the expire date will go further
since the last renew.

I will look further in the logging, maybe here will something appears.

Grtz,
Mek.
Do you get the SSL that is on the DirectAdmin panel? Or what SSL do you get?
If you get the wrong SSL on the mail part you may find this article helpful: Domain SSL on mail server
 
Hi Realcryptonight,

The default SSL server certificate (Self-signed root certificate) will be served (before letsencrypt generated the certs specific on domains or sub-domains in the control panel). The correct letsencrypt certificate will be displayed on https://mail.domain.com:2222 but not on https://mail.domain.com:443. So in my opinion Apache will serve the wrong certificate (since the the auto renew failed for some reason), but I can't find how to fix this in apache, since the same cert is valid for webmail.domain.com, smtp.domain.com & imap.domain.com which use the same cert file information. For dovecot/exim the correct certificate will also be served, when I do an SSL check.

Grtz,
Mek.
 
Hi Realcryptonight,

The default SSL server certificate (Self-signed root certificate) will be served (before letsencrypt generated the certs specific on domains or sub-domains in the control panel). The correct letsencrypt certificate will be displayed on https://mail.domain.com:2222 but not on https://mail.domain.com:443. So in my opinion Apache will serve the wrong certificate (since the the auto renew failed for some reason), but I can't find how to fix this in apache, since the same cert is valid for webmail.domain.com, smtp.domain.com & imap.domain.com which use the same cert file information. For dovecot/exim the correct certificate will also be served, when I do an SSL check.

Grtz,
Mek.
Do note tho that port 222 will be served by the DirectAdmin panel and port 443 will be served by apache. (They are 2 different systems.)
And could you verify that mail.domain.com is added as a common name?
 
Do note tho that port 222 will be served by the DirectAdmin panel and port 443 will be served by apache. (They are 2 different systems.)
And could you verify that mail.domain.com is added as a common name?
And did you add that certificate to your doman in DirectAdmin? (Since as mentioned above: the DirectAdmin panel uses its “own” web system that is independent of the website system. So it will not share SSLs with domains that are added in it.)
 
Do note tho that port 222 will be served by the DirectAdmin panel and port 443 will be served by apache. (They are 2 different systems.)
And could you verify that mail.domain.com is added as a common name?
Hi Realcryptonight,

mail.domain.com is added as a common name. Absolute. I saw indeed a different configuration file for directadmins
own webserver in: /usr/local/directadmin/conf/directadmin.conf

The strage thing is also, the server default name is: mail-server.domain.com (which is reachable by SSL on port 443 and port 2222). mail.domain.com is just an extra subdomain including: webmail, smtp, imap etc. I have no issues on other domains with mail.xxx.com
I have no clue why it's working (valid SSL on port 2222 for mail.domain.com, but not valid for SSL port 443), then the default self signed root cert will be served for some reason, which is valid until: Sat, 10 Oct 2048 07:47:07 GMT.

Grtz,
Mek.
 
I've the same problem. Certs are made for all subdomains, but the certificate shown is not for that subdomain. It is in the alternatives chain, but incorrect.
 
Back
Top