Broken SmarterMail UI after upgrade to 13.3
Problem reported by Jamin Blount - 3/26/2015 at 4:29 PM
Just upgraded to v13.3.5535 from 13.1. Seemed to work fine at first, but after rebooting the server, I am unable to connect to the SM UI. IMAP and Outlook still seem to work just fine.
Trying over HTTPS (which used to work fine other than me using a self-signed cert) now fails entirely with chrome's sad face "this webpage is not available", Error code: ERR_CONNECTION_ABORTED.
HTTP at least connects to the login page, but I get two specific 404s on javascript files and then the page fails to build correctly. 404s on:
And then javascript errors:
Uncaught ReferenceError: jQuery is not defined
Uncaught ReferenceError: $ is not defined
The login panel itself is weird, smaller than normal, and shows "[SMWeb.Login_Example]" in red text next to the word "Email Address".
And then once I log in, I just get SM's white Gear page, "Oops! There was an issue that caused this page to malfunction."
To upgrade, I stopped the SM service and the IIS site, uninstalled SM, installed the new version, then stopped the SM built in webserver and started the IIS site. Like I said, it initially worked fine. But then after rebooting, I get this.
Not sure where to go from here, or where in the logs it would be.
Thank you in advance for any help.

3 Replies

Reply to Thread
Steve Reid Replied
Please uninstall and reboot the server. After is comes back up reinstall.
Bruce Barnes Replied
The issue of using self-signed certificates has been discussed at length in both these forums and on sites like Microsoft Technet.  
Unless you are very familiar with the new certificate security requirements, you should be very careful about using self-signed certificates.
All certificates must now be at least 2048 bit public and private keys - Microsoft depreciated all keys of 1024 bits and smaller on 1 December, 2014.  US Cert depreciated all keys of 1024 bits almost a year prior to Microsoft.
Additionally, all SSL Certificates should now be created using SHA2 (SHA256) as       will be depreciated in the Spring of 2016.
Finally, you will also need to test your certs to make certain they are actually protecting your server(s) - whether SmarterMail, FTP, Webhosting, VOIP, Gaming, or for any other purpose
QUALSYS SSL Labs provides a very good online testing tool at: https://www.ssllabs.com/ssltest/index.html.  
Remember to test using the FQDN of your MX server, IE: our SSL certificate protected SmarterMail MX server's name is "securemail.chicagonettech.com," so we enter securemail.chicagonettech.com in the testing window on the QUALSYS SSL Labs testing site.
You should also test all of your other certificate protected sites via their web URLS, IE: www.mydomain.com, etc.
Everything should be TLS protected now and you need to have TLS 1.2 and TLS 1.3 protocols enabled.  If you want backward compatibility to Android operating systems prior to Android 4.4, you should also have TLS 1.1 enabled.

Additional information, along with notes about the changes required to disable SSL V 1.0, V 1.1, and V 1.2, along with enabling TLS 1.0, TLS V 1.1, and TLS 1.2 can be found here: 
ALL SSL encryption has been depreciated and should be disabled.  Microsoft disabled SSL 1.0 in a security patch they issued on 12 December, 2014. 
Bruce Barnes
ChicagoNetTech Inc

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
Scarab Replied
First of all, make sure that the SmarterMail Web Service is Stopped and Disabled. If it is Running this will cause all kinds of strange behavior in SmarterMail running on IIS.
Then, go to your Smartermail v13.3.5535 download and right-click and choose "Properties" from the menu. Click on [UNBLOCK] button at the bottom-right corner. Right-click on the file again and choose "Run as Administrator". If you have Data Execution Prevention enabled (Windows Server has this enabled by default) and Protected Mode enabled (also enabled by default) you must do these steps prior to running the the install process otherwise it will install the 32-bit version and cause the symptoms you are experiencing on a 64-bit OS.

Reply to Thread