So I have an IW server up and running since the beginning of this year and very much enjoy the setup. There have been a few little quirks for checking logs and filtering random IP’s that have been hammering the mail server with send to or login requests of invalid addresses, and xmlrpc.php requests trying to flood the server. Other than that, it has been running smoother than any other host I’ve been with.
The question I have today is, all domains are prompted with a “Security certificate cannot be verified” when initially opening Outlook to check e-mails. The accounts have been setup with SSL/TLS but only with the self generated certificate from IW.
To resolve this, I’m assuming that an actual valid SSL cert is needed per domain? or does the “Let’s Encrypt” plugin somewhat alleviate this? As much as I would like to have everything encrypted on each domain, buying that many static IP’s, and certs is just not feasible at this time. Do I have any other options?
I appreciate the help. I did not send a support ticket in as this is not quite a function issue with IW, but general help question.
Thanks.
Hi TechAlta
Many thanks, glad your liking IW
Firstly, have you installed and setup BFD (Brute Force Detection), if not, there are good posts on how to do this, and it should resolve your mail issue of abuse, along with other areas of abuse you may not be noticing
I am sorry, LE is not wildcard, and yes, mail.domain.url could be covered under CN, Qmail would not use it.
The best way to stop the warning is to use your server SSL MX record, and not that of the siteworx domain, which I have just tested here, and works lovely with no warning of SSL
I hope that helps a little
Many thanks
John
Thanks for the prompt reply. I checked out BFD and got it installed pretty quickly and setup the e-mail notification.
I thought that was probably true with LE. As for the SSL for the MX records, call me a bit dumb but I’m a little lost there.
The web-server SSL is self generated and domain is set to the server’s domain address (None of the e-mail domains). The POP3, IMAP, SMTP SSL are set on localhost as the domain.
Glad to hear you installed BFD now (hopefully you whitelisted your IP addresses so you don’t lock yourself out)
Ah, sorry my mistake, I thought you had a paid SSL on server but not siteworx accounts
If your running release candidate, lets encrypt can generate subdomain CN as well, so you should be able to generate using LE for server, mail, FTP, ssh etc (all services under server, SSL from nodeworx
If you have not setup a siteworx for your server hostname, I would advice you so, and match the SSL in full to server SSL
I hope that now makes sense and you should be good to go, subject to your siteworx users for email using my first post suggestion
-Primary interworx server as CM doing all functions
-Secondary interworx server only as load balancing and secondary DNS
-No SSL certs have been purchased (but can if needed, but only have limited amount of IP’s)
-There is a siteworx account for the domain the servers are listed as.
-All configuration relating to SSL’s are default from initial installation.
Let me know if this is out of the scope of the support from the forums, or if I should open a support ticket for this.
Outlook E-mail Authentication with Certificate Prompt
Hi techalta
Many thanks
To be honest, given your post I would strongly suggest you match our servers setup for server SSL as follows
Purchase a wildcard SSL (you create the SSL csr etc only from cm server)
Then copy the whole SSL (private key, csr, cert and chain) to the other servers and your server hostname siteworx account
Remember to restart httpd afterwards
You will not use anymore external IP addresses then you are now
Then you have 2 choices as follows
Set all mx records to your server SSL mx record
Or if you clients use their own siteworx mx record, they have to manually accept the SSL cert when it gives warning or change to use your server SSL mx record
Does this help
Also, if you have a wildcard SSL for server and introduce additional nodes/servers, you can use your wildcard SSL for these as well - so only costing 1 wildcard SSL (subject to you naming your server hostname the same for domain ns1.myhost.url ns2.myhost.url anything.myhost.url etc)
I hope I have explained so you can understand but please let me know if not and we sell wildcard SSL or you can look to buy
I do not think LE would work in your setup to cover all servers
Looks like I am keeping you busy with questions today. I do appreciate the help.
A lot easier to understand for me now.
With the two options,
Set all MX records to the main server SSL MX record. (Each hosted domain, point their MX record to the main MX record with the SSL)
-Each domain when receiving and sending e-mails would be authenticating and presenting the mail transfer through the main server SSL MX, and not their own.
-Problem is that some ISP’s around here require that the mail is received from the originating domain. (e.g. mail sent from info@mydomain.com is from mail.mydomain.com, not mail.e-mailbox.com)
Each siteworx MX record on their own.
-Currently how things are setup, but with a self signed SSL, of course Outlook is going to flag it as non-verified and prompt the “Would you like to accept this”. Have tried to install and store the cert on the system, but will not.
-Not a big deal and could do without SSL connections to get rid of the prompt, but who would refuse it if it’s available?
I would consider doing the wildcard SSL covering the CM and main siteworx account, but is there still the possibility that if one of the other domains wanted an SSL cert it could be purchased and set for their domain? (Wildcard only, without having to dedicate the IP to it.)
Hi TechAlta
Many thanks, and I perhaps am slightly confused or perhaps you are sorry.
I mean over over ISP requiring the user to use own MX or domain (which country are you in, and can you give an ISP who require this - note, some ISP may block ports for email, inwhich case you use secondary ports).
No email should be blocked for using a different MX record to their own domain (Outlook would go out of business fairly quickly if they did) and no mail servers should reject email based on their MX been different from the domain (the SPF, dkim and dmarc should cover mail servers)
If you could explain a little more, that would be good, and ideally give an example, or PM me with detail so I can understand a little better sorry, as I see it, a domain MX is part of domain DNS, so no block should happen.
IW use SNI, so you can set as many SSL certs (wildcard or any SSL certs, including LE) on as many siteworx accounts as you need, using only your shared hosting IP address, or as many IP address as you need. I hope that makes sense.
Lastly, in outlook, you do not download the cert or store it, upon first verification of account, if cert warning appears, you click the button to always trust SSL cert, and warning is not seen again, unless something changes and it appears again, but just do the same, and click always trust ssl cert
I hope that makes sense as the more I read it, the more I think I need to explain more, but this may confuse sorry
Many thanks
John
Haha I have even made myself confused there for a couple moments. I checked my notes on what was happening and it was this:
Location: Alberta, Canada.
When an e-mail was sent from our Interworx servers (Siteworx account setup, hosting mail services), and was sent to a “@Shaw.ca” address, it would bounce back with “554, Reverse DNS for x.x.x.x (My IP) does not exist.”
As many have said, and I corrected immediately was to make sure that:
DNS records for PTR, MX, are setup.
ISP for the servers (Who is actually Shaw as well) was contacted and told to update their reverse DNS records to correspond with both server IP’s and their domain names. (ns0.mydomain.com, ns1.mydomain.com)
I have not had any issues sending to anyone at an “@Shaw.ca” address since then, or ever anyone else for that matter. I thought I may have a similar issue occur if all MX records are updated to point to the new MX record with the SSL cert.
BUT, how I understand that it should work is:
Get wildcard SSL for “mydomain.com” (Using this as my Interworx domain is setup on, instead of actual domain name)
Apply it to the domain Interworx is setup on (Which covers the ns0.mydomain.com, ns1.mydomain.com doing all of Interworx/siteworx, including DNS, Mail, Web, firewall, etc.)
Modify all siteworx domains to point their MX records to now ns0.mydomain.com instead of their own MX record.
Result:
With all siteworx accounts being on the same server, the MX lookup record would simply resolve to ns0.mydomain.com, then IP, rather than just directly to the IP?
This is probably good to leave as a reference on the forum in case anyone else experiences it, but if you have any questions for me feel free to PM, or let me know where I can add you on Skype or anything else.
Thank you.
Your initial issue was as you state, PTR (RDNS) missing
Let’s say your server hostname is mydomain.url, so your NS would be ns1.mydomain.url and ns2.mydomain.url and mx record mail.mydomain.url, with your PTR shown as ns1.mydomain.url
The above are fictitious but as an example you do the following
Set a wildcard on mydomain.url (this then covers all subdomains of mydomain.url)
Set your SMTP host greeting to ns1.mydomain.url
(Make sure your wildcard SSL is set for all services in nodeworx, server SSL )
Now you change your DNS template for mx to mail.mydomain.url (this ensures all future siteworx accounts use your server mx record)
Change your current siteworx mx records to server mx record
Wait a few hours for all DNS to fully populate and stale cache to expire
Then test (should work lovely)
I think you have got it now anyway, just want to make sure (though you could set it differently, but just do not want to confuse you sorry)
No everything makes sense for the most part about needing a wildcard SSL for shared hosting. The only issue which is not a big one, but hoping to still question about, is that all other domains (example1.com, example2.com, example3.com) will have to use and change their incoming and outgoing mail servers from mail.example1.com to now mail.mydomain.com? (The one with the purchased wildcard SSL cert for Interworx)
That is where its a bit tough for me to assume and tell the 10-15 domains already on their with various amount of users each, that they need to change on all devices accessing e-mails to a different mail.mydomain.com rather than their own domain (mail.example1.com) in order for them to be able to use the SSL cert?
Or am I seeing that wrong?
To be able to provide SSL for e-mails under a shared hosting service would be great, until they want to pay for their own dedicated IP and SSL cert for their domain.
(*Dummy side question, getting a wildcard for the mydomain.com allows for the SSL cert to be present on any subdomains including www.mydomain.com, mail.mydomain.com, server.mydomain.com, etc. even though they are possibly on a different IP or different service?)
Your clients could remain with current mx record and just accept the warning about SSL (although when you have a paid SSL, you can click always accept SSL cert and not be prompted again), or they can change their settings on devices to server mx and receive no warning
Your clients can purchase their own SSL or use lets encrypt, and you do not need to use a dedicated IP address - IW uses SNI, which allows unlimited SSL on same IP address to be installed or they could have a dedicated IP address if they paid extra to you
I do have to point out that qmail would not use their SSL unless there were multiple qmail instances, which there are not and even if they were, they would need seperste ports to each other - that’s my understanding but apologies if I’m wrong. This is for email only though
Yes, your correct with wildcard SSL (any number of servers and different IP addresses) but it works the same on a standard SSL but with wildcard, you can use on all services such as SMTP, pop, FTP, ssh, https etc (on all servers using the same hostname domain) as the SSL covers the domain name, not the server or IP addresses. You cannot buy a SSL on an IP address (you used to be able to but was ceased a few years ago)