On 1/22/2014 3:46 PM, Viktor Dukhovni wrote:
> On Wed, Jan 22, 2014 at 03:07:33PM -0500, Ben Johnson wrote:
>
Thanks for expanding upon Wietse's response, Viktor.
>> I created the certificate with the following command:
>>
>> $ cat example_com.crt PositiveSSLCA2.crt AddTrustExternalCARoot.crt >
>> /root/ssl/example.com.pem
>
> To verify that the file is well-formed try the below:
>
> openssl crl2pkcs7 -nocrl -certfile /root/ssl/example.com.pem |
> openssl pkcs7 -print_certs -text |
> less
>
> You should see the verbose decoding of the certificates in the
> correct order.
>
And I do. That's a handy command to have around; thanks for that.
>> # TLS parameters
>> smtpd_tls_cert_file = /root/ssl/example.com.pem
>> smtpd_tls_key_file = /root/ssl/example.com.key
>> smtpd_use_tls = yes
>>
>> But when I attempt to verify the certificate chain, I always receive
>> "19:self signed certificate in certificate chain".
>
> There nothing wrong with that, the client did not have a suitable
> CAfile or CApath configured. Very few SMTP clients do.
>
>> $ openssl s_client -connect example.com:25 -starttls smtp
>
> No -CAfile or -CApath options in this command-line.
>
I see. I had actually tried adding a -CApath, but I didn't think it was
working correctly because no matter what path I supplied, the
certificate always ended with (what I understand to be) a "success"
response:
Verify return code: 0 (ok)
In fact, I can even use a completely non-existent path on my system, and
still receive "0 (ok)", e.g.:
$ openssl s_client -connect example.com:25 -starttls smtp -CApath /fake/path
...
Verify return code: 0 (ok)
Is there a rational explanation for this behavior? I would expect the
openssl executable to complain that the supplied CApath is invalid
(doesn't exist), and for the TLS session to end with something other
than "Verify return code: 0 (ok)".
This does seem to be the case when using -CAfile, however. If I do
something like
$ openssl s_client -connect example.com:25 -starttls smtp -CAfile /fake/file
I see the type of output that I would expect in the former scenario with
-CApath:
140106251884192:error:02001002:system library:fopen:No such file or
directory:bss_file.c:169:fopen('/fake/file','r')
140106251884192:error:2006D080:BIO routines:BIO_new_file:no such
file:bss_file.c:172:
140106251884192:error:0B084002:x509 certificate
routines:X509_load_cert_crl_file:system lib:by_file.c:274:
[... all other expected output here ...]
Verify return code: 19 (self signed certificate in certificate chain)
In other words, -CApath doesn't really seem to work. At all. Unless I am
misunderstanding something fundamental.
>> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=example.com
>> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
>> Limited/CN=PositiveSSL CA 2
>> 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA
>> Limited/CN=PositiveSSL CA 2
>> i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
>> External CA Root
>> 2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
>> External CA Root
>> i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust
>> External CA Root
>
> This chain is good.
>
>> What might the problem be? Isn't the last certificate in the chain
>> *supposed to be* self-signed?
>
> There is no problem.
>
That's a relief! Looks like I am in good shape here, but I am curious
about the -CApath issue described above, nonetheless.
Thanks again for your help, Wietse and Viktor!
-Ben
