• 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

Forwarded to devs Dovecot SNI not working with Plesk Premium Email Extension (Kolab/Guam)

peterbo

New Pleskian
TITLE:
Dovecot SNI not working with Plesk Premium Email Extension (Kolab/Guam)
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:
Version 18.0.21 Update #5, Debian 9.11
PROBLEM DESCRIPTION:
When setting up SNI in the new Plesk Obsidian, certificate also configured for each domain's email security, Dovecot keeps sending the certificate that is setup for the whole mail server, not the one configured for an individual domain.

Code:
echo | openssl s_client -connect localhost:993 -servername xyz.com
will keep returning the global server's mail certificate, not dovecot's certificate from the local_name section. This seems to be the certificate which ius configured under /etc/guam/sys.config.

Querying the dovecot's IMAP port directly returns the correct certificate (9993):
Code:
echo | openssl s_client -connect localhost:9993 -servername xyz.com
This omit the guam wrapper around the IMAPS service and returns the correct certificate. So Dovecot alone would work with SNI.​
STEPS TO REPRODUCE:
- Setup Plesk with Plesk Premium Email (Kolab)
- Setup Domain, Emails and secure the individual Domain with an SSL-Certificate for E-Mail services​
ACTUAL RESULT:
IMAP answers with the serverwide configured SSL certificate for the mail service.​
EXPECTED RESULT:
Expectation: IMAP answers connections to that domain on port 993 with the individual SSL certificate​
ANY ADDITIONAL INFORMATION:
Since Plesk Premium Email Extensions is now some kind of first class citizen in Plesk, this should be fixed with high priority. For many I suppose, an argument for the fast update to Plesk Obsidian was the SNI support.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:
Help with sorting out
 
Thank you for the report.
SNI is not supported by KOLAB, and we are with it. We can’t do anything right now.
The module is not developed and supported by us.
There is an article on this subject http://kcs.plesk.ru/search-api/article/360033820133

PS. There is a statement that the KOLAB developers are aware of the problem, but at the moment there is no ETA
 
Hi @IgorG, Thank you for forwarding my message! Unfortunately, the link you provided doesn't work (at least on my machine).
Is there any way or anyone I can contact to ask about bypassing guam and what are the implications on that?

Apart from that, it'd be nice to have a notice or an error message indicating that SNI is not supported by KOLAB, when you're configuring domain based Email SSL-Certificates. This would have saved me hours of figuring this out. That strongly raises product frustration! Kolab is not any free third party plugin but a quite expensive premium extension, so this should be part of the MVP.
 
Last edited:
@Cosmin Catalin I tried to find out here, but as Kolab is not managed by Plesk but by an external vendor, we are not perfectly sure. We think that meanwhile SNI is supported as there are some hints to it, but personally I cannot say. Are you a Kolab user already? I have an info here that if SNI does not work right with Kolab, the Plesk user should run this command to fix it:
plesk bin extension -e kolab sync-guam-config.php
So I think that obviously there must be some kind of SNI support in that extension.
 
@Cosmin Catalin I tried to find out here, but as Kolab is not managed by Plesk but by an external vendor, we are not perfectly sure. We think that meanwhile SNI is supported as there are some hints to it, but personally I cannot say. Are you a Kolab user already? I have an info here that if SNI does not work right with Kolab, the Plesk user should run this command to fix it:
plesk bin extension -e kolab sync-guam-config.php
So I think that obviously there must be some kind of SNI support in that extension.
When executing what you have indicated, the imap(993) server no longer has any certificate assigned, which is why it is completely inaccessible.

To resolve and at least have a server certificate assigned, I had to reinstall the Premium Email extension
 
I had this issue again after the last upgrade of plesk premium email, all clients could not connect to 993 port on imap anymore..
Running the command `plesk bin extension -e kolab sync-guam-config.php` fixed it, there should really be some improvements done in this area.. It took me a whole week to find this thread and this command
 
I had this issue again after the last upgrade of plesk premium email, all clients could not connect to 993 port on imap anymore..
Running the command `plesk bin extension -e kolab sync-guam-config.php` fixed it, there should really be some improvements done in this area.. It took me a whole week to find this thread and this command
Right now the imap server is assigned the ssl certificate of the server and not of the domain, at the moment I execute the command "plesk bin extension -e kolab sync-guam-config.php" directly the certificate is no longer assigned, so it is no longer possible to connect securely to IMAP
 
I agree that this could be improved, but it will be best if you could please address the issues to Kolab as they are the vendors and manufacturers of the extension.
 
I agree that this could be improved, but it will be best if you could please address the issues to Kolab as they are the vendors and manufacturers of the extension.
If you could help me know how I can communicate with them, I will address it and explain it to them. I would really appreciate it if you tell me how to contact them
 
Back
Top