• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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