iPad Resolved: iPad Air 2 and iPad OS 13.1.2 Certificate Issue

[defjam]

My mother has an iPad Air 2 for which she upgraded iPad OS to 13.1.2. As a result she is no longer able to retrieve her e-mail as she receives a "Cannot Verify Server Identity" pop up. When she clicks on the "Details" button nothing happens (she just receives the error again) and if she clicks on "Cancel" she's able to read her existing e-mail but not retrieve any new e-mail (and then the error dialog will again pop up at some point).

The issue is she's using an e-mail server I personal operate and it is configured to force the use of encryption. In order to do that I need to configure a certificate which I've generated and is self signed. It is that latter part which is causing the error. Typically all that need be done is to accept the self signed certificate and all is good. For some reason the upgrade invalidated this acceptance.

Browsing the Internet the recommend fix for this is to delete the account from the iPad and re-create it. Presumably this would allow her to re-accept the self signed certificate. This seems extreme to me but looks to be the only way (it's configured as IMAP so her mail is stored on the server). My concern is the upgrade will no longer permit the use of self signed certificates (previous upgrades never invalidated the acceptance of the self signed certificate). Does anyone have any experience / thoughts on this?

I am not going to go out and obtain a recognized mail server certificate and I would like to avoid permitting the use of non-SSL enabled IMAP traffic if possible.

 

[Dave-Z]

I can help you with this as I've run private mail servers with private certificates. I am not running iOS 13 on any of my devices at the moment but I don't expect any of this to be different.

First you should review Apple's support document for certificates: support.apple.com/en-us/HT210176

Next be aware that private certificates are actually a normal thing in enterprise-level businesses. They're used to authenticate clients, prevent untrusted site warnings for internal HTTPS web sites, etc. The key is that these things are not simply self-signed server certificates. They are signed by a trusted certificate authority, but that trusted certificate authority can be you (really, it can).

Before I go into the details, if your mail server is not commercial you can use Let's Encrypt for certificates. Theirs are free and trusted by most major platforms these days. They are short run, 90 days, so you usually setup a cronjob to automate the renewal process. They have a tool called certbot that does it for you. (There are also other tools that do the same job.)

Back to doing all yourself... If you have a Mac, Linux, or Windows 10 (1809 or later) you can do all the certificate authority (CA) stuff yourself with the openssl command, but I prefer to use EasyRSA from the developers of OpenVPN. It's a bash script that wraps the openssl commands for creating CAs, server and client certificates all in one easy to use command. It allows you to easily revoke compromised certificates as well as export things in various formats.

You can fix the issue you're experiencing without deleting any accounts or re-configuring your mail server. (N.B. You mentioned you require encryption for connecting, that's good; make sure you're not requiring it for unauthenticated connections (i.e. other mail servers connecting to your mail server to deliver mail) because while sites like Gmail will take advantage of encryption, it's technically not a requirement in the spec and so some mail servers will fail to deliver mail as a result. But, yes, you absolutely want to require it for your users to authenticate and send/receive.)

Next use EasyRSA; do this offline/locally (i.e. not on your mail server because you do not want the CA private key to be on an Internet-facing machine!). Using EasyRSA you create your own CA. Then you create a server certificate signed by that CA. Put the server's public certificate and private key on your server and update the appropriate conf files to use these. Be sure to restart the processes (Postfix, Exim, Dovecot, whatever).

Next, put the CA's public certificate somewhere accessible (a public web site, email attachment (I get the irony ), iMessage, whatever)). On the iPad Air 2 access the URL (or click to open if it's attached somewhere) to get that certificate. Click all the Allow/Confirm/Yes dialogue boxes. Go into Settings > About > Trusted Certificate Authorities (not sure of the exact wording for this last one). Toggle your own certificate authority to on. Click all the Allow/Confirm/Yes dialogue boxes. Wait a few seconds for it to take effect.

You're done and it should work.

Post here if you have specific questions, encounter errors, etc. I have a pretty solid amount of experience with this so I'm happy to share it.

 

[defjam]

Thank you Dave-Z for the very comprehensive response.

I ended up resolving the issue by removing the account and then re-creating it. This allowed the self-signed certificate to be re-accepted and the connection to retrieve / send mail possible. Apparently there is a bug in 13.1.2 which resulted in the previously accepted certificate now being rejected. It would be nice if Apple would provide a means to just re-accept the certificate whenever there is a change. Having to remove the account and re-create it seems excessive (though it didn't take long to do).