Heiko Hilscher wrote:
Hallo Heiko,
Post by Heiko HilscherKann mir jemand einen Tip geben. Unser Kunde möchte auf keinen Fall
auf seinen Mercury verzichten.
Ich denke, das sollte eigentlich weiter helfen:
----- Auszug aus der Mercury-Hilfe -----
Secure connections using SSL/TLS
Mercury/32 has comprehensive support for secure connections using the
Internet SSL/TLS protocols. "SSL" (Secure Sockets Layer) and "TLS"
(Transport Layer Security) are standards for transferring data across
Internet connections in an encrypted format to ensure security. Pegasus
Mail supports both SSL and TLS so from this point on we'll use the term
"SSL" to mean both. The way these protocols are implemented means that a
client and a server can negotiate an encrypted transaction in a way that
prevents the data from being intercepted in transit even if the intruder
can see the entire session.
There are three steps to enabling support for SSL in a Mercury/32
protocol module:
Step 1: Enable advertising of the protocol
Step 2: Install a certificate the server can offer to clients connecting
via SSL
Step 3: [Optional] Decide whether you will allow users to login without
using SSL.
Step 1 is easy: in the configuration dialog for the protocol module,
switch to the page called "SSL" and check the control labelled Enable
support for SSL/TLS secure connections. This tells Mercury that it can
advertise the availability of SSL services to clients when they connect
to it. If you do not enable this control then the protocol module will
neither advertise the availability of SSL services, nor will it accept
attempts to establish SSL connections.
Step 2 is also easy in Mercury, but it needs a little explanation. When
an SSL connection is established, the server is required to supply a
certificate to the client: a certificate is a specially formatted piece
of data that is intended to prove that the server is in fact who it
claims to be: the server is required to provide a certificate even if
the proof of identity is not particularly important. You can obtain
certificates from a Certification Authority, such as Thawte or Verisign,
but the process is complicated and expensive: what's more, for SSL
connections to mail servers, the proof of identity that a Certification
Authority Certificate provides is typically not as important as
encrypting the data in transit. For this reason, Mercury also allows you
to create a special type of certificate called a self-signed
certificate.
A self-signed certificate basically says to the client "This is my name,
and you can trust me"; now, you don't have to think about this for very
long to realize that this isn't very secure, but there's another aspect
of certificates that compensates for this: every certificate, even a
self-signed one, has a unique attribute represented by a calculation
called a fingerprint which is essentially impossible to forge. As a
result, you can get excellent security even when using a self-signed
certificate by comparing the certificate's fingerprint with the
fingerprint 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 connected 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 security
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 fingerprint 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 MercuryS SMTP server without having to create new ones.
Once you have entered the filename, simply click the Create... button in
the SSL configuration 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 certificate 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 supplied. 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 determined 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 environments 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 without 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 transit,
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 allow
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.
------------------------------------------------------------------
Kompetente Antworten zu Deinem Problem sind auch in
de.comm.software.mailserver
zu erwarten. :-)
Gruß
Stefan