Link to home
Create AccountLog in
Avatar of awilderbeast
awilderbeastFlag for United Kingdom of Great Britain and Northern Ireland

asked on

SSL on exchange 2007 behind ISA 2006, the public cert works if we have public on ISA and private on exchange..!

Hi all,

We recently got a public SSL certificate for our exchange OWA/activesync setup. exchange 2007 behind isa 2006.

our public cert has the following:
Common Name: domain.co.uk
SANS:- mail.domain.co.uk, autodiscover.domain.co.uk,mail.bobsdomain.com, autodiscover.bobsdomain.com, exchange.domain.co.uk

so we installed the cert on exchange and isa correctly, they both see the cert fine.
then change our OWA listener on isa to the new public cert and then enable the thumbprint of the new cert on exchange.

mail.domain.co.uk works with the new cert, activesync however completely stops, server error on all mobiles and isa logs show authentication failure attempts to mail.domain.co.uk on our OWA rule

so we did a few tests, and we finished with the public cert on ISA and the private cert on exchange. and everything works!

this baffles me, shouldnt the public cert need to be used on the exchange server?
one thing i did think is that the common name on the public cert is domain.co.uk not mail.domain.co.uk, would that cause any issues?

thanks for any advice
ASKER CERTIFIED SOLUTION
Avatar of Bruno PACI
Bruno PACI
Flag of France image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Avatar of awilderbeast

ASKER

Thanks for this info.

whats confused me is when following guides (goddaddy ssl guides and digicert guides) after completing the request on the excahnge serrver it says to enable the certificate. which obviously sets this public cert as the cert for the exchange, are these guides referring to a public facing exchange do you think?
Yes, a lot of articles on the web propose to use the same certificate internally and externally. But these articles suppose that your internal AD domain name is the same as your external SMTP domain name... Of course this is the simplest situation for anyone that is not aware of DNS names, split DNS, TMG rules etc... only one name, no need to understand DNS principles...

But in this case your certificate must contains more names as I told you in my previous answer.
The more the names you have in the certificate, the more it is expensive. The more servers you install the certificate on, the more it is expensive.

So personnally I never preconize to use public certificates inside the enterprise to my customers. By the way, today there are more and more internal services that need SSL and certificates. Having your own internal certification authority is almost a requirement now, so I always propose to install a CA on a Windows server somewhere and avoid buying public certificates if it's not really needed.
Hmm, our internal domain is the same name as our external domain, would that of caused issues?

Thanks
No this is not a problem for OWA/ActiveSync publishing.

As soon as your TMG server is able to resolve internal DNS name of your CAS servers to an internal IP all is OK.

Having internal DNS name the same as external name will force you to create a split-dns configuration if your want your TMG/ISA to be a web proxy for internal computers, because in that case the TMG/ISA will have to resolve internal names to reach the domain and external names to reach external web sites.

If it's only about OWA/ActiveSync/OutlookAnywhere publishing your TMG server does not need to resolve external names and it can then only interrogate your internal DNS servers.
thanks for all this, so in future, you only need exchange to create the OWA/acticesync ssl cert then you just install it on ISA/TMG and it snot needed on exchange?

Thanks
If you use Exchange auto-signed certificates, at the installation time Exchange generates its own certificate but you'll have to regenerate a new one each time the certificate expires.

You'll then have to export this new auto-signed certificate and import it on the TMG server and put it in the "Trusted Root Certification Authorities" container of the local computer account. Nothing else to do.


If you plan to use internal CA authority, it's the root certificate of the CA that must be imported in the "Trusted Root Certification Authorities" on the TMG server.

A root certificate of a CA can expire after 10 years, while Exchange auto-signed certificates expires every 2 years (as far as I remember).
The rules for this changed when ISA went out of support and TMG took over. With ISA you had the option of tunneling therefore the certificate had to be on the Exchange Server. With TMG, tunneling is no longer an option and it only supports acting as the application gateway/reverse proxy.

Keith
thanks for all the info