• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

expired "Parallels" SSL cert and email issues

JeffreyZ

Basic Pleskian
I have a client who is having difficulty setting up Mac Mail due to a certificate not being trusted. Choosing "trust" is not resolving the issue. I'm wondering if having an expired Parallels self-signed certificate could be contributing to this problem.

If I create a new certificate, will I then create issues with all my clients running SSL/TLS for their mail? In other words are they going to now get a security warning because it is no longer the cert they "trusted".

Also, I purchased an SSL certificate that I use with Control Panel logins, but it does not show when connecting via email. I found a thread "How to Change Default Certificates" which seems like what I need to do. http://kb.odin.com/en/118917 -- does this sound about right?
 
Yup, you just follow the instructions to install the certificate for email.

The ones who had previously trusted your old certificate may indeed have to trust the new one.

But note that even with the purchased one, if the certificate is for domain.tld and they connect to domain2.tld then they will still get an error, because although the certificate is valid, it does not match the domain their email client has been configured to connect to.

Similarly, if the certificate is for domain.tld and they connect to mail.domain.tld they will also get an error.

Using a wildcard certificate solves the domain.tld / mail.domain.tld issue. Asking all customers (on a shared IP) to use domain.tld solves the other issue.

Also I'm pretty sure someone on the forum posted how to use multiple ssls with multiple domains. There's also info in the Postfix website. I could be confusing this with something else though, so check before assuming this is correct.
 
Faris, thanks for your reply. If I'm understanding correctly when you say "Asking all customers (on a shared IP) to use domain.tld solves the other issue." you mean that if I tell them to set incoming and outgoing mail server to be my server domain name rather than their domain name that will solve the other issue. When I test mail setup for a random domain on my server it doesn't work. So in other words I can only connect when using mail.my-clients-domain.tld and cannont connect with mail.my-server-domain.tld. Should mail be able to connect using the server's hostname?
 
If they are all on the same IP then yes, you should be able to connect to the hostname. After all, you probably have root/postmaster/abuse/[email protected] and you must collect email from that address? Remember, domain.tld has an A record pointing to a certain IP. The clients also have theirdomain also with A records pointing to the SAME IP. So whether you use the IP address, and whichever domain name you use, you end up connecting to the same IP.

Of course Apache decides which website to show based on which domain was used when connecting. I'm not aware of Postfix caring which domain is used except for authentication ? But you are making me doubt myself now :)

Now your email program does care about the hostname set in the POP3/SMTP/IMAP server address box, when using any form of secure connection, because it needs to check that against the name the SSL certificate is issued for. If they do not match then it will throw an error.
 
Thanks for the follow up! I was able to connect mail using mail.hostname.tld. I'll buy a cert for that and see how it goes.
 
I followed the instructions on this article (https://kb.odin.com/en/118917) and replaced the certificates in the following files:

/etc/postfix/postfix_default.pem
/usr/share/pop3d.pem
/usr/share/imapd.pem

I then restarted these services:
# /etc/init.d/courier-pop3d restart
# /etc/init.d/courier-pop3s restart
# /etc/init.d/courier-imapd restart
# /etc/init.d/courier-imaps restart
# /etc/init.d/postfix restart

In testing, per this article (https://kb.plesk.com/en/118918) I get a failure on 465 but success on the others. Perhaps I missed something?
 
Last edited:
Now my admin mailbox is filling up with error message emails with subjects like this one:
Postfix SMTP server: errors from m165.salsalabs.net[69.174.83.165]

And when trying to send from webmail I get an error message "Could not open secure TLS connection to the server"

[root@my-hosting share]# openssl s_client -showcerts -connect mail.my-hosting.net:465
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
 
Last edited:
I paid a service to fix this issue. I don't know what they did but it's properly configured now. I'll assume I missed a step somewhere in the instructions.
 
Back
Top