Untrusted cert in OUTLOOK 2013 under WINDOWS 10

Hello: I use Outlook 2013 under Windows 10, whit several accounts, some of them with Comodo signing cert. When I send mails from anyone of them, they are received with warning that the signature is invalid and that the contents could have been modified. This does not happen with Mozilla Thunderbird. ¿Are you aware of this problem and why it occurs and how it can be solved ?. The same problem occurs with StartCom certificates. Thank You.


One quick question… Is the sending account email address ‘exactly’ the same as the email address in the certificate?

ie the sending account email address is me@this.com and the certificate is for me@this.com

As opposed to the account being for me.too@this.com and the certificate is for me@this.com or visa versa.

It’s a common mistake, but one that gives the error you mentioned.


Hello SSL Guru,
Shouldn’t the cert cover the domain and if used the subdomain of the mail server?

You said " Is the sending account email address ‘exactly’ the same as the email address in the certificate?
ie the sending account email address is me[at]this.com and the certificate is for me[at]this.com
As opposed to the account being for me.too[at]this.com and the certificate is for me[at]this.com or visa versa."

In your examples, anything before the [at] is in the local part of the email address.
I used to go to the RFCs, but Wiki has a pretty good description of the format of an email address at https://en.wikipedia.org/wiki/Email_address:
“An email address such as John.Smith[at]example.com is made up of a local part, an @ symbol, then a case-insensitive domain part…
The general format of an email address is localpart@domain, and a specific example is jsmith[at]example.org. An address consists of two parts. The part before the @ sign (localpart) identifies the name of a mailbox. This is often the username of the recipient, e.g., jsmith. The part after the @ symbol is a domain name that represents the administrative realm for the mail box, e.g., a company’s domain name, example.com.”

To my knowledge, SSL certificates help validate domains and subdomains. If we had to get an SSL certificate for each email user’s account, which you are suggesting in your reply, that sure would be difficult to manage - and the cost!!! Just think - HR asks IT to set up an email account for a new employee and IT responds ‘We’ll get that set up for you asap - it’ll take a couple of days to get the SSL certificate.’ And HR adds, 'Oh, and can you change John T’s address to john.t[at]example.com, and IT says ‘We’ll get that done as soon as we get John’s SSL certificate reissued to cover the name change.’

The VPS server that my company uses for the domains we own and manage has a server name whose format follows the domain naming guidelines (which is discussed in the same wiki referenced above as to email address formatting) and which looks like a subdomain name. We had our hosting service install a services SSL certificate on the server and they told us to use the server name instead of mail.[domain name] in our email client account setup so the email SSL connection will match against the name used in the services certificate.

That is one possibility and perhaps something that Guirala might look at.

Outside of that, we have a problem with Outlook 13 on our company’s Apple computers, as well as appears on IOS devices. I hadn’t seen this forum, but the issue is detailed in two responses in the forum/post “The Comodo Forum > Business / Enterprise Security Products & Services > Digital Certificates > SSL Certificate > SSL root certificate not trusted?”. We recently had a new SSL certificate installed and were getting a message that the SSL Root certification authority was not trusted.

I found that COMODO did have a root certification authority in the Apple computer’s keychain, but the Serial Number and expire date are different than that of the new certificate we received. Adding the new root certificate to my computer and that of our other employees takes care of that part of the problem, but then we can’t ask everyone else around the world who uses an Apple device to do that. Well, perhaps we could by adding a notice on our sites that we have a COMODO SSL certificate and we found that the root certificate is not included in Apple device keychains and if they would like to visit our site without getting messages that the site cannot be trusted that they too should add the root certificate to their keychain.

As I said, it is detailed in the post referenced above. The initial post was entered on August 25, 2015, 04:50:54 AM by lennertk and no COMODO or other moderator has responded to the post.

Since Guirala mentions Outlook 2013, though under Windows 10, and since we saw the problem in Outlook 2013 on the Mac, it makes me wonder if perhaps it might also be a root certificate problem. Guirala says it doesn’t happen with Mozilla Thunderbird, but then I understand that Firefox uses its own root certificate library, and since they are both through Mozilla, perhaps they both use similar mechanisms.



An SSL certificate is for a domain and an email certificate is for use with email addresses, so I’m wondering if one is being confused with the other?


Hello SSL Guru,
Good question - re-reading the original question Guirala did say signing cert.

I apologize -

Our Outlook problem is related to the SSL cert for our domain and causes images whose source scheme is https not to display so people receiving our newsletter and using the Mac Outlook client don’t see the images. Looking into connections to the images in Safari gives a warning about not being able to trust the COMODO root certification authority so we believe the two are tied especially since adding the SSL cert to the keychain cleared our problem.

Thanks for your clarification.