I am wondering how to get my domain at a registrar to depend on just the DNS on the virtualmin server. Because mac mail is complaining about issues with the ssl and an associate of mine said that it was because I wasn’t using virtualmins internal BIND server.
Operating system: Centos
OS version: 8
Set up BIND, point your nameservers (at your domain registrar) to your BIND nameservers; and once you’re sure it’s working, terminate your DNS service with your registrar (or whatever third-party DNS you’re using).
First, however, I’d advise making sure that your friend is right. What kind of issues is Mac mail having? Third-party DNS can coexist quite nicely with Virtualmin.
Richard
That was my first thought. A few years ago there was a patch for Qmail specifically to fix TLS handshaking problems that affected only Apple mail transport. @betazedsoftware’s problem could be something like that.
This is what I am currently getting. There are 2 domains on the server hosting email and both present this error despite having their own ssl certs.
This is not a DNS issue (well, I guess it could be resolving to the wrong IP, which also happens to be setup with mail and, obviously, doesn’t have appropriate certs for your domains).
Are you trying to connect using the domain names themselves? SNI is not widely well supported in mail clients and servers. I’m not even sure if CentOS 8 has a new enough postfix to support it. Regardless, we still recommend you use a single domain for all mail services and use that domain to connect to the server (the username will be sufficient to send and receive mail to/from the right domain).
I remember back in the day we would just do a cname or a A record with @ in it pointing to the server and it used the dns from the server then rather than the registrar.
Yes. I’m using CentOS 8 and it still ships with crusty old Postfix 3.3. For SNI I think it needs to be 3.4 or higher. My domains never needed SNI since each had its own IP. But as soon as I added a sub-server with mail that shares its parent’s IP, client SSL errors like yours started showing up.
One way around it is what Joe recommends and it’s the easiest way: use the same domain for MX and client SMTP across the board. IMO, an improvement on this is to bypass mail.domain.tld and use the server’s hostname instead – that is, if you’re using a hosted domain as the server hostname’s TLD.
An alternative is to get SNI support from a newer Postfix release. There’s a tutorial for that.
Sorry, wrong nightmare. When you said “mac mail” I thought of an ugly experience I had with messages from iCloud and me-dot-com. Apparently I haven’t gotten over it.
For what it’s worth, I’m using Postfix 3.5.3 and SNI on CentOS 7 with no problems whatsoever. I upgraded it manually, which was quite an achievement because what I don’t know about Postfix could fill a large library.
As a side benefit, the automatic configuration in Thunderbird and most other clients I’ve tried (Apple Mail being a notable exception) work fine now. Apple Mail works, too, but PUSH doesn’t. That’s a limitation of the client, not the server.
Richard
If you click on the “Show Certificate” you will get an list of domains that are in that specific certificate. Looks like at least one is not included.
On my mac I’m just using the TLD for mail server settings and it’s working perfect 
Worth it! I decided to replace Postfix 3.3 with 3.5 and it’s all good. Your tips from older posts were helpful, in particular the one about updating /etc/webmin/postfix/version.
Thanks. I’m glad the posts made it a bit easier.
Richard
How did you setup sni after that?
Once the Postfix version is updated and /etc/webmin/postfix/version manually changed to reflect the update, a new option for Postfix IP certificate enabled? should magically appear in
Virtualmin > Server Configuration > SSL Certificate > Service Certificates
for mail for the particular domain in question. Once that’s enabled, you should be able to use mail.domain.tld as both the incoming and outgoing server for secure mail for that domain.
Richard
In my case I should have also paid attention to Dovecot. Postfix SNI behaved fine but when Thunderbird connected to IMAP Android clients didn’t. When Android connected Thunderbird didn’t. It was enough to drive a guy batshit. Long story short, I ended up issuing new certs and that’s when all the pieces fell into place.
Good to know. I didn’t know that because I’ve never used the default Android mail client. I used K9, which had no issues. K9 also works fine on Amazon Fire and on AOSiP (and presumably other AOSP forks).
I’ve since switched to an iPhone as my daily driver, and Canary has no issues. The native Apple Mail client does, but only with PUSH. Everything else works fine.
Of course, the certs have been updated several times since I updated Postfix; so any recent experiences would be after the certs were already updated.
Richard
In case it helps… When new certs were created /etc/dovecot.conf ended up with clean new entries like this:
ssl_cert = </home/user1/ssl.combined
ssl_key = </home/user1/ssl.key
ssl_cert = </home/user2/ssl.combined
ssl_key = </home/user2/ssl.key
But mobile clients were still being served the wrong certificate.
These changes made a difference and clients now get the right certs for the IMAP host:
local_name mail.domain1.tld {
ssl_cert = </home/user1/ssl.combined
ssl_key = </home/user1/ssl.key
}
local_name mail.domain2.tld {
ssl_cert = </home/user2/ssl.combined
ssl_key = </home/user2/ssl.key
}
Certificate paths will be different for sub-servers unless they’re using the parent domain’s SSL, which is how I did it:
local_name mail.subserver.domain2.tld {
ssl_cert = </home/user2/ssl.combined
ssl_key = </home/user2/ssl.key
}
It also helps to know that Dovecot SNI may not be supported by a client (see Dovecot docs)…
“It is important to note that having multiple SSL certificates per IP will not be compatible with all clients, especially mobile ones. It is a TLS SNI limitation. See SSL/SNIClientSupport for list of clients known to (not) support SNI.”
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.