ucspi-ssl - TLS encryption for Client/Server IPv6/IPv4 communication

Hi Roberto,

     Is the ucspi-ssl package required to proceed further with the qmail installation. Cause I am stuck as Centos6 comes with Openssl 1.0.1 . And ucspi-ssl requires OpenSSL version at least 1.1.1. Thouch I have installed OpenSSL 1.1.1v in /usr/local/openssl and added the same to my ldconfig. I am getting the following error while installing ucspi-ssl

./compile sslclient.c
In file included from sslclient.c:11:
ucspissl.h:14:3: error: #error "Need OpenSSL version at least 1.1.1"
sslclient.c: In function âmainâ:
sslclient.c:154: warning: passing argument 2 of âgetoptbâ discards qualifiers from pointer target type
/usr/local/qlibs/include/getoptb.h:20: note: expected âchar **â but argument is of type âchar * const*â
sslclient.c:350: warning: implicit declaration of function âTLS_client_methodâ
sslclient.c:350: warning: passing argument 1 of âssl_contextâ makes pointer from integer without a cast
ucspissl.h:44: note: expected âconst struct SSL_METHOD *â but argument is of type âintâ
make: *** [sslclient.o] Error 1
compile: fatal: cannot make it-base

Can you point me in the right direction.

Regards

Shailendra

Hi, you don't need ucspi-ssl. Your users can do the auth on submission port 587 via qmail-smtpd. Qmail should work with old openssl versions as well

Hi Roberto,

Thanks for your part in keeping qmail and the community alive!

I am wondering if you have heard of, or explored, any options for Server Name Indication with SSL connections to Qmail.

Specifically, I want each of my clients to be able to configure their mail clients with mail.theirdomain.com for their incoming and outgoing connections, instead of having all clients use a common mail.mydomain.com.  Dovecot supports SNI, and it works well for incomign server settings, but I haven't found any thing in the qmail world for this yet for outgoing settings.

I wrote Dr Hoffman a few years back to see what it would cost to sponsor him adding it into ucspi-ssl, but I don't think he saw the value in providing this feature.  Maybe I didn't explain the use case well enough.

To get around the issue, I used to use my own self-signed Certificate Authority, and I would generate a cert for the mail server with all the domains/subdomains of my clients as SubjectAltNames.  From there, the client would have to install my CA on their devices, and then their devices would connect to the various domain names without error. Of course I had to script that so that the mail server cert would be regenerated with the correct SANs every time I added or removed a domain.  That system actually worked remarkably well from about 2007 or so, but my clients absolutely hated it and I lost a few of them over that.  So every time I upgrade or update my servers I am always looking around for another solution. 

Unfortunately maintaining a paid cert with all those SANs is prohibitively expensive, so I couldn't really solve the problem that way, and Let's Encrypt simply doesn't support the number of SANs I needed, so couldn't go that way, either.

So I started playing with haproxy 2-3 years ago and have implemented this with Let's Encrypt in front of my qmail instance to accomplish SNI.  Overall, this has been successful, but unfortunately it only works for direct SSL connections, and it will not support STARTTLS connections.  So I have been offering my clients a choice to use SSL with their domain on port 465, or STARTTLS with my domain on port 587, but if often confuses them (though not as badly as having to install a CA on all their devices), so I would ultimately like them to be able to use either protocol with their own domain.

Looking for any thoughts you, or any other readers of this site, might have on the topic?

Hi, thanks for your message. I guess you have tons of domains, much more than the 100 that you can handle by a single letsencrypt cert :-)

haproxy seems to be interesting and probably the right choice, but I've never heard of it before. 

I hope that anyone else here colud be of help

Hi Roberto,

Thanks for your reply.  Not looking to be an overly hot topic of conversation ;)

I do have more than 100 domains, but "much more" is quite relative given that it only takes *one more for Let's Encrypt to not work.  It is a further limitation if you need to have multiple subdomains per domain on the certificate as well.

Maybe I will approach Dr. Hoffman again; haproxy is a workable solution, but given that it is not a complete solution maybe he will have more interest this time.