I am planning an hmailserver on a Windows Server 2019. The accounts on hmailserver use different domains, like one.com, two.com, but all domains have MX records that point to the primary domain mail address, so I thought I only need a wildcard certificate for the primary domain to cover them all, as far as certification on mail server is concerned (am I right?).
In addition, I’d rather not install IIS on this machine at all.
But I am at a loss with Certify the Web, since I am all confused when about certificates:
What would be some simple steps to setup a wildcard certificate for hmailserver? (I don’t really need the more complicated DNS-based procedure).
What would be some simple steps to setup automatic certificate renewal for hmailserver?
I am aware I may be asking too much, but then, other people, where did they learn these things from?
Let’s Encrypt does not offer wildcard certificates for http-01 validation. You must use dns-01 or include multiple alternate names on a non-wildcard certificate. (up to 100)
Certify can spin up a temporary port 80 server to serve the challenge requests that Let’s Encrypt requires. The option is in the Settings tab, ‘Enable Http Challenge Server’.
Certificate Deployment can be set to No Deployment to ignore Windows/IIS.
For my personal server, I have 3 deployment tasks configured…
I have hMailServer already configured to use a static file path for the above files, so restarting the service refreshes the certificates used.
I’m not really sure the MX records pointing anywhere matter. You’re securing a client’s SMTP/POP/IMAP to hMailServer. You don’t tell an email client about your MX records because it doesn’t care. You tell it about the hMailServer’s domain name/port. You can use CNAME records to forward one domain to another, but it will not make the client accept a certificate that doesn’t mention the first domain… so it’s not useful here.
I’m not aware of hMailServer having something like SNI where you can have many certificates enabled instead of one certificate that has all domains.
As a side note… I’m mostly talking about user clients connecting to hMailServer. Email clients really do care about validating certificates for servers they connect to… just as much as web browsers do. If the smallest thing fails, it’ll silently abort the connection at worst; stop and warn the user about the invalid certificate at best.
If you’re using hMailServer as a server that accepts connections from other MTAs… I’ve heard that many care about this less and some would even accept a self-signed certificate. So given the choice, I’d prepare for the email clients. Maybe your use-case is far outside of what I’m expecting.
All I want from this hmailserver is to serve POP email clients, and do some email forwarding.
Here is what I mean by those MX records:
Say the primary domain is primary.com, and some accounts on hmailserver also use one.com and two.com
The MX records for all the above domains point to the same mail.primary.com
Also, on the workstations’ Outlook accounts I set the incoming mail server as mail.primary.com for all, supposing all accounts use one of the above three domains.
It seems to me I don’t need any certification for any domain other than the primary one, am I wrong? Do I really need a wildcard certificate?
Does your CTW update certification for hmailserver automatically with no scripting?
MX records don’t mean anything to email clients that use POP. They are for MTAs to know where mail needs to be sent for your domain. Email clients use mostly A DNS records and maybe CNAME for DNS resolution to an IP.
If you want to make it a bit more friendly, you could add A or CNAME records for mail.one.com and mail.two.com to point to your hMailServer as well. Then you would have 3 names on your one certificate… which isn’t much harder than having one.
As I said, with Certify v5, I just have 3 deployment tasks that are not scripts. In the port/security UI of hMailServer, it says If you change these settings, hMailServer needs to be restarted for the changes to take effect. Which I take to mean that my choice to restart the service when re-exporting the cert/key is correct.
I noticed the current beta of hmailserver implements some new versions of some encryptions. Did you have to choose any of those in CTW? Or in hmailserver? If yes, where? And which one (encryption, version) was your choice? Or which one would you recommend if mail clients are all Outlook latest?
Hmm, Let’s Encrypt will give you a certificate that is strong enough to pass handshake requirements. The cipher that is used after the handshake isn’t up to the certificate. That’s up to the server configured to use the certificate.
I disabled TLS v1.1 and weaker, then ran some random vulnerability checker and disabled all ciphers it said were insecure. I don’t remember which ciphers those were.
For my version, the allowed ciphers are just a block of text delimited by a colon(:). To disable a cipher, you put an exclamation mark in front like: !MD5
I looked around and this checker seems to work fine for custom ports using SSL/TLS directly. https://www.htbridge.com/ssl/
It’s up to you how far you follow its advice, but if it complains a lot, consider it.
All right, then, to my understanding up to this point, after the handshake, server and client negotiate a cipher. So it’s not for me to decide.
But, as you said, one can disable weak ciphers on hmailserver. However, mail on my hmailserver does not require tight security, but just enough to communicate to the client without a flaw.
Given that, I think I won’t touch the cipher settings at all, on the server. Only on the Outlook client, I think I need to select SSL/TLS in account settings, and that would cover them all, the ciphers for negotiation.
Anything I am missing? If you can give a go, this seems to be a pretty nice/complete roundup for barebone hmailserver and CTW 5. Thanks a lot!
@jljtgr your setup sounds like an excellent example. I wonder if the Generic Server deployment task should have an option to include the full chain in the .cer, that way you’d only need one task + the restart service task.
I’m not entirely sure. I’m just happy that the options exist.
As your Apache deployment option demonstrates, for some reason web browsers don’t care about the intermediary chain. For some reason the mail client on my Android device did care once upon a time. If I were to try it again today, perhaps it would work? I’m not sure how the lookups of the intermediary CAs work if you just have the root CA and server cert at-hand.