Unable to “Trust” SSL certificate generated by Dovecot/openssl

Usual reason is the certificate and the host name and the DNS don’t match. Forward and reference must match for a mail server, both for certificates and more recently for anti-spam checks in other mail servers. (Other mail servers may or may not be an issue here.) Which also means the mail server gets a static address, or getting DDNS going and tied into your DHCP server.

Add the root cert into each of the clients using the Apple Configurator app, or one of the available MDM apps, and see if that works.

Basically, set up your own root CA, and signing and CSRs, and load and trust the root of that into each of the clients using profiles.

Self-signed certs will work when the host is correctly configured, and the cert is loaded and preferably via a trusted path. Usual reason for a certificate failure with a mail server is a lack of an A or AAAA record, or a mismatched A or AAAA record; a DNS error. Mail servers are particularly sensitive to DNS errors. The CA path makes part of that a little easier.

I’ve run Postfix relay out, and a mail-fetching script in, which avoids exposing the mail server.

Within your network, set up DNS, or edit and copy around the hosts file as was done prior to DNS.

You could conceivably also use mDNS naming here, if your DHCP server is willing to vend IP addresses based on client MAC address.

Setting up and trusting a root CA means you’re loading the trusted cert using a trusted path. A private CA is otherwise no different from a commercial CA. The sole difference is the trusted pre-load.

Somerset_WI wrote:

Router is LEDE/OpenWrt, hostname of computer running Dovecot is internetcomp and it is assigned a static ip by the router.

$ dig internetcomp.lan

I do not recommend DNS domain squatting. That was less hazardous years ago, before everybody can get their own TLD. Lots of new TLDs have come online too, with more arriving.

https://data.iana.org/TLD/tlds-alpha-by-domain.txt

..

;; ANSWER SECTION:

internetcomp.lan. 0 IN A 192.168.1.2

The important bit:

dig -x +short 192.168.1.2

I don’t recommend using 192.168.0.0/24, 192.168.1.0/24, nor 192.168.2.0/24, particularly if there is any potential future use of VPN connections. Those subnets are far too commonly used, and VPNs don’t react well to the same subnet on both ends of the connection. Subnets somewhere in 172.16.0.0/12 and 10.0.0.0/8 tend to be less occupied, thus less likely to encounter routing conflicts.

After a recent update Thunderbird stopped connecting too, so I reconfigured Dovecot to allow plaintext auth, and configured the iPad and Thunderbird to connect on port 143.

TCP 143 IMAP. No SSL/TLS. So no certificate.

According to a post on Bugzilla, self-signed certificates don’t use a CA,

Self-signed certs don’t use a public CA. They can use a private CA.

…but top level CA certificates are self-signed.  I may try making a root CA + server certificate out of curiosity to see if the problem persists, but this is getting more complicated than it used to be.

…Or more specifically, a configuration running a mail server in a NAT network in a subnet I would not generally recommend and seemingly without DNS, so, yes, there can be issues here. Setting up a CA and CSR’ing your stuff is negligible addition to this, and can be used for securing other connections if and as needed.

When I install the self-signed certificate on my iPad it shows up in General > VPN & Device Management but not General > About > Certificate Trust Settings.

Ah, well. You seem intent ina particular setup. Ah, well. Have at. I wish you well, here.

PS: Technical Q&A QA1948: HTTPS and Test Servers