Office365 Outlook "target principal name is incorrect" error with multi-domain cert

Screenshots of the Outlook errors

image001

image001

1 Like

Correct, they do. I can manually edit the various config files if needed, but macOS Server handles all of the certificate paths etc. in all of those places. Once the cert is installed in the system keychain, I can use the Server Admin GUI to tie that cert to the various services & websites. When that cert gets updated by certbot, serveradmin automatically updates all the config files with the new cert.

Good, I see similar for those 3.

But all 3 are sending the Self-signed ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) which they should not be doing.

1 Like

Please show the Certificate Path as well.

1 Like

What OS and version of the OS is that client running?

4 Likes

Also what does Outlook mean with "target principal name"?

1 Like

From various Outlook forums, the "target principal name" is the CN from the cert. So if Outlook is configured to hit mail.brazoslink.net but the CN is www.brazoslink.net (or brazoslink.net, as it is now), it's throwing a mismatch error. I can't find anyplace that Outlook ignores SANs, but that could be the issue; it doesn't surprise me at all when a Microsoft product doesn't exactly adhere to the standard.

Yeah, I found these 3 links

  1. https://www.purpledogdesign.com/clients/knowledgebase/110/Troubleshooting-Server-Incorrect-Message.html
  2. How to Fix Target Principal Name Is Incorrect Error in 2022
  3. The target principal name is incorrect - Microsoft Outlook - WinCert
1 Like

This is where Exact versions of the OS the client is running on and the Exact version of the Client are helpful.

1 Like

Still would be nice to have Certificate Path that Outlook see.

1 Like

Side note SSL Server Test (Powered by Qualys SSL Labs) shows another certificate and chain
Certificate #2: RSA 2048 bits (SHA256withRSA)


Does Outlook see that as well?

1 Like

User says, "Outlook for Windows(C2R) v16.0.15726.20174 in the Office 365 suite."

1 Like

I don't think it sees that, the only place I see it is in the Qualys report. Apache is using SNI to serve multiple SSL-encrypted sites from a single IP, so apparently Qualys is doing something with its requests that doesn't follow the SNI browser protocols.

1 Like

SSLLabs does both: with and without SNI.

3 Likes

Working on this...

1 Like

Thanks! :slight_smile:

1 Like

Here are 3 more links on Chains:

2 Likes

Am I looking at using the certbot --preferred-chain option when creating/updating certs, or the openssl -trusted-first option when exporting a PKCS12 file from the LE cert?

I'm scratching my head trying to figure out where the "extra" root is coming from. Is it included in the LE cert, or is my system adding it during the openssl export?

it is not.

I don't think OpenSSL, with the command you've posted earlier, would do that as you're only using the files provided by Certbot. And they don't include the root cert.

3 Likes