1
How to debug HTTPS bind problem (Linux) ?
Question asked by Nathan - 2/12/2025 at 2:00 PM
Answered
I have just performed a test migration from Windows to Linux and have copied the data over as per the knowledge base article. The conversion process has completed so I can now connect via HTTP to administer or login as an end user. 

However, despite having migrated the PFX and confirm the correct password is set the built-in webserver does not appear to be binding to HTTPS. More specifically it appears the port is listening but there is no response via a browser or using 'openssl s_client -tls1_2 -connect':

no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 195 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1739393454
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

The port is not being blocked by a firewall. If I test the mail ports (25, 587, 993, etc) using openssl to test I receive an appropriate response indicating the certificate is working. I am attempting to use the same certificate for HTTPS. The certificate happens to be a wildcard but historically that has not impacted.

It is almost certainly something simple but I am struggling to determine what it is! Does anyone have any thoughts?

5 Replies

Reply to Thread
1
Kyle Kerst Replied
Employee Post
Could this be the certificates not being in the correct directory? The error indicating no peer certificate available tells me its not actually reaching the PFX file potentially. In a default installation you'll find the PFX files under /var/lib/smartermail/Certificates so any migrated certs should be there as well. Lastly, since you migrated from another environment you may also want to verify that the write permissions are set correctly for the files/directory.
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Nathan Replied
The PFX is in the same path you listed and shows in the admin section as valid. The certificate is successfully used by the IMAP/POP/SMTP ports but not the web server.

I was initially running the daemon as root but have since followed your guide to switch to a 'smartermail' user account. As part of your guide I reset the permissions correctly. (It was broken whilst using root so it is not the switch to a smartermail account that caused it).

Other than not being able to enable HTTPS everything else went smoothly with the test upgrade which was really positive.

Is it possible to enable verbose logging on the web service?
0
Kyle Kerst Replied
Employee Post
It definitely sounds like you have everything where it should be! I'm going to check in with our developers to see if there is a way to debug what certificates it's selecting.
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Kyle Kerst Replied
Employee Post
Some other things I thought of while waiting for a response on this!

- Do you have HSTS enabled for this hostname? I ask because perhaps the HSTS entries in your browser could be fighting the new host. I believe there is a chrome:// flag you can access to delete individual entries so this might be worth trying to see if HTTPS begins working again at that point. <-- This is done in Chrome with chrome://net-internals/#hsts

- If you run a sudo service smartermail status in normal cases you'll see when we bind to port 80/443 logged, so you may be able to run that right after attempting HTTPS to see if any errors get logged when that happens.

- Does the new user you're running under have sudo privileges? Perhaps they're not able to stat the certificate directory and so we're running into an error there preventing the certificate loading? All of the PFX files in my test box show a user/group of root likely because this box was installed under defaults and with sudo being used.

Development says there isn't a single debug log that centers around PFX selection beyond our Certificates log file, but that this log file should show when we select the PFX from the directory along with any errors we encountered. The certificates log should contain some detail here at least:

16:34:35.187 ACME: Verification complete for host.name.com in system. Generating certificate
16:34:37.452 ACME: Certificate for host.name.com has been bound and will be used for future HTTPS connections.
16:34:37.457 ACME: Certificate for host.name.com has been bound and will be used for future HTTPS connections.
16:35:07.028 [10.1.5.164][21210258] SNI using fallback binding certificate host.name.com.pfx for (no hostname passed to SNI).
16:36:07.063 [10.1.5.164][28265781] SNI using fallback binding certificate host.name.com.pfx for (no hostname passed to SNI).
Based on the code that leads into this area though the biggest possible culprits are the certificates path directory and/or the password being used to access those files. You've already checked there though so I think your best bet might be a support ticket so we can collect some examples and have that team do a review for us. 
Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com
0
Nathan Replied
Marked As Answer
The problem seems to be related to using a wildcard certificate. I ordered a new cert from the CA for the primary FQDN and now it works. If I remove the non-wildcard certificate it stops working, if I re-add it works fine. This seems to only impact Kestrel, not the mail services.

Reply to Thread