Exchange 2007/2010 - TLS
Hi Experts,
I've never really attempted to configure TLS on any of our customer Exchange servers before.
I've read this:
http://technet.microsoft.com/en-us/library/aa998840(v=exchg.141).aspx
But I'm a bit confused on what certificates are required.
We have multiple hub transport servers, sending and receiving emails to/from the Internet.
Are we able to enable TLS if there is a smart host in the way?
If we are sending from multiple hub transport servers, do we need a cert for each of these? or can these be covered by a single cert?
Any help is appreciated!
I've never really attempted to configure TLS on any of our customer Exchange servers before.
I've read this:
http://technet.microsoft.com/en-us/library/aa998840(v=exchg.141).aspx
But I'm a bit confused on what certificates are required.
We have multiple hub transport servers, sending and receiving emails to/from the Internet.
Are we able to enable TLS if there is a smart host in the way?
If we are sending from multiple hub transport servers, do we need a cert for each of these? or can these be covered by a single cert?
Any help is appreciated!
Asked:
Who is Participating?
we use TLS and enforce it for quite a few customers. We use Microsoft FOPE as service to do email filtering.
We enforce TLS between our edge servers and Microsoft so that are emails between use and the cloud are secure.
Between Microsoft specific customers we enforce TLS and if its fails then the email does not send. For other mail it can send eiher with or without i.e. opportunistic negotiation.
Depending ho how you have set up your certificates you can install the same cert on all hub/edge servers and make sure the FQDN connector matches the name in the cert.
If you have different FQDN's then you would need to include them all on one cert or have different certs attached the SMTP service
We enforce TLS between our edge servers and Microsoft so that are emails between use and the cloud are secure.
Between Microsoft specific customers we enforce TLS and if its fails then the email does not send. For other mail it can send eiher with or without i.e. opportunistic negotiation.
Depending ho how you have set up your certificates you can install the same cert on all hub/edge servers and make sure the FQDN connector matches the name in the cert.
If you have different FQDN's then you would need to include them all on one cert or have different certs attached the SMTP service
Thanks for the quick reply!
I was thinking of creating an additional send connector, locked down for that particular domain that would like to use encryption.
On a totally different note, Digital Signatures *could* be used to encrypt data between 2 particular users between 2 different Exchange Organizations right?
Thanks again!
I was thinking of creating an additional send connector, locked down for that particular domain that would like to use encryption.
On a totally different note, Digital Signatures *could* be used to encrypt data between 2 particular users between 2 different Exchange Organizations right?
Thanks again!
yes a scoped send connector would be the way to enforce TLS to a specific Domain
as far as i am aware digital signatures (within Exchange) can be used to sign emails but not encrypt them, this is using the Exchange Rights Management to do this which is a load of extra infrastructure an licensing. If you want to do user to user encryption then PGP is a good choice.
there is a PGP universal server which does gateway encryption which means it sits next to the exchange server and does the encryption there and removes the need to end user setup with software and encryption keys
as far as i am aware digital signatures (within Exchange) can be used to sign emails but not encrypt them, this is using the Exchange Rights Management to do this which is a load of extra infrastructure an licensing. If you want to do user to user encryption then PGP is a good choice.
there is a PGP universal server which does gateway encryption which means it sits next to the exchange server and does the encryption there and removes the need to end user setup with software and encryption keys
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
In Exchange 2007/2010 each server have its own self-signed certificate by default.
Exchanger servers inside the organisation ALWAYS use TLS between them.
Enabling TLS for external servers is probably a bit useless because I really doubt many external servers use it.
If you plan to enable TLS anyway on send connectors you should NEVER REQUIRE TLS ! You can enable it but do not require it !
Exchange servers inside the Exchange organization must authenticate each other and then use TLS certificate in that manner, added to the need of encryption.
As far as I know, using TLS with external servers is just for encryption and this will not be used for authentication. That means that you should not be forced to use publicly trusted certificates and you should be able to use your own self-signed and free certificates...
TLS with external servers is negociated and should stay negociated. It should never be required. So if servers are not able to use TLS they will use unencrypted SMTP.
The real question is why the hell to do want to encrypt dialogs with external servers ? This is not a security enforcement because you can not be sure that the message will still be encrypted on the next hop !
If you plan to encrypt messages so that they won't be read during the transfer to the destination you should encrypt the message body with S/MIME or any sort of PGP software. This is the only way to protect the mail content.
Have a good day.