Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Self-Signed server cert failing verification in Postfix

473 views

Skip to first unread message

Jim Garrison

unread,

Jun 21, 2004, 10:45:42 PM6/21/04

First of all, please forgive me if this is the wrong list. I'm having
a problem using TLS (OpenSSL-based) in Postfix and the problem might
be in OpenSSL, or how Postfix uses OpenSSL.

Postfix is running on an internal network, using an external relay
host for all outgoing mail. The connection to the relay host requires
TLS, and the relay host uses this *self-signed* certificate.

The problem is that Postfix refuses to proceed because it cannot
verify this self-signed cert.

According to everything I can find in the archives, all I should need
to do is add the self-signed certificate to the trusted CA file in
/usr/share/ssl/certs/ca-bundle.crt and set the postfix smtp_tls_CAfile
parameter pointing to the same file, which I have done. When Postfix
attempts to initate TLS, the following is logged (hostnames/ip's
obfuscated)

> starting TLS engine
> SSL_connect:before/connect initialization
> SSL_connect:SSLv2/v3 write client hello A
> SSL_connect:error in SSLv2/v3 read server hello A
> SSL_connect:error in SSLv3 read server hello A
> SSL_connect:error in SSLv3 read server hello A
> SSL_connect:SSLv3 read server hello A
> SSL_connect:error in SSLv3 read server certificate A
> SSL_connect:error in SSLv3 read server certificate A
> Peer cert verify depth=0
/C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=relay.server.com/emailAddress=s...@cpanel.net
> verify error:num=18:self signed certificate
> verify return:0
> Peer cert verify depth=0
/C=US/ST=Unknown/L=Unknown/O=Unknown/OU=Unknown/CN=relay.server.com/emailAddress=s...@cpanel.net
> verify return:1
> SSL_connect:SSLv3 read server certificate A
> SSL_connect:error in SSLv3 read server key exchange A
> SSL_connect:error in SSLv3 read server key exchange A
> SSL_connect:SSLv3 read server done A
> SSL_connect:SSLv3 write client key exchange A
> SSL_connect:SSLv3 write change cipher spec A
> SSL_connect:SSLv3 write finished A
> SSL_connect:SSLv3 flush data
> SSL_connect:error in SSLv3 read finished A
> SSL_connect:SSLv3 read finished A
> Unverified: subject_CN=relay.server.com, issuer=relay.server.com
> TLS connection established to relay.server.com: TLSv1 with cipher
DES-CBC3-SHA (168/168 bits)
> Peer certficate could not be verified
> 66DBD16C196: to=<z...@zzz.zzz>, relay=relay.server.com[xx.xx.xx.xx],
delay=31450, status=deferred (TLS-failure: Could not verify certificate)

Note that the above cert DOES have [X509v3 Basic Constraints:CA:TRUE].

Also, openssl verify says the cert is OK, regardless of whether or not
a copy appears in ca-bundle.crt.

Two questions:

1) Am I missing something that is needed in order for
OpenSSL to correctly verify a self-signed server certificate?

2) Is it possible Postfix is doing something wrong that would
cause the observed behavior?

TIA

-------------- Postfix Configuration Details -------------------

Postfix version is 2.0.16 on Fedora Core 1

TLS configuration parameters:

smtp_tls_CAfile = /usr/share/ssl/certs/ca-bundle.crt
smtp_use_tls = yes
smtp_enforce_tls = yes
smtp_tls_enforce_peername = no
smtp_tls_loglevel = 2

--
Jim Garrison (j...@acm.org)
PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org

Lutz Jaenicke

unread,

Jun 22, 2004, 3:27:55 PM6/22/04

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jun 21, 2004 at 09:44:29PM -0500, Jim Garrison wrote:
> First of all, please forgive me if this is the wrong list. I'm having
> a problem using TLS (OpenSSL-based) in Postfix and the problem might
> be in OpenSSL, or how Postfix uses OpenSSL.

No. The problem is located in between the ears.

I am most sorry, but your statement is wrong. This is not the
certificate used on the host in question. I just did connect to
the host (with a hacked version of openssl s_client:
./openssl s_client -CAfile cert.pem -connect minsk.hostforweb.net:25 -starttls smtp -debug
(I needed to hack s_client because it does not sent the required EHLO.
This hack is most ugly and messes up the cleartext communication, but
I have appended it for your information and to verify my statements.)
The certificate sent by the server will be listed such that you can
save it to a certificate file:
-----BEGIN CERTIFICATE-----
MIIDkjCCAvugAwIBAgIBADANBgkqhkiG9w0BAQQFADCBkzELMAkGA1UEBhMCVVMx
EDAOBgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoTB1Vu
a25vd24xEDAOBgNVBAsTB1Vua25vd24xHTAbBgNVBAMTFG1pbnNrLmhvc3Rmb3J3
ZWIubmV0MR0wGwYJKoZIhvcNAQkBFg5zc2xAY3BhbmVsLm5ldDAeFw0wNDA2MDkx
MDM5MTZaFw0zMTEwMjUxMDM5MTZaMIGTMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
VW5rbm93bjEQMA4GA1UEBxMHVW5rbm93bjEQMA4GA1UEChMHVW5rbm93bjEQMA4G
A1UECxMHVW5rbm93bjEdMBsGA1UEAxMUbWluc2suaG9zdGZvcndlYi5uZXQxHTAb
BgkqhkiG9w0BCQEWDnNzbEBjcGFuZWwubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQCyXWHU7Qns7zoojuCfM66cWiS7EPlkRhSscRgGVIJe84T85zjmAWZT
M9VNYFSupneInOQxGq4CPDs4xnMfhJLVH7x/vi+WZ6CnnC3lmz3Z7QWGft0iBaOf
VF+XXDOTGKbHwUBwZxW+0CmfUasQrw7mO2GFqdmXWoGDaTpZbBFEiQIDAQABo4Hz
MIHwMB0GA1UdDgQWBBTIF8I85FeKPTfweHLzhMObYkzUqTCBwAYDVR0jBIG4MIG1
gBTIF8I85FeKPTfweHLzhMObYkzUqaGBmaSBljCBkzELMAkGA1UEBhMCVVMxEDAO
BgNVBAgTB1Vua25vd24xEDAOBgNVBAcTB1Vua25vd24xEDAOBgNVBAoTB1Vua25v
d24xEDAOBgNVBAsTB1Vua25vd24xHTAbBgNVBAMTFG1pbnNrLmhvc3Rmb3J3ZWIu
bmV0MR0wGwYJKoZIhvcNAQkBFg5zc2xAY3BhbmVsLm5ldIIBADAMBgNVHRMEBTAD
AQH/MA0GCSqGSIb3DQEBBAUAA4GBAJ2NwxcwDAGu1QyPxhE09gDjVgheyHA3st0r
MJGpPk7DnVcnhnupdLmorZFzaI5VCqh6wbrTQdec0jILSw9o/O5O5DenlsIKNm1W
dQ0GzMQSC64b9RHnGWCri6o3OJkV/FNXdTlucf+DbAc9p+395K5Nu5HdjzcKT/vT
7fjXJBcM
-----END CERTIFICATE-----

Close examination with "openssl x509 -in cert.pem -text" will easily
reveal that the certificates are in fact different. The "not before"
date stating the date of issuing indicates that the certificate might
have been exchanged around June 9.

> The problem is that Postfix refuses to proceed because it cannot
> verify this self-signed cert.

It behaves just as intended :-)

Best regards,
Lutz
PS. It does not make much sense to obfuscate the FQDN and IP in the
original post to postfix-users, if you sent the certificate including
the real hostname to openssl-users :-) And it would have made tracking
down the problem impossible if I wouldn't have been able to extract
the information from the certificate.
--
Lutz Jaenicke Lutz.J...@aet.TU-Cottbus.DE
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus

--9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="s_client.patch"

Index: s_client.c
===================================================================
RCS file: /e/openssl/cvs/openssl/apps/s_client.c,v
retrieving revision 1.54.2.10
diff -u -r1.54.2.10 s_client.c
--- s_client.c 27 Sep 2003 21:56:12 -0000 1.54.2.10
+++ s_client.c 22 Jun 2004 19:24:15 -0000
@@ -588,6 +588,8 @@
if (starttls_proto == 1)
{
BIO_read(sbio,mbuf,BUFSIZZ);
+ BIO_printf(sbio,"EHLO some.host.name\r\n");
+ BIO_read(sbio,mbuf,BUFSIZZ);
BIO_printf(sbio,"STARTTLS\r\n");
BIO_read(sbio,sbuf,BUFSIZZ);
}

--9amGYk9869ThD9tj--

Jim Garrison

unread,

Jun 22, 2004, 5:20:28 PM6/22/04

Lutz Jaenicke wrote:

> No. The problem is located in between the ears.

Ouch! But thanks for helping....

> I am most sorry, but your statement is wrong. This is not the
> certificate used on the host in question. I just did connect to

You are, of course, correct. I was assured that the cert I was
given was the one in use. As I had no way to capture the one
actually being sent by the server, I accepted on faith that they
were the same.

Everything is now clear.... thanks again for your assistance.

0 new messages