Blog Entry

aevans's picture

Securing your agents, Part II

Author Info

1 August 2007 - 8:00am
Submitted by: aevans

Tags

blog
Reads:

904

Score:
0
0
 
Comments:

1

As most of you know all the traffic between GW agents and between the client and the POA is already encrypted using a proprietary encryption method. There are some verticals that require a particular standard of encryption and this is where encrypting using SSL certificates come into play. In my last post I covered securing the HTTP interface of your agents. If you followed that you have actually done most of the groundwork for securing all the other protocols too.

Read on:

I am not going to cover creating the certificates and key files again, or installing them - check out my last post for that. What I am going to show you here is how to enable it on the other protocols (and the observant amongst you will notice that I am running Bonsai snapins - so all disclaimers regarding 'content may not reflect reality' apply here.)

Well, it's really easy once you have got the certificate and key installed and working. The easiest way to check it's working is to make sure that the HTTPS interface works. If so then just go and enable SSL for the other protocols:

MTA
mtaddress.jpg
POA

poaaddress.jpg

From the POA screenshot you can see that I have set Internal Client/Server and IMAP to 'Enabled', instead of 'Required'. I just wanted to point out that those 2 had an additional option and to explain the difference. Required on the protocol means that if the other side of the link does not support SSL then communication attempts will fail. Enabled means that if the client can do SSL then it will, otherwise the POA will still allow regular communications. It is also worth noting that SSL does not replace the GW encryption, it is just wrapping the already encrypted GW packet in an SSL wrapper.

If you get this set up correctly then you will see a padlock icon in the client to signify that is communicating over SSL:

padlock.jpg

Doing this you can secure all protocols that GroupWise uses.  Currently the only place that you can't secure with SSL, though it is still encrypted, is the link between the WebAccess Application and the WebAccess Agent.

I think that's it - the next post will cover client certificates, mail signing and mail encryption.


Author Info

1 August 2007 - 8:00am
Submitted by: aevans

Tags




User Comments

When can we expect part III:

Submitted by Peter (not verified) on 5 November 2007 - 7:26am.

When can we expect part III: "the next post will cover client certificates, mail signing and mail encryption"?

© 2009 Novell, Inc. All Rights Reserved.