Not trusted by Apple Devices

My domain is:*

I created a Cert so that SSL could be used on our mail server. Previous one expired ( Was self issued )

This is for POP, Imap and SMTP. ( So no IIS )

I created it for the servers host name not the mail Domain. Android Devices all seem okay ( Maybe not using SSL by default ), but every client on an iPhone gets pop ups to say that its not a trusted Cert. All the online testers I have used say that the chain is correct.


What version of iOS do you have?

Thank you

Hi. I would imagine the whole range because its our clients that have them not us. ie We host mailboxes for clients.
My Android phone is quiet happy with life. I did check that the phone in the picture was up to date with everything Apple could throw at it.

I did a work around by turning off SSL on both POP and iMap which solved it for that client, but thats not the answer to this issue. I’m puzzled why ?

What is the full domain? Can you test it with SSL Server Test (Powered by Qualys SSL Labs) ?

Thanks for that. Ive checked and it seems to pass okay. The FQDN is

Please correct me if I’m wrong, but I got the cert in the host name of the machine, not the pop or iMap Domain which happens to be something different. ( Well its a lot of different ones because a lot of our clients use pop.their_own_domain and smtp.their_own_domain which are just CNAMED to the actual server name )

TLS clients don't know about CNAMEs, so if they're accessing a host under a different name, they will fail to validate.

For example if I have IN CNAME and I have a certificate on the server that covers only, then connecting to will fail certificate validation. The client is expecting a certificate for One possible way of thinking of this is that the client doesn't have a way to know that the CNAME is genuine and isn't just created by a malicious attacker on the LAN. For example if you go to an Internet café, the wifi operator could create fake CNAMEs from pointing to and have a valid certificate for the latter name, yet that's not in fact the Gmail service.

To pass certificate validation, you'll need certificates that cover the names that the TLS clients actually use to access the services.

1 Like


As mentioned my servers host name is

The connection addresses are,, and

I read somewhere that because the first point of contact is the server the Cert should be the servers host name not the service names above.

But you are saying that the Cert should be *

If this is correct then it means we cant offer SSL with custom pop names. What I mean here is that in order to make it easy for clients we CNAME to ( Makes them feel special )

Thanks for your help


That's right.

Perhaps the person who wrote the documentation you read meant to say that the certificate needs to cover the server's hostname as configured in the mail client rather than the domain used for e-mail addresses. For instance, the user might receive e-mails at but if the server name that the user enters in the mail client is, the certificate should cover rather than This distinction should be drawn in effectively the opposite direction from the way you interpreted it, but it's still possible to describe it as "the cert should be the server's host name" (as opposed to the name after the @ in the end-user's e-mail address).

You could still offer this, but in order to do so you would have to issue certificates for these names yourself. You can actually do that, if you want, after the CNAME is in place because Let's Encrypt will allow you to issue certificate for names for which you are the target of a CNAME. For instance, if the customer does IN CNAME (or if you control the DNS and do this yourself), then you can issue a Let's Encrypt certificate for using a private key that you control! That certificate would then be accepted by the e-mail clients for a connection to

If this is a common configuration for you, it should be possible for you to script this so that it gets set up automatically—assuming that you don't mind the comparatively large number of certificate issuances. Since they relate to separate customer domains, it shouldn't create a problem for the Let's Encrypt rate limits.

I know this distinction might seem somewhat arbitrary to you, but it's effectively based on the idea that CNAMEs encountered in DNS are "believed" at certificate issuance time, but not at certificate verification time. That distinction is a little bit arbitrary but it sort of stems from an intuition that certificate authorities are better-equipped to detect and avoid DNS attacks than, for example, a user's mobile device connecting to a service from an Internet café. For various reasons the certificate authority "gets to" trust DNS more than the certificate verifier does, and therefore if you want the CNAME to be trusted in this process, you have to issue certificates referring to that name.

1 Like

Thank you Seth

I will re install the Cert with the correct name

Thanks for your help

Kind regards


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.