Verify fail

Please can someone advise us what is reequired for verify to work and what
is its importance?

We have tried everything we can think of and tried to follow the Bat Book
but we ccan't get it to work. We have also obtained and installed a Verisign
certificate.

Here is our access file:
Try_TLS:localhost NO
Try_TLS:127.0.0.1 NO
Try_TLS:10.130.148.40 NO
TLS_Srv:10.130.148.40 ENCR:0
# TLS_Srv:millcorner.ath.cx ENCR:128
TLS_Srv:connexions-leics.org ENCR:128
TLS_SRV: ENCR:128
TLS_Clt:10.130.148.40 ENCR:0
# TLS_Clt:millcorner.ath.cx ENCR:128
TLS_Clt:connexions-leics.org ENCR:128
TLS_Clt: ENCR:128

CERTISSUER:/C=UK/ST=England/L=Leicester/O=Leicester+20City+2 0Council/OU=Info
rmation/CN=itssecmail01.leicester.gov.uk/emailAddress=it.sup port.centre@leic
ester.gov.uk RELAY

To:leicester.gov.uk RELAY
Connect:mail-relay1.leicester.gov.uk RELAY
Connect:localhost OK
127.0.0.1 RELAY
10.130.148.40 RELAY

The Try_TLS lines didn't seem to work but we were able to get around this by
using the ENCR:0 line.

Here is our certs config:
define(`confCACERT_PATH', `/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/cacert.pem')dnl
define(`confSERVER_CERT', `/etc/mail/certs/cert.pem')dnl
define(`confSERVER_KEY', `/etc/mail/certs/key.pem')dnl
define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem')dnl
define(`confCLIENT_KEY', `/etc/mail/certs/key.pem')dnl
define(`confSMTP_LOGIN_MSG', `LCC_Secure_eMail gateway')dnl

We created a certificate request using Openssl and installed the certificate
in the cert.pem file.

Re: Verify fail

John Chajecki unleashed the infinite monkeys on 10/04/2008 10:52 producing:
> Please can someone advise us what is reequired for verify to work and what
> is its importance?
>
> We have tried everything we can think of and tried to follow the Bat Book
> but we ccan't get it to work. We have also obtained and installed a Verisign
> certificate.

It isn't critical (AFAIK). The fact that it isn't verifying simply
means that the certificate wasn't issued by a party the others trust.
You've checked that the keys in cert.pem and key.pem are the Verisign ones?

--
Rob MacGregor (BOFH)

Rule 37: "There is no 'overkill'. There is only 'open fire'
and 'I need to reload.'"

Re: Verify fail

In article <47FDF15F.FFB7.0000.0@group.dsl.pipex.com>,
"John Chajecki" wrote:

> Please can someone advise us what is reequired for verify to work

TLS 'verify' will work if the client presents a certificate with a
signature chain that leads back to a CA certificate that you trust.

Read http://www.sendmail.org/~ca/email/starttls.html carefully.

You need to install (as described on that page) any CA certs necessary
to verify the signatures on any certs presented to you by TLS partners
that you need to verify. This means that if you or a partner use
self-signed certs, you need to put them (or links to them) there.

> and what
> is its importance?

If you need certainty that the host you are talking to is the host it
claims to be, requiring successful TLS verification is your only choice.
Verification tells you that there has been no network and/or DNS hijack
allowing an impostor to look like the host you think you are talking to.

Cases where requiring verification makes sense are rather uncommon. If
you use a self-signed cert verification will fail with any partner that
has not been given your cert as one they must trust. If you trust the
DNS and routing between your host and a partner, there's no reason to
demand verification.

> We have tried everything we can think of and tried to follow the Bat Book
> but we ccan't get it to work. We have also obtained and installed a Verisign
> certificate.

You may find these useful as well:

http://www.sendmail.org/~gshapiro/security.pdf
http://www.sendmail.org/m4/starttls.html
http://www.sendmail.org/doc/sendmail-current/doc/op/op.pdf

> Here is our access file:
> Try_TLS:localhost NO
> Try_TLS:127.0.0.1 NO
> Try_TLS:10.130.148.40 NO
> TLS_Srv:10.130.148.40 ENCR:0
> # TLS_Srv:millcorner.ath.cx ENCR:128
> TLS_Srv:connexions-leics.org ENCR:128
> TLS_SRV: ENCR:128
> TLS_Clt:10.130.148.40 ENCR:0
> # TLS_Clt:millcorner.ath.cx ENCR:128
> TLS_Clt:connexions-leics.org ENCR:128
> TLS_Clt: ENCR:128
>
> CERTISSUER:/C=UK/ST=England/L=Leicester/O=Leicester+20City+2 0Council/OU=Info
> rmation/CN=itssecmail01.leicester.gov.uk/emailAddress=it.sup port.centre@leic
> ester.gov.uk RELAY
>
> To:leicester.gov.uk RELAY
> Connect:mail-relay1.leicester.gov.uk RELAY
> Connect:localhost OK
> 127.0.0.1 RELAY
> 10.130.148.40 RELAY
>
> The Try_TLS lines didn't seem to work but we were able to get around this by
> using the ENCR:0 line.

That's odd...

In what way did they not work?

> Here is our certs config:
> define(`confCACERT_PATH', `/etc/mail/certs/')dnl
> define(`confCACERT', `/etc/mail/certs/cacert.pem')dnl
> define(`confSERVER_CERT', `/etc/mail/certs/cert.pem')dnl
> define(`confSERVER_KEY', `/etc/mail/certs/key.pem')dnl
> define(`confCLIENT_CERT', `/etc/mail/certs/cert.pem')dnl
> define(`confCLIENT_KEY', `/etc/mail/certs/key.pem')dnl
> define(`confSMTP_LOGIN_MSG', `LCC_Secure_eMail gateway')dnl
>
> We created a certificate request using Openssl and installed the certificate
> in the cert.pem file.

You also need it (or the local CA signing cert) in
/etc/mail/certs/cacert.pem and any other CA certs you trust linked in
/etc/mail/certs/

--
Now where did I hide that website...

Re: Verify fail

Bill,

Thanks for the links. The first one was very helpfull and I have been able
to make some progress. By following the guidelines and creating a hash to
the remote MTA (self signed) CA certificate I have been able to get
verify=OK for the remote MTA. However the remote MTA still fails to verify
my Verisign certificate.

I placed the CA root in cacert.pem (there are in fact 3 of them class 1,
class 2 and class3. This should presumably provide the certificate chain to
verify the server certificate issued by Verisign in cert.pem but at present
it doesn't. I tried the certificate hash thing as well on the remote MTA but
that made no difference. If I'm reading it right, it shouldn't be necessary
anyway.

In the situation I am working with, I do need to verify that the host I am
talking to is in fact the host it purports to be and opnly this host should
be allowed to communicate with my MTA. At the moment for testing purposes
I'm just using ENCR rather than VRFY in the access table, but once I've got
the verification working properly, I intend to switch it to VRFY.

Re: Verify fail

In article <47FF5243.FFB7.0000.0@group.dsl.pipex.com>,
"John Chajecki" wrote:

> Bill,
>
> Thanks for the links. The first one was very helpfull and I have been able
> to make some progress. By following the guidelines and creating a hash to
> the remote MTA (self signed) CA certificate I have been able to get
> verify=OK for the remote MTA. However the remote MTA still fails to verify
> my Verisign certificate.
>
> I placed the CA root in cacert.pem (there are in fact 3 of them class 1,
> class 2 and class3. This should presumably provide the certificate chain to
> verify the server certificate issued by Verisign in cert.pem but at present
> it doesn't. I tried the certificate hash thing as well on the remote MTA but
> that made no difference. If I'm reading it right, it shouldn't be necessary
> anyway.

If the remote MTA is using openssl, I'm pretty sure that hash format is
necessary.

The best tool for figuring out this sort of problem is the openssl
s_client command. 'man s_client' ought to explain it on any machine with
openssl installed and a working man system. It lets you specify cert
locations, supports the STARTTLS protocol for SMTP, and has a rich set
of options for tracing the progress of a TLS session.

> In the situation I am working with, I do need to verify that the host I am
> talking to is in fact the host it purports to be and opnly this host should
> be allowed to communicate with my MTA. At the moment for testing purposes
> I'm just using ENCR rather than VRFY in the access table, but once I've got
> the verification working properly, I intend to switch it to VRFY.

I only mentioned that it was a rare need because there is a history here
(and on postfix-users) of people seeking to require verification simply
because it is 'more secure' without understanding the feasibility of
doing so broadly or what verification is really worth in a particular
case.

--
Now where did I hide that website...