Page 100 - Mercury Manual.book

95 Using SSL to secure connections
Enabling SSL support

you obtained the last time you connected to the server: if the fingerprints are different, this
indicates that the certificate has changed and that there may be a security issue. The point is
that provided you are confident you connected to the right server the first time you ever con-
nected to it via SSL (and hence got a valid fingerprint for the server), you have a basis for
detecting changes in the server's certificate fingerprint, and hence can detect potential secu-
rity breaches on all subsequent connections. This technique is not a good approach for things
like e-commerce sites, because you'll mostly only connect to them once or twice, so the risks
of certificate falsification are magnified, but it works quite well with mail protocols because
you tend to connect to the same small group of servers continuously, hence the change in fin-
gerprint is really the most significant issue. Pegasus Mail, Mercury's companion mail client,
supports fingerprint comparison on certificates: other mail clients may also do so.

To create a self-signed certificate in Mercury, type a filename into the Server Certificate
"filename" field in the SSL configuration page: this is the name of a file in which Mercury
can secure the certificate and its associated security information - any existing file by this
name will be overwritten when you create the new certificate.

Important note: If you have already created a self-signed certificate for one Mercury protocol
module, you can use that certificate in any other protocol module without having to create it
again. So, if you have already created a self-signed certificate for use in the MercuryI IMAP
server, you can simply type in its filename for both the MercuryP POP3 server and the Mer-
curyS SMTP server without having to create new ones. A self-signed certificate created by
Mercury can be used for any process running on the same machine - it certifies the hostname,
not the process.

Once you have entered the filename, simply click the Create... button in the SSL configura-
tion dialog. Mercury will open a dialog prompting you for the Internet domain name to be
associated with the certificate - the default value for this is the server's Internet domain name
as it has been entered in the Mercury Core Module configuration dialog: it is very important
that you enter the right domain name here, because some clients may refuse to accept the cer-
tificate if its associated domain name does not match the domain name they thought they
were connecting to. When you have entered the name, simply click Create and Mercury will
manufacture a suitable self-signed certificate for you and will store it in the filename you sup-
plied. Assuming no error occurs in certificate creation, you can now click the OK button to
save the configuration and Mercury can immediately begin accepting SSL connections -
that's all there is to it.

Even more important note: The file in which Mercury stores your certificate is not especially
secure; it is encrypted in a manner beyond the ability of almost anyone except the most de-
termined and experienced security expert, to crack, but it is conceivable that it could be
cracked. As a result, we do not recommend the use of Mercury's SSL services in environ-
ments where the physical system on which Mercury runs is not located in a secure location.

Step 3 involves deciding whether or not people should still be able to login to the server with-
out first establishing an SSL connection. Since the primary reason for using SSL is to prevent
usernames and passwords from being transmitted in a format that could be intercepted in tran-
sit, it makes little sense to allow people to login without securing the link first. The MercuryI
IMAP server and the MercuryP POP3 server allow you to check a control called Disable
plaintext logins for non-SSL connections: if this control is checked, these servers will not al-
low people to login unless they first establish an SSL connection. The conventional wisdom
on the Internet is that you should always enable this kind of refusal for unsecured logins, but
this may be impractical if you have some users running mail clients that do not support SSL.
We recommend strongly that you enable this option if you can do so practically.