Troubleshooting Certificate Errors in Outlook Clients – Part 1

Written by Mike Rede on September 29, 2009

I’ve written about the use of certificates with Outlook in the past. Sometimes when using certificates with Outlook you will run into problems.

Remember that if you want to send and receive secure email then you will need to ensure that the email you send is private by using encryption. Let’s say you want to send a private email to someone and you want to make sure no one else can read it; if you know that your recipient’s public key then you can encrypt your mail message with their public key. To anyone without the recipient’s “private key” – for decryption – that message will look like a mass of unintelligible characters.

The receiver will use their own private key to decrypt the email so that the mass of unintelligible characters are now a readable message.

When using public keys the sender can make available their public keys to their intended receivers through various means like email, fax, etc. But how does a receiver know that the public key which they have received is indeed from the purported sender? How can we be really sure that the owner of a public key is who they say they are?

One method is to mutually rely on a trusted third party to verify the true ownership of a public key. Such a trusted third party is called a Certificate Authority (CA).

Certification Authorities are trusted entities that safely distribute public keys and sign public key certificates. A certificate always contains three pieces of information: a name, a public key and a digital signature computed over the name and the public key. The certificate associates a name with a public key.

But like I said earlier, there will be times that you, as an administrator, will be asked to troubleshoot a certificate problem in conjunction with Outlook.

One such problem you may encounter is when your Outlook 2007 POP3 or IMAP4 clients are using Transport Layer Security (TLS) and they receive a “Target Principal Name is Incorrect” certificate error when connecting to Small Business Server 2008.

You can configure Outlook 2007 to connect to Windows Small Business Server 2008 (SBS) by using either POP3 or IMAP4 with TLS.

Upon making a connection your users may get a certificate error such as: “The server you are connected to is using a security certificate that cannot be verified. The target principal name is incorrect. Do you want to continue using this server?”

You can continue to make the connection by clicking on “Yes”, but the next time you try to make a similar connection, after closing and reopening Outlook 2007, you will receive the same prompt.

If you were to take a look at the SBS 2008 self-signed certificate, specifically the Subject Alternative Name field, you would see that the first DNS name in the list does not match the server’s public Fully Qualified Domain Name (FQDN). Outlook 2007 reads this list and starts with the first DNS name on the list. It then tries to find a match with a POP, IMAP or SMTP server that it is connected to. If the two names do not match then the result is the error message you see listed above.

Outlook 2000 and Outlook 2003 do not produce this error.

This is where the Certificate Authority comes into play. You can run the “Add a trusted certificate” wizard to add a trusted third party certificate. Some well-known Certificate Authorities include VeriSign and Thawte. Although Thawte is owned and operated by VeriSign, Inc (Nasdaq: VRSN), after it was acquired in 2000, Thawte still continues to run as a distinct brand within VeriSign.

Keep in mind that before you run the “Add a trusted certificate” wizard that you must first run the “Internet Address Management” wizard and configure your external Fully Qualified Domain Name (FQDN).  Make sure you use the same name that you used when you requested the third party certificate.

Note that the “Internet Address Management” wizard will add “remote” as the prefix to the domain that you specify. So if you specify quantum.com as your domain name, then the wizard will assign remote.quantum.com as your external Fully Qualified Domain Name. If that’s the case, then remember to specify remote.quantum.com in your certificate request.

Subscribe to my RSS feed

Leave a Comment

Comment Policy