A secure connection cannot be established with the server <domain.com> because its intermediate or root certificate cannot be found. Do you want to continue?
If you continue, the information that you view and send will be encrypted, but will not be secure.
Microsoft has a suggestion for fixing this, issue a new certificate with the domain added as a SAN (subject alternative name) or just accept the wrong cert. But I bet you actually have a certificate for the domain name you have Office 365 or Exchange setup on, so why not use it? Here’s how.
- You need to track down where the domain is pointing to determine where the certificate needs to be installed. You may or may not know this, and I understand because like many of you I am a sys admin that takes over control of already existing systems. Just ping the domain name in the certificate warning (the <domain.com> bit, replace that with the domain in your warning). That will give you an IP, now track that IP to whatever web server, load balancer, or firewall it may be.
- Get your certificate ready. I work with Microsoft and IIS nearly exclusively so I have a handy PFX (certificate + private key, don’t let this out of your sight). Simply install that certificate to wherever that IP address is terminating. When Outlook resolves the domain name it will try and pull the cert from that device/server.
In my case the server was a reverse proxy load balancer, running ARR, IIS, and network load balancer. With ARR I have SSL offloading enabled so the certificate actually comes from this load balancer, not the web server. I added a binding to the site in IIS with the cert and the warning went away.