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

May 9, 2022 Roberto Puzzanghera 3 comments

sslserver, sslclient, and sslhandle are command-line tools for building SSL client-server applications. 

sslserver listens for IPv6 and/or IPv4 connections, and runs a program for each connection it accepts. The program environment includes variables that hold the local and remote host names, IP addresses, and port numbers. sslserver offers a concurrency limit on acceptance of new connections, and selective handling of connections based on client identity supporting CIDR IP address notation. sslserver supports STARTTLS and STLS.

sslclient requests a connection to either a IPv6 or IPv4 TCP sockets, and runs a program. The program environment includes the same variables as for sslserver.

sslhandle is a pre-forking sslserver; though without STARTTLS/STLS capabilities.

With sslserver we can have a secure connection on port 465 to receive our emails.

You have already installed fehQlibs, which are supplementary C libraries needed for ucspi-ssl.

tar xzf /usr/local/src/ucspi-ssl-0.12.3.tgz
cd host/superscript.com/net/ucspi-ssl-0.12.3

The configuration of the supervise script for qmail-smtps is inside the configuration page.


SNI for SSL connections

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?

Reply | Permalink

SNI for SSL connections

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

Reply | Permalink

SNI for SSL connections

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.

Reply | Permalink