Dale Gallagher wrote: > I'm struggling to get qpsmtpd up and running with a chained cert from > DigiCert. It's a WildCard SSL Cert, but I doubt that should make a > difference. Currently there are no problems when using my self-signed > certs!
Other than the first time a client uses it, they must OK the cert as being valid... > tls /path/to/server.crt /path/to/server.key /path/to/ca_chain.crt > > Where ca_chain.crt is created as follows: > cat DigiCert.crt TrustedRoot.crt > ca_chain.crt The tls code was never (AFAIK) tested with externally signed certs, but rather only with self-signed certs (single CA path). This is really "good enough" for the vast majority of installations, for whom a externally signed cert is a unnecessary luxury. > What is even more strange, is that the following works (ie returns > with no error). > > perl -MIO::Socket::SSL -e ' > my $ssl_ctx = IO::Socket::SSL::SSL_Context->new( SSL_use_cert => 1, > SSL_cert_file => "server.crt", > SSL_key_file => "server.key", > SSL_ca_file => "DigiCertChain.crt", > SSL_cipher_list => "HIGH", > SSL_server => 1 > ) or die "Could not creat SSL context: $!"; > ' That doesn't have anything to do with your error; the code in the tls plugin is working too, but the underlying SSL code (I don't know if it is IO::Socket::SSL or Net::SSLeay) is not passing the entire certificate chain during the initial negotiation. >From a quick google, I think the solution is that you have to include the certificate chain in the same file as the server cert itself, in reverse order (so the CA is first, followed by any intermediate CA's, and the server cert is last). I think this is because the SSL_ca_file is there for the local code to authenticate the certificate, but you need to send a copy to the remote end so _it_ can authenticate the chain... HTH John
