Certificate on Exchange 2003

I have installed a certificate on our Exchange server (previously it used clear text) and I am going to change the IIS settings to require SSL. Are there anly things I should watch out for when I do this? Every Exchange Server I have ever setup I have required SSL from the start, so this is new to me.

We use BES, not sure if that matters...

Thanks!

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

paintb4707

RobertKaucher wrote: »

I have installed a certificate on our Exchange server (previously it used clear text) and I am going to change the IIS settings to require SSL. Are there anly things I should watch out for when I do this? Every Exchange Server I have ever setup I have required SSL from the start, so this is new to me.

We use BES, not sure if that matters...

Thanks!

You mentioned requiring SSL but you didn't say where. On the OWA page? POP3? SMTP?

RobertKaucher

Oh, sorry. The only people who access the site outside the company, other than the BlackBerry users, use OWA. So only on the OWA site.

What is SOP in this situation? Should I also require it for POP/IMAP/SMTP/etc?

Claymoore

As long as you associate the certificate with the webmail IIS site in IIS Admin, you should be fine. Make sure your users update their favorites to HTTPS

/webmail.company.com/exchange if they have only been using http thus far and you change the site to require SSL.

If you aren't using POP/IMAP then disable them. If you are, you can use the certificate with them. I had to do this with IMAP before the iPhone supported ActiveSync.

You can also use the certificate for SMTP and use TLS, but TLS is a little different in Ex2k3. First, you will need to change the masquerade domain of the SMTP connector to match the certificate name. For example - your mx record or servername is mail.company.com but your certificate is for webmail.company.com - change the masqurade domain to webmail.company.com and your server can start using TLS if it is supported in the remote domain. Most hosted mail providers support opportunistic TLS as well as Exchange 2007, but for others you made need to define a separate IP address and SMTP connector for your Exchange server that requires TLS. You can then define the connector based on DNS namespace to both sign and encrypt the mail to those destinations. Just be sure to check the message headers to make sure they are being encrypted.

paintb4707

Claymoore wrote: »

As long as you associate the certificate with the webmail IIS site in IIS Admin, you should be fine. Make sure your users update their favorites to HTTPS/webmail.company.com/exchange if they have only been using http thus far and you change the site to require SSL.

If you aren't using POP/IMAP then disable them. If you are, you can use the certificate with them. I had to do this with IMAP before the iPhone supported ActiveSync.

You can also use the certificate for SMTP and use TLS, but TLS is a little different in Ex2k3. First, you will need to change the masquerade domain of the SMTP connector to match the certificate name. For example - your mx record or servername is mail.company.com but your certificate is for webmail.company.com - change the masqurade domain to webmail.company.com and your server can start using TLS if it is supported in the remote domain. Most hosted mail providers support opportunistic TLS as well as Exchange 2007, but for others you made need to define a separate IP address and SMTP connector for your Exchange server that requires TLS. You can then define the connector based on DNS namespace to both sign and encrypt the mail to those destinations. Just be sure to check the message headers to make sure they are being encrypted.

For SMTPSSL, doesn't your senders also require their own certificate in order to send/receive an email to your organization? I thought there was a lot more involved with encrypting SMTP.

Or maybe it was just that every user in the organization needed their own certificate... hmm...

blargoe

BES uses MAPI to connect to Exchange so that shouldn't be affected.

Are you using POP or IMAP at all? You can secure those with SSL pretty easily if it's not a problem for all of the clients to be reconfigured to use those over SSL.

SMTP... if you're using TLS the other server would have to have a TLS cert that your server trusts and vice versa. If this Exchange server is the Internet MX for the domain (and not an outside filtering service), and you want to be able to receive from anyone on the Internet, you have to allow for plain old SMTP without TLS and not require it for all SMTP. I haven't set it up on 2003 so I don't know the particulars there.

Claymoore

paintb4707 wrote: »

For SMTPSSL, doesn't your senders also require their own certificate in order to send/receive an email to your organization? I thought there was a lot more involved with encrypting SMTP.

Or maybe it was just that every user in the organization needed their own certificate... hmm...

TLS encrypts the transmission of the email - not the email itself. Each user would need their own certificate to encrypt individual emails (transport rules can encrypt individual emails in 2010 using a server certificate). Both the sending and receiving server need certificates, and there is a difference between opportunistic TLS and enforced TLS.

For enforced TLS, you would need to create a separate TLS SMTP virtual server using an additional IP address. Plus you would need additional RGC to route messages to that virtual server, usually by domain name. This enforces TLS encryption on that connection to a partner organization.

The problem with this is that everyone will send to your default SMTP virtual server instead of the TLS virtual server. If you install a certifcate on that default virtual server to support inbound TLS, you will need to make sure that the masquerade domain matches the name on the certificate.

Once I installed the certificate on the default virtual server at a previous employer and began monitoring the SMTP logs to verify the STARTTLS command was working, I noticed TLS connections from many different servers. It turns out many of our partners were using mail servers or hosting services that supported opportunistic TLS - they were asking to use TLS and would use it if the other server supported it, but otherwise they would transmit unencrypted. After identifying the partners, I added their domains to the TLS routing group connector and mail to them was sent through our TLS enabled virtual server. Now mail transmission was encrypted in both directions.

2007 supports opportunistic TLS and will try to encrypt the mail transmission if the remote server supports it, without the need for a separate virtual server. You still need valid certificates, but the only reason to create a separate send connector is if you want to sign and encrypt the mail. Outlook 2007 with then display an additional message at the top of the email stating it was received from a trusted source.

2010 adds the ability to encrypt individual messages using transport rules. You could inspect the mail and, using a regular expression to look for a social security or account number pattern, encrypt the mail message itself rather than just the transmission.

RobertKaucher

Thanks again, y'all!!

paintb4707

Claymoore wrote: »

TLS encrypts the transmission of the email - not the email itself. Each user would need their own certificate to encrypt individual emails (transport rules can encrypt individual emails in 2010 using a server certificate). Both the sending and receiving server need certificates, and there is a difference between opportunistic TLS and enforced TLS.

For enforced TLS, you would need to create a separate TLS SMTP virtual server using an additional IP address. Plus you would need additional RGC to route messages to that virtual server, usually by domain name. This enforces TLS encryption on that connection to a partner organization.

The problem with this is that everyone will send to your default SMTP virtual server instead of the TLS virtual server. If you install a certifcate on that default virtual server to support inbound TLS, you will need to make sure that the masquerade domain matches the name on the certificate.

Once I installed the certificate on the default virtual server at a previous employer and began monitoring the SMTP logs to verify the STARTTLS command was working, I noticed TLS connections from many different servers. It turns out many of our partners were using mail servers or hosting services that supported opportunistic TLS - they were asking to use TLS and would use it if the other server supported it, but otherwise they would transmit unencrypted. After identifying the partners, I added their domains to the TLS routing group connector and mail to them was sent through our TLS enabled virtual server. Now mail transmission was encrypted in both directions.

2007 supports opportunistic TLS and will try to encrypt the mail transmission if the remote server supports it, without the need for a separate virtual server. You still need valid certificates, but the only reason to create a separate send connector is if you want to sign and encrypt the mail. Outlook 2007 with then display an additional message at the top of the email stating it was received from a trusted source.

2010 adds the ability to encrypt individual messages using transport rules. You could inspect the mail and, using a regular expression to look for a social security or account number pattern, encrypt the mail message itself rather than just the transmission.

Thanks for clearing that up