Hi guys

It seems the certificate I've got installed is having some issues. Details regarding the cert:

3rd party SSL, consisting of mail.domain.com and autodiscover.domain.com.

Exchange was working flawlessly, when at one point access to both OWA and outlook clients is inaccessible.

OWA shows page can't be displayed and outlook clients has no connection.

The only way I can access OWA is internally through the Exchange server internal IP/owa or FQDN/owa. The way it did work with mail.domain.com/owa is not successful.

My theory points to certificate having issues, as all virtual directories are unchanged and relevant URLs have been verified.

Any advise or suggestions as to why this would occur would be appreciated.

As a last option, should I remove the current cert or disable it of some sort, and re-apply? If so, what would be best practise to replace or change the current certificate that's dependant on the transport service?

Regards

Did you recently renew your expired 3rd party certificate ?

After renewing your expired certificate you must import it and then enable the certificate on the Default Web site
Then run the below command to enable  new the certificate and replace the old one
Enable-ExchangeCertificate -thumbprint <copied thumbprint value> -services IIS,IMAP,POP,SMTP

Also replace the old certificate in your reverse proxy with the newly replaced one and see the re

Hi guys

It seems the certificate I've got installed is having some issues. Details regarding the cert:

3rd party SSL, consisting of mail.domain.com and autodiscover.domain.com.

Exchange was working flawlessly, when at one point access to both OWA and outlook clients is inaccessible.

OWA shows page can't be displayed and outlook clients has no connection.

The only way I can access OWA is internally through the Exchange server internal IP/owa or FQDN/owa. The way it did work with mail.domain.com/owa is not successful.

My theory points to certificate having issues, as all virtual directories are unchanged and relevant URLs have been verified.

Any advise or suggestions as to why this would occur would be appreciated.

As a last option, should I remove the current cert or disable it of some sort, and re-apply? If so, what would be best practise to replace or change the current certificate that's dependant on the transport service?

Regards

If there was a problem with the certificate you would get a certificate error when connecting to the name (just like you are getting when you connect via IP).  There's got to be something funky with DNS or something else going on.  What version of Exchange?

Hi Sathish

It is a new Exchange installation, and the 3rd party certificate has only been configured last week, valid for 2 years.

Thus, no clear indication that there was tampered with in my opinion.

That might be possible, but nothing DNS private or publically changed.

Exchange 2013 Std. Standalone server

How did you renew your Exchange certificate?

Did you go through IIS or through the EAC?

Validate your virtual directory URLs are correct as well.

Hi

It was not renewed, first cert on a new Exchange organisation setup. This was done through EAC, and worked for a week, now I'm sitting with these roadblocks.

I've double checked all virtual directories, seems to be in order.

Hi

It was not renewed, first cert on a new Exchange organisation setup. This was done through EAC, and worked for a week, now I'm sitting with these roadblocks.

I've double checked all virtual directories, seems to be in order.

Are you running in coexistence with any other version of Exchange?  Can you test name resolution for your namespace with both nslookup and ping -a

Also make sure you check all your dns servers when you use nslookup something can't be resolving corr

Negative, as mentioned above, standalone server.

Seems like all name resolutions resolves perfectly. DNS servers checked and all entries prior to this issue still in tact.

Negative, as mentioned above, standalone server.

Seems like all name resolutions resolves perfectly. DNS servers checked and all entries prior to this issue still in tact.

If you can access everything with either the server name or the IP of the machine, but not by mail.domain.com it almost certainly has to be name resolution.  If it's not name resolution, what else is between your workstations and exchange?

That's what I've read also on other threads, that is points towards name resolution.

The only thing that changed, and to answer your question, is that Mimecast came in to play. We have a separate company handling this, and recent changes were made that Mimecast points to the Exchange server for mail flow.

Could it be something on Mimecast influencing this?

Edit, this company I referred to also handles the firewall rules.

• Edited by Techn101 10 hours 54 minutes ago

That's what I've read also on other threads, that is points towards name resolution.

The only thing that changed, and to answer your question, is that Mimecast came in to play. We have a separate company handling this, and recent changes were made that Mimecast points to the Exchange server for mail flow.

Could it be something on Mimecast influencing this?

Edit, this company I referred to also handles the firewall rules.

• Edited by Techn101 Tuesday, July 14, 2015 8:34 PM

Hi,

If your certificate is working fine, and you have no changes for DNS records,

maybe Mimecast has some influences on OWA .

I suggest you can do the troubleshooting about it.

Regards,

David

Hi David

Seems like it had to something with the firewall, NAT-ing to be more specific.

Seeing that I don't have access to the firewall, I assume someone changed something and changed it back.

Needless to say, as I suspected everything on Exchange is correct.

Regards

Seems like it had to something with the firewall, NAT-ing to be more specific.

Seeing that I don't have access to the firewall, I assume someone changed something and changed it back.

Needless to say, as I suspected everything on Exchange is correct.

Regards