Nathaniel Smith <n...@pobox.com> added the comment:
> For the concern issue, as I understand it, the ability to call getpeercert() > or the proposed getpeercertchain() is only after the TLS session has been > established. As such, the SSL socket already established that there exists a > valid chain of trust. Thus these methods are primarily to provide visibility > into what the peer passed *after* it had been authenticated, right? The issue is that "the cert chain provided by the client" and "the cert chain that was validated as trustworthy" might be different. For example, say you have trust roots A and B, and I have a leaf certificate with a valid signature by B. If I pass the chain [A, leaf cert], then openssl's trust validation code might look at that and say "yep, this leaf cert is signed by root B, I trust root B, cool, the connection is good. Also there's a random A cert here, but whatever, that doesn't change anything". In this case, for your use case, you want to get back the chain [B, leaf cert], because that's the chain that was actually validated. If you instead got the chain the client gave you, then you might be fooled into thinking that this cert chained to root A, when it actually didn't, and make the wrong trust decision. That's why we need to be careful to distinguish between these two possible chains. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18233> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
