What needs to be done to overcome the pinning issue with Apple mail (MAC mail)

Hi folks,

looking for some guidance on what needs to be done to the XG so that the XG CA meets Apple CA pinning requirements. The CA works fine for SMPTS and decrypt scanning in the web proxy, but not for iMAPS.

When you first enable iMAPS scanning the certificate asks for for permission to continue which if granted works for about 30 minutes before failing again.

Ian

  • Hi Ian, 

    Thanks for the feedback. Which MAC version you are using ?

     

    Regards,

    Saurabh

  • I have the same issue on the latest version of Mac OS, iOS and iPad OS.

    I thought this was based on Apple changing their certificate requirements that was resolved in V17.

    Edit: I should add I still have issues with SMTPS. I’ll get a certificate error but if I click continue in Mac OS/iOS/iPad OS, it message still sends (I believe it’s simply because I’m forcing the use of the certificate that’s failing). I have no idea though, Sophos XG and email with Apple products has always been very problematic for me.

    ---

    Sophos XG guides for home users: https://shred086.wordpress.com/

  • Hi,

    I am using the latest version of Catalina, IOSpad and IOS. My wife is also using Outlook for MACs on her MBP and that also fails.

    I have spent a lot of time resolving MAC mail and Outlook issues in the past. There are no errors logged in XG to assist with debugging.

    The mail applications work correctly when not connected to the XG or IMAP scanning is disabled. 

    Ian

     

    Update - more testing finds that the main ISP does not use SSL/TLS for sending mail to their SMTP mail servers. The XG reports on the service as being SSL/TLS in the dally reports.

    So in summary mail scanning on MACs is broken.

    Turn off scanning and the CAs are valid.

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Hi everyone, thank you for your feedback and your patience in this matter. As you know Apple have made some changes to the CA and cert requirements for iOS and MacOS. Briefly below these are summarised, and our response.

    Current Apple requirements for iOS 13 and MacOS 10.15:

    All TLS server certificates must comply with these new security requirements in iOS 13 and macOS 10.15:

    • TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
    • TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

    Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines:

    • TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
    • TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

    Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

     

    We are tracking and fixing this issue in NC-55223 and the fix is currently timed for v18.0.1 (MR1) release.

  • Stuart,

    I really hope you can fix in GA.

    Thanks for your info.