Order of certs returned by SSL_get_peer_cert_chain()

[Graham Leggett]

Hi all,

Can anyone confirm the order in which certs are returned by SSL_get_peer_cert_chain()?

Regards,
Graham
—

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Graham Leggett
Can anyone confirm the order in which certs are returned by SSL_get_peer_cert_chain()?

Last time I read the code, I concluded that SSL_get_peer_cert_chain
returns the certificate chain exactly as sent by the remote server
in its TLS/SSL server HELLO message. The internally constructed
chain used in certificate validation is not (AFAIK/IIRC) available.

So this function is more useful for performing your own independent
chain validation than for examining the chain validated by OpenSSL.

[Michael Wojcik]

Sent: Monday, 20 October, 2014 17:48
Subject: Re: Order of certs returned by SSL_get_peer_cert_chain()
Last time I read the code, I concluded that SSL_get_peer_cert_chain
returns the certificate chain exactly as sent by the remote server
in its TLS/SSL server HELLO message. The internally constructed
chain used in certificate validation is not (AFAIK/IIRC) available.

If memory serves, the chain constructed by OpenSSL is available to the certificate callback function, in the final invocation of the callback for a given certificate exchange. That is, if you're in the callback, and X509_STORE_CTX_get_error_depth(store) returns 0, then X509_STORE_CTX_get_chain(store) should give you the chain constructed by OpenSSL.

This is the callback the application can set with SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, [callback]).

So if you want access to that chain later in processing, you could write a callback that saves it somewhere (e.g. in session external data, with SSL_set_ex_data etc) when invoked for the final check, and just returns preverifyOk.
--
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Viktor Dukhovni]

Post by Michael Wojcik

Post by Viktor Dukhovni
Last time I read the code, I concluded that SSL_get_peer_cert_chain
returns the certificate chain exactly as sent by the remote server
in its TLS/SSL server HELLO message. The internally constructed
chain used in certificate validation is not (AFAIK/IIRC) available.

If memory serves, the chain constructed by OpenSSL is available to the
certificate callback function, in the final invocation of the callback
for a given certificate exchange. That is, if you're in the callback, and
X509_STORE_CTX_get_error_depth(store) returns 0, then
X509_STORE_CTX_get_chain(store) should give you the chain constructed by
OpenSSL.
This is the callback the application can set with SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, [callback]).
So if you want access to that chain later in processing, you could write
a callback that saves it somewhere (e.g. in session external data, with
SSL_set_ex_data etc) when invoked for the final check, and just returns
preverifyOk.

Yes, the constructed chain is available in every invocation of the
callback, but is only known to have passed all the usual validity
checks if all callbacks receive "ok = 1" by the time the last
callback is invoked at depth = 0. If the callbacks in question do
not suppress errors (return the original "ok" argument as-is), then
one can simply check for "ok && depth == 0" and save the chain at
that point.

After the connection completes however, SSL_get_peer_cert_chain()
returns the wire certificate list, not the validated chain.