• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion
  • Inviting everyone to the UX test of a new security feature in the WP Toolkit
    For WordPress site owners, threats posed by hackers are ever-present. Because of this, we are developing a new security feature for the WP Toolkit. If the topic of WordPress website security is relevant to you, we would be grateful if you could share your experience and help us test the usability of this feature. We invite you to join us for a 1-hour online session via Google Meet. Select a convenient meeting time with our friendly UX staff here.

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