10 ms·
iOS 18 breaks IMAPS self-signed certs
- rmoriz 2y agoI had this issue with let's encrypt certificates. IMHO it's unreleated to the issue. IOS18 mail initially connected using TLSv1.3. Afer deleting and re-installing Mail, the connection falls back to TLSSv1.2 and another set of ciphers. Then downloading of mails works again. Using dovecot 2.3/Ubuntu on the server.
- mmd45 2y ago:-( hey lurking apple devs- can someone please escalate this?
- cpach 2y agoI would not bet money that Apple is willing to change their mind regarding this question.
- mmd45 2y agoper apple dev forums it seems like they have a history of breaking this and then fixing it. additionally, while IMAP is broken, calendars and notes seem to work just fine so hopefully it's not deliberate.
- deleted 2y ago[deleted]
- Arnt 2y agoI switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.
- mmd45 2y agoI'm using a private ip over a vpn so I don't think that workaround will work for me. I don't really want a public dns record.
- Arnt 2y agoLE will issue you a wildcard certificate and it's usable for mail.
- mmd45 2y agoi'm just using a hardcoded private ip to connect to the imap server. are you saying i can get a certificate with a hostname of "*" that will match ANY ip address?
- oneplane 2y agoNo, but you could use DNS for that internal IP. And then you'd have a hostname. Since your IMAP server likely has some way of getting external mail, it is likely that you have a DNS zone and MX records, so adding an A record for your internal IMAP access isn't that much of an effort compared to what you already would have. If you have mmd45.com as a domain and have MX records pointing to your mail server, adding imap.mmd45.com pointing to your IMAP server should be fairly simple. Getting a Let's Encrypt certificate for *.mmd45.com is all that remains for the TLS part with a valid CA chain. As a bonus you can then also use encrypted SMTP.
- mmd45 2y agounfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.
- 0x457 2y agoOnly thing required for this setup to work: client needs to be able to resolve domain to internal ip. I have wireguard mesh with a bunch of services that use LE for TLS that have no access to interwebs and not accessible from interwebs.
- mmd45 2y agohow are you renewing the LE certificate if the domain is resolving to an internal ip? this seems like a big hoop to jump through.
- ytch 2y agoACME DNS-01 Challenge doesn't need a public resolvable and reachable host, it just sets a temporary DNS record to verify.
- hedora 2y agoThat adds a lot of attack surface vs. issuing a self-signed cert and confirming it was securely verified by your imap client. Not only could let’s encrypt issue a mitm cert for your imap connections, so could other CAs, and any cloud providers / dns providers you use.
- commandersaki 2y agoUh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt. And any CA can generate a certificate to MITM anything. That's why it's pretty much a requirement to submit all certs issued to Certificate Transparency, and if you're found to be misbehaving expect to receive ire from CA/B.
- beeflet 2y agowhy should I require some third party's permission to do encryption between one of my computers and another one of my computers?
- kijin 2y agoBecause you chose to use a program that doesn't accept self-signed certificates. Use a different program or a different computer that actually respects your freedom to tinker with it. Problem solved.
- DidYaWipe 2y agoNo. He noted that it's a REGRESSION. So he chose one that DID accept them. Running away from defects doesn't get them fixed.
- Arnt 2y agoSelf-signed certs were a defect — people were used to just click OK and blackhats exploited that. OP wants support for the special case where only the cert issuer trusts the cert (he has his own self-signed cert). Apple and others do support that: You make a private CA, trust that CA in the device, and then use that CA to sign certs for your IMAP server. IIRC (and this is from vague memory) you may need to configure yourself to be a company that manages employees' devices.
- mmd45 2y agohttps://developer.apple.com/forums/thread/732409 https://developer.apple.com/forums/thread/732409 (fixed url) seems like the issue is specifically with IMAP- I can confirm that calendar syncing works fine with the self signed cert. this is really disappointing.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- m463 2y agoCan you add your own CA cert to your device?
- telgareith 2y agoYes.
- urda 2y agoYes, I have a private CA I install on all my Apple devices for my self-signed certs. After I have the root CA on the device, it looks like any other valid SSL to iOS / macOS.
- mysteria 2y agoAt least with Safari all my internal SSL web services work properly on iOS with the root cert installed. Not sure about IMAP.
- lxgr 2y agoYou can, but I find that much less secure than being able to TOFU a self-signed certificate: I once did this, and besides being incredibly unergonomic, now I have to either securely destroy or safely store the signing key for the self-signed CA, or risk malware from performing an MITM against any app on my device, and not just e.g. the email client.
- benmmurphy 2y ago
- stephenmac98 2y agoIt's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid. Plenty of existing applications will refuse to connect to a self-signed certificate on the belief that allowing the end-user to confirm a certificate offers basically 0 protection against malicious actors.
- mmd45 2y agoexplain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.
- stephenmac98 2y agoI didn't say a "pinned self signed cert is insecure" I said that self-signed certs are a lazy choice I also said "allowing the end-user to confirm a certificate offers basically 0 protection" If an average user get's prompted to trust a certificate they will do so blindly At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA Using a CA also allows for use of CRLs or OCPS. If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate. In Summary: Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs Using Self signed certificates creates more work when handling certificate leaks or certificate rotation Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate. BUT A self signed certificate is lower effort on the initial setup Lazy
- tiberious726 2y agoDoes anyone know if there is any way to get iOS's mail client to present a client cert? Or, barring that, any form of self-hosted MFA.
- punnerud 2y agoI wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy. Most apps work, but not everyone. Often called certificate pinning.
- tadfisher 2y agoApple isn't doing certificate pinning, it's the apps verifying the certificate chain themselves by baking in public keys (or hashes/fingerprints). So there's not really a way for Apple to break this.
- londons_explore 2y agoApple could say "If you wanna talk HTTPS, you have to use our HTTPSClient class, and that only supports using the system certificate store and does not support pinning". Or they could say "All apps that don't support custom certificates for https will be denied app store approval".
- lxgr 2y agoWhile you're at it, make sure to have them prohibit any encryption on top of HTTPS, or apps might just be hiding things in application-level encryption schemes! Banning certificate pinning... Do we really need mandated insecurity by prohibiting apps from doing better than trusting all Apple-trusted CAs around the world?
- londons_explore 2y agoA better rule might be "You must use our HTTPSClient class, and it either uses the system+user trust stores, or optionally it uses an application supplied certificate authority+the user trust store".
- saagarjha 2y agoThey already do that to some extent, actually. Not as you mention, but because of US export compliance laws.
- nerdile 2y agoSo in summary: iOS used to accept untrusted certificates, yikes! Now, it validates the server cert, and people are upset? This blatantly insecure thing is broken now and the posters don't want to set it up securely? It seems like these people are just struggling with how to properly set up their email server and clients when using a private CA. If you're going to use your own CA, then configure your client to trust it. The rest of us should be able to enjoy secure defaults and not have to worry about our less informed family members being tricked into bypassing basic security protections like TLS validation.
- mmd45 2y agobad summary. it prompted you to accept the certificate upon first use and then pinned it which is far different than what you are describing in terms of security implications.
- nerdile 2y agoTOFU for invalid/untrusted certificates is the equivalent of "go there anyway" in a browser Very different than explicitly trusting a Private CA. It means that skilled attackers can rely on unskilled users clicking the "trust me, it's fine" button. All so that someone skilled enough to set up their own email server and certificates doesn't have to configure their system securely? This is about making bad things harder for unskilled users at the cost of raising the standard for service providers. If you can set up an email server, you can use easyrsa or step-ca or some manual openssl to create your own root CA. Or, register your self-signed email server as a trusted root CA. Personally, I use easyrsa for my internal CA (with domain path constraints because I'm paranoid) and letsencrypt for my mail server, but I require VPN access to the user ports on the mail server.
- mmd45 2y agoyou are assuming i have users and this is a mail server not a website which has a very different access pattern more analogous to ssh where TOFU works beautifully.
- walrus01 2y agoI think the solution to this is to: a) run your own private root CA b) install the public part of the root CA on your device and trust it (basically the same as many major enterprise end users of android and ios devices need to do already, so this functionality is extremely unlikely to be removed from the operating system) c) use the root CA to sign a cert for your mail server Yes it's a bit more hassle than just trying to tell the mail client to trust your self-signed cert that was generated on the mail server and signed by nothing, but I can understand why apple (given the population of hundreds of millions of NON TECHNICAL end users) doesn't want people just blindly clicking through "yes/I accept/trust this server" self signed cert warnings.
- deleted 2y ago[deleted]
- techbrovanguard 2y agotangent, but you can’t send mail on ios with an idn because “the sender address was invalid”, despite it working in macos. i’ve read this is caused by a broken regex check. if any apple employees are reading please take a look
- snapetom 2y agoThere are so many quirks between the way Mail behaves on iOS vs Mac, its infuriating. At the core of it, if you are manually adding IMAP/SMTP/POP, both just need to get out of the way and stop trying to help. Very typical of Apple to think it knows better than you.
- schoen 2y agoDoes some other software (like the MUA) need to convert the IDN to punycode before submitting it to the OS?
- yieldcrv 2y agoI feel like this going to happen to the permissionless side of crypto assets just like whats happened to most of the web 1.0 stuff Walled garden things will take over and something is going to happen to EOAs that make them nerfed or rare but at the same time, that might take 40 years just like these web 1.0 problems so its fine for now
- sgt 2y agoI think I've seen this before, in previous versions of iOS. You used to be able to just force a trust, but it would ask you again sometimes. I ended up just using LetsEncrypt certs, the one I use on the main website. Then I have a hook that also copies it to mailu.
- apparentorder 2y agoI run my own CA and install it as a trusted CA via Configuration Profiles. This works fine, including iOS 17. Does this break in iOS 18 or does this affect only self-signed (untrusted) certificates?
- stbenjam 2y agoI have the same setup and it works fine on iOS 18.
- xg15 2y agoAnd the Apple fanboys are loose again... Regardless how your opinion on PKI and self-signed certificates is, shouldn't we at least be bothered by the fact that Apple just switched off this feature without any communication whatsoever? The community was literally in the dark about whether this is an official policy change or a bug. Google, in situations like this, at least made some corpospeak press release officially "sunsetting" the feature and provided an official deprecation timeline so users have time to adapt. Apple is apparently just leaving their users stranded and unable to access their email.
- CrispyKatsu 2y ago[dead]
- ben_w 2y agoI suspect it's worse than that. Since the UK's Investigatory Powers Act 2016, I've noted that every web browser is necessarily an end-to-end encrypted communication system. This isn't compatible with what all the spy agencies want. The US can kinda get past that with the reporting obligation for anyone publishing on an app store controlled by a US company. (As a British citizen living in Berlin, the corresponding checkbox when publishing apps is mildly infuriating). Now that Apple is obligated to allow competitors, that doesn't work. Or perhaps the agencies finally noticed that this problem applies to websites and not just apps (perhaps web apps are finally good enough?) So the agencies find another way — and this time it comes with an obligation to not report what they're doing. This smells like that other way. Might not be correct, but intelligence agencies' long-standing history means it's not paranoia.
- deleted 2y ago[deleted]
- farnwomt 2y agoI use letsencrypt for my mail server and I have done so for years, but iOS 18 appears to have broken my configuration which has worked perfectly for as long as I can remember. I believe my certificates were all set up correctly because it never gave me a problem up until now and never asked for authorisation of any kind. At this stage MacOSX works just fine, but iOS 18 and iPadOS 18 just do nothing.