------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=786
jwexler@??? changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jwexler@???
--- Comment #3 from jwexler@??? 2008-12-04 23:03:29 ---
> On 2008-12-03 15:00, Chris Edwards wrote:
> On Tue, 2 Dec 2008, jwexler@??? wrote:
>
> | Outlook appears to send the server certificate that I loaded in
> | Outlook's trusted center.
>
> That's very strange.
>
> Normally, a *server* certificate is sent from the server to the client, to
> help the client to authenticate the server.
>
> In some situations, the server requires the client to supply a *client*
> certifiate, to help the server authenticate the client. This seems to be
> what you're after. But as Andreas says, I've no idea if/how you can make
> outlook supply a *client* certificate.
>
> However, you mention outlook sending a *server* certificate. This sounds
> odd - there is no point in sending a server certificate *to* the server.
> Recall that the server certificate is essentially public. Anyone who can
> send packets to the server can trivially download it.
>
Thanks Chris.
I have also actually attempted the same test using a client certificate in
Outlook Trust Center with the same results.
This is the current configuration of certificates that I have:
01_CA_Certificate = CA certificate signing authority
02_Server_Certificate = Certificate signed by 01_CA_Certificate. This
certificate and its corresponding private key are located in /etc/exim4. This
is the certificate that MAIN_TLS_CERTIFICATE is assigned and
MAIN_TLS_PRIVATEKEY is assigned to its corresponding private key. (Note that
the certificate is also in /usr/share/ca-certificates and loaded into
/etc/ssl/certs/ca-certificats.crt per the instructions in exim4.conf.template.
I realize now from your post that the server certificate should not be there
but would guess does not affect the tls_verify_hosts issue.)
03_Client1_Certificate = Email sender/authenticator's client certificate. Test
user 1.
04_Client2_Certificate = Email recipient's client certificate. Test user 2.
This is also signed by 01_CA_Certificate.
Both client certificates (03_ and 04_) are signed by 01_CA_Certificate. Each of
the two client users were added to Outlook's address book and their
corresponding certificates (in .cer file format for the address book upload)
were uploaded and saved in the addresss book. Note that Outlook requires that
their certificates be in the address book before it allows signed and encrypted
email to be sent between the sender and recipient.
As mentioned above, I had initial attempted the authentication check via
tls_verify_hosts = * with 03_Client1_Certificate in Outlook's Trust Center.
(CASE A) I had gotten identical errors messages in Exim's mainlog. When I
commented out the tls_verify_hosts assignment, I had confirmed that the client
certificate was indeed within the received email.
Since tls_verify_hosts did not work with the sender's client certificate, I had
then proceeded to attempt sending the email by uploading 02_Server_Certificate
into Outlook's Trust Center and tried sending with that certificate (CASE B).
This yielded the same error as CASE A (and of course is not expected to work
given that it should be the client certificate that is sent as per your post).
Other settings: Exim was installed from daemon-heavy and thus appears to
perform TLS via GnuTLS rather than OpenSSL. The certificates that I have been
testing against recently were created via GnuTLS's certtool. TLS relaying is
performed on port 587. The Outlook client is on a network within
MAIN_RELAY_NETS which is required for authenticating.
CASE A is the intended functionality for tls_verify_hosts, correct? I would
guess that this is its intended purpose as it seems to offer equivalent
certificate authentication security functionality as in MS Exchange. I can't
imagine what other purpose would be for tls_verify_hosts than to verify client
certificates for authentication.
Is there any other info/test that I can provide to help determine whether this
is a legitimate bug?
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
