It appears that I have inadvertently applied a single secure certificate to the email of the entire group of virtual domains on a server using Postfix. This is causing some problems because email software is somehow automatically seeking to connect to the secure certificate of one of our virtual domains, rather than the secure self signed certificate of the server/postfix.
This was accomplished I suspect when I clicked on Apply Certificate to Email. I thought when I was doing that that it would apply only to the appropriate domain, but I'm seeing evidence now that the action is applying that certificate to all the virtual domains on the server which is resulting in refused sending connections to the mail server.
Is there a fix? Can I get the server to revert back to default settings with regard to secure email?
Comments
Submitted by andreychek on Tue, 04/11/2017 - 22:33 Comment #1
Howdy -- Postfix does generally have just one SSL certificate.
Do you happen to know what SSL certificate was previously installed?
The only time that isn't the case is when a Virtual Server with an SSL cert is on it's own IP address. In that particular case, the SSL cert should be copied to just that IP address in Postfix.
Submitted by stan on Wed, 04/12/2017 - 06:35 Comment #2
Postfix previously must have been using its own self signed certificate, or the server's self signed certificate. Previously the customer's certificate was deployed only for website use. Previously I had not clicked the copy to email option. Most likely that is overriding the default postfix security solution, but I don't know how to undo what I have done. Even with an https webmail connection, the postfix server now wants to display the customer's certificate and not a self signed. Both commercial certificates were/are provided by DigiCert.
Submitted by andreychek on Wed, 04/12/2017 - 08:15 Comment #3
What you could always do, is copy in a different SSL certificate from another Virtual Server.
You could create a more generic one, perhaps with the hostname of the server, or with your company name.
You could even use Let's Encrypt to create a free, widely supported SSL certificate, and copy that in.
Submitted by stan on Wed, 04/12/2017 - 15:04 Comment #4
I like both ideas for copying in a generic cert from another Virtual Server or creating a free one. Follow on question, can you guide me to how to properly install a server wide certificate that would not over ride existing customer certificates assigned to their specific domains? Webmail connections are properly handing off a generic postfix secure connection, but somehow Apple Mail and other email clients are latching on to something other than the generic. How do I force the generic to the forefront for email SSL
Submitted by andreychek on Wed, 04/12/2017 - 15:10 Comment #5
Howdy,
It all depends on how the service is being accessed.
Apache can handle multiple SSL certificates on one IP address -- but Postfix and Dovecot cannot.
So your clients can all have unique SSL certificates available via the web, but when accessing email services using Postfix or Dovecot, your server can only have one SSL certificate per IP address.
Does that help clear things up, or doesn't that explain the issues you're seeing?
Submitted by stan on Wed, 04/12/2017 - 15:25 Comment #6
We're getting very close now. What I need is guidance to restore the Postfix/Dovecot SSL certificate back to "factory" default generic. I apparently have inadvertently applied a client certificate to email service thinking that when I clicked on that button it would only relate to that client's email -- it did not, it impacted the entire email service for everyone. So I need to find where it overwrote the generic and how to get the generic back in place.
Submitted by andreychek on Wed, 04/12/2017 - 16:50 Comment #7
Well, the old certs were just self-signed certs. They would have had a domain name, though I don't know what domain name was listed in them. It could have been your hostname.
While it's not possible to replace that certificate exactly (ie, the old one isn't laying around, it's been overwritten), my suggestion would be to just create a new cert using a domain name of your choosing.
For example, you could create a cert using your systems hostname, or your company name.
If you just want a self-signed cert (not necessarily recommended), you could just create any Virtual Server with your preferred name, then enable SSL to have it create a self-signed cert.
What I'd actually recommend is to create a valid Let's Encrypt certificate, though for that to work the domain name in question would need to be accessible on the web.
Submitted by stan on Mon, 04/17/2017 - 10:28 Comment #8
Is there any chance you can recommend someone I could pay to assist me with installing a generic certificate. As a Mac user, I am very ill at ease with command line. There is little doubt in my mind that I have created this email problem by overwriting my generic postfix certificate. Frankly, I'm wondering if any certificate other than the one which comes with Postfix will address the issue. Apple Mail just simply refuses to accept a certificate which doesn't match the sending domain name. Since hawk.marketus.net was and is the created overall server's name, perhaps getting back to there will solve the issue.
Submitted by andreychek on Mon, 04/17/2017 - 10:48 Comment #9
You wouldn't need to use the command line to update the SSL certificate.
All you'd have to do is create an SSL certificate using Virtualmin, and then click the button to copy that to Postfix.
If all you want is a self-signed certificate, you can go into Server Configuration -> Manage SSL Certificates -> Create Self-signed certificate.
There, add the domain names you want included in the SSL certificate, and then click "Generate Self-signed key".
Once you do that, you can click "Copy to Postfix" to overwrite what's in there now.
That should be all you need in order to update it.
Submitted by stan on Wed, 04/19/2017 - 16:13 Comment #10
I did use the Webmin/Virtualmin user interface to generate a new self signed certificate and it is very much looking like that my have solved the problem. Please hold this ticket open for a day or so while I confirm that others are seeing an improvement as I now am. Thank you so much for the GUI that made this simple and your patience in guiding me to it!
Submitted by andreychek on Wed, 04/19/2017 - 23:00 Comment #11
Sure thing, we're in no rush to close this ticket, we can keep it open for as long as you like.
But we're glad to hear things are looking good!
If you have any questions at all though please feel free to let us know.
Submitted by stan on Sat, 04/22/2017 - 11:13 Comment #12
This issue has been resolved and I am very appreciative of Virtualmin's support and patience as we worked through it.