My domain is:*.irhost.co.za
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.
Hi,
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 darwin.irhost.co.za
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 foo.example.org IN CNAME bar.example.com and I have a certificate on the server that covers only bar.example.com, then connecting to https://foo.example.org/ will fail certificate validation. The client is expecting a certificate for foo.example.org. 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 mail.google.com pointing to myinternetcafe.example.com 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.
Hi
As mentioned my servers host name is darwin.irhost.co.za
The connection addresses are pop.ourhostname.co.za, smtp.ourhostname.co.za, imap.ourhostname.co.za and webmail.ourhostname.co.za
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 *.ourhostname.co.za
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 pop.clientname.co.za to pop.ourhostname.co.za ( Makes them feel special )
Thanks for your help
Lionel
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 username@ourhostname.co.za but if the server name that the user enters in the mail client is darwin.irhost.co.za, the certificate should cover darwin.irhost.co.za rather than ourhostname.co.za. 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 pop.clientname.co.za IN CNAME popourhostname.co.za (or if you control the DNS and do this yourself), then you can issue a Let's Encrypt certificate for pop.clientname.co.za using a private key that you control! That certificate would then be accepted by the e-mail clients for a connection to pop.clientname.co.za.
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.
Thank you Seth
I will re install the Cert with the correct name
Thanks for your help
Kind regards
Lionel
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
