Let's Encrypt & ZeroSSL certificates don't work for pop/smtp/ftp.domain.com but work for everything else.

P

Panormitis

Verified User
Joined
Sep 13, 2014
Messages
40
Let's suppose I create a wildcard Let's Encrypt or ZeroSSL certificate for domain.com.
The ssl certificate works fine for:
domain.com
www.domain.com
mail.domain.com
webmail.domain.com
Any subdomain.domain.com

But for pop.domain.com, smtp.domain.com and ftp.domain.com, the hostname ssl certificate is loaded, and I get a common name mismatch error.

A records exists in DNS, I see no errors in the logs (unless I'm looking in the wrong place).
The same thing happens if I don't create a wildcard certificate and select the entries (domain.com, www.domain.com, ftp.domain.com etc.) manually.

pop.domain.com, smtp.domain.com and ftp.domain.com, always use the hostname certificate, not the domain certificate. Any ideas?
 
Panormitis said:
pop.domain.com, smtp.domain.com and ftp.domain.com,
Click to expand...
I don't know of ftp.domain.com but did you create pop.domain.com and smtp.domain.com in DNS? Because by default they do not exist.
If yes, are they A records instead of Cname records?

How or where do you check these, so where do you see the common name mismatch error?
 
Yes A records exist in DNS.
Initially I was testing with https://www.sslshopper.com/ssl-checker.html but then I remembered that it was performing the test only on port 443, so I decided to use openssl s_client.
I found out the following:
These use the correct certificate on ports 995, 465, 587. On port 443 the hostname certificate is used.
Code: 
openssl s_client -connect pop.domain.com:995 | grep CN
openssl s_client -connect smtp.domain.com:465 | grep CN
openssl s_client -connect smtp.domain.com:587 -starttls smtp | grep CN

mail.domain.com, domain.com, www.domain.com are using the correct certificate on any port I tested:
Code: 
openssl s_client -connect mail.domain.com:443 | grep CN
openssl s_client -connect mail.domain.com:995 | grep CN
openssl s_client -connect mail.domain.com:993 | grep CN
openssl s_client -connect mail.domain.com:465 | grep CN
openssl s_client -connect mail.domain.com:587 -starttls smtp | grep CN

openssl s_client -connect domain.com:443 | grep CN
openssl s_client -connect domain.com:995 | grep CN
openssl s_client -connect domain.com:993 | grep CN
openssl s_client -connect domain.com:465 | grep CN
openssl s_client -connect domain.com:587 -starttls smtp | grep CN

openssl s_client -connect www.domain.com:443 | grep CN
openssl s_client -connect www.domain.com:995 | grep CN
openssl s_client -connect www.domain.com:993 | grep CN
openssl s_client -connect www.domain.com:465 | grep CN
openssl s_client -connect www.domain.com:587 -starttls smtp | grep CN

However on port 21 (ftp) the hostname ssl certificate is used:
Code: 
openssl s_client -connect domain.com:21 -starttls ftp | grep CN
openssl s_client -connect ftp.domain.com:21 -starttls ftp | grep CN
 
I don't know. I tried waht you said, but when I use mail.domain.com on any port I get the hostname on the CN. like this on mail.domain.com port 995.
Code: 
verify return:1
depth=0 CN = server.domain.com
verify return:1
 0 s:/CN=server.domain.com
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
subject=/CN=server.domain.com

I doesn't matter what I use, also on other domains, it always shows the hostname. So also with www and mail. Do you see something different when you use mail and www?

I thought this was working as designed because SNI is used?
 
Richard G said:
I don't know. I tried waht you said, but when I use mail.domain.com on any port I get the hostname on the CN. like this on mail.domain.com port 995.

I doesn't matter what I use, also on other domains, it always shows the hostname. So also with www and mail. Do you see something different when you use mail and www?

I thought this was working as designed because SNI is used?
Click to expand...
In my case it works fine on 995.
Code: 
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = domain.com
verify return:1
 0 s:CN = domain.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
In my case the hostname ssl is used on port 21. The ftp server makes no difference by the way (I tried PureFTPd & ProFTPD).
 
Hmmz.. that is odd. I just went testing on 2 other servers. Another Centos 7.9 which also only gave the hostname in the CN.

Then I tested on an Almalinux 8.5 server and now we got some different outputs:
openssl s_client -connect mail.domain.com:995 | grep CN
result:
depth=0 CN = ftp.domain.com
in every case where CN was to be found. So that is very odd. But I don't know how that domain was made, manual or wildcard, probably manual.

And on a domain with a wildcard, it showed like this:
depth=0 CN = *.domain.com

So it seems that it works differently depending on which distro is used, for some reason.

Which distro and version are you using?
 
webserver test and mailserver test will have different result

from my test

]$ openssl s_client -connect smtp.domain.com:587 -starttls smtp | grep CN
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.domain.com
verify return:1
250 HELP
0 s:CN = *.domain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = *.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3

]$ openssl s_client -connect mail.domain.com:995 | grep CN
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.domain.com
verify return:1
0 s:CN = *.domain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = *.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
Click to expand...
]$ openssl s_client -connect ftp.domain.com:21 -starttls ftp | grep CN
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.domain.com
verify return:1
220 You will be disconnected after 15 minutes of inactivity.
0 s:CN = *.domain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = *.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
^C
[admin@serv ~]$ openssl s_client -connect domain.com:21 -starttls ftp | grep CN
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.domain.com
verify return:1
220 You will be disconnected after 15 minutes of inactivity.
0 s:CN = *.domain.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = *.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
Click to expand...

trying test at
CN=*.domain.com
Click to expand...

CN=hostname.domain.com
Click to expand...
Click to expand...

try checking from direct service like Mail SSL Checking , FTP SSL Checking

###UPDATE for testing openssl with :21
 
Last edited:
I'm using:
Rocky Linux 8.5
CustomBuild 2.0.0 (rev: 2874)
/usr/local/directadmin/scripts/letsencrypt.sh Version 2.0.30
 
jamgames2 said:
try checking from direct service like Mail SSL Checking , FTP SSL Checking
Click to expand...
If I do that with mail and www from the 2 links you had in your previous post, than all seems fine. Then I see the domain name, not the hostname.

Mail gave this:
Code: 
Common Name (CN)
*.domain.com
Alternative Names
*.domain.com
domain.com

And this is from www.
Code: 
CN=*.domain.com
Certificate chain
*.domain.com
41 days remaining
4096 bit
sha256WithRSAEncryption
R3
1158 days remaining
2048 bit
sha256WithRSAEncryption
ISRG Root X1 (Certificate is self-signed.)
4706 days remaining
4096 bit
sha256WithRSAEncryption

Subject
Common Name (CN)
*.domain.com

Alternative Names
*.domain.com
domain.com
so no hostname to see there either.
This is on the Centos 7 server which gave the hostname CN when using the commandline check.
 
That might be due to the test tool, it's for mail and www only, not for FTP.

I just tried with the mailserver test thing and then I get the same result:
CN=*.domain.com

So I checked a domain on the Alma 8.5 server to see if there is any difference, but that one also came up with *.domain.com as CN.
Only ssllabs complaints about the CN hostname. But it seems that is testing either hostnames, or domain names (websites.
When I use the domain name, I get an A and no complaints about any CN mismatch.

So I presume it's just depending on the test tools which result you get.

I found another way to test the FTP certificate, which also gives the correct CN name.
openssl s_client -connect ftp.domain.com:21 -starttls ftp -servername ftp.domain.com

Found that one here:
 
Odd. I can't explain it. I presume you have all these settings in the directadmin.conf file when using Letsencrypt?
mail_sni=1 enable_ssl_sni=1 ssl=1 letsencrypt=1
and these 3?
cacert=/usr/local/directadmin/conf/cacert.pem cakey=/usr/local/directadmin/conf/cakey.pem carootcert=/usr/local/directadmin/conf/carootcert.pem

If yes, I don't know,t hen you might need to send in a ticket if you have ticket support or see if anybody else knows.

Maybe @Zhenyapan or @bdacus01 have a clue?
 
did you try regenerate wildcard cert ? or trying rebuild all service.
Code: 
/usr/local/directadmin/custombuild/build all d

I just update my previous post result testing of :21 (ftp), it work fine on RockyLinux.
 
jamgames2 said:
did you try regenerate wildcard cert ? or trying rebuild all service.
Code: 
/usr/local/directadmin/custombuild/build all d

I just update my previous post result testing of :21 (ftp), it work fine on RockyLinux.
Click to expand...
Yes I tried them both
Code: 
openssl s_client -connect ftp.domain.com:21 -starttls ftp -servername ftp.domain.com | grep CN
depth=0 CN = hostname.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = hostname.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = hostname.domain.com
verify return:1
220 ProFTPD Server ready.
 0 s:CN = hostname.domain.com
   i:C = US, O = Let's Encrypt, CN = R3
subject=CN = hostname.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
^C
 
Ok I found something interesting, initially I thought that using either PureFTPd or ProFTPd makes no difference.
However, with ProFTPd I get the hostname ssl (CN missmatch):
Code: 
openssl s_client -connect ftp.domain.com:21 -starttls ftp -servername ftp.domain.com | grep CN
depth=0 CN = hostname.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = hostname.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = hostname.domain.com
verify return:1
220 ProFTPD Server ready.
 0 s:CN = hostname.domain.com
   i:C = US, O = Let's Encrypt, CN = R3
subject=CN = hostname.domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
^C

If I install PureFTPd, I get the correct SSL certificate:
Code: 
openssl s_client -connect ftp.domain.com:21 -starttls ftp -servername ftp.domain.com | grep CN
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = domain.com
verify return:1
220 You will be disconnected after 15 minutes of inactivity.
 0 s:CN = domain.com
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=CN = domain.com
issuer=C = US, O = Let's Encrypt, CN = R3
^C

However PureFTPd doesn't support TLS data resumption, this is why I switched to ProFTPd some months ago.
I guess you can't have your cake and eat it too.
 
Hmmz... odd. I didn't expect that it would be a ProFTD thing. Indeed I used Pureftpd everywhere too. Good find.
 
Might be correct, because it appears to not need it.

What I've read is that ProFTPD can use TLS via openssl and no SNI is needed. For that reason there is a switch one can use in te ProFTPD config:
IgnoreSNI

Then it would just use mod_tls if I'm correct. However I'm not native English but you can read about this here.
 
Richard G said:
Might be correct, because it appears to not need it.

What I've read is that ProFTPD can use TLS via openssl and no SNI is needed. For that reason there is a switch one can use in te ProFTPD config:
IgnoreSNI

Then it would just use mod_tls if I'm correct. However I'm not native English but you can read about this here.
Click to expand...
I added "TLSOption IgnoreSNI" to proftpd.conf to check and restarted ProFTPD, but it didn't work, I was still getting the hostname CN.
So I'll keep using PureFTPd for now.
 
You must log in or register to reply here.
Back
Top