SSLSocket.getpeercertchain()

[tiran]

BPO	18233
Nosy	@jcea, @pitrou, @tiran, @ashemedai, @njsmith, @mmaker, @dstufft, @dsoprea, @miki725, @mmasztalerczuk, @chet, @joernheissler, @chrisburr, @JustAnotherArchivist, @jamespo
PRs	bpo-18233: Add SSLSocket.get_verified_chain() and SSLSocket.get_unverified_chain() #17938 bpo-18233: Add internal methods to access peer chain (GH-25467) #25467
Dependencies	bpo-18147: SSL: diagnostic functions to list loaded CA certs
Files	ssl_peerchertchain.patch ssl_peerchertchain2.patch ssl_peercertchain3.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tiran'
closed_at = None
created_at = <Date 2013-06-16.20:39:55.412>
labels = ['expert-SSL', 'type-feature', '3.10']
title = 'SSLSocket.getpeercertchain()'
updated_at = <Date 2021-06-21.15:17:12.858>
user = 'https://github.com/tiran'

bugs.python.org fields:

activity = <Date 2021-06-21.15:17:12.858>
actor = 'jamespo'
assignee = 'christian.heimes'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2013-06-16.20:39:55.412>
creator = 'christian.heimes'
dependencies = ['18147']
files = ['30611', '30622', '45057']
hgrepos = []
issue_num = 18233
keywords = ['patch']
message_count = 32.0
messages = ['191287', '191352', '193424', '199434', '199443', '199446', '199447', '203187', '203189', '203190', '205734', '244312', '244313', '244314', '278494', '280348', '293570', '293577', '293580', '293590', '293778', '301525', '324917', '357540', '361076', '361085', '361093', '361095', '361120', '372627', '372673', '391916']
nosy_count = 20.0
nosy_names = ['jcea', 'pitrou', 'christian.heimes', 'asmodai', 'njs', 'maker', 'Hiroaki.Kawai', 'underrun', 'zwol', 'dstufft', 'dsoprea', 'miki725', 'mmasztalerczuk', 'chet', 'joernheissler', 'chaen', 'chrisburr', 'kwatsen', 'JustAnotherArchivist', 'jamespo']
pr_nums = ['17938', '25467']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue18233'
versions = ['Python 3.10']

[tiran]

The patch implements a method getpeercertchain() on a SSLSocket. It returns the peer's certificate chain from the leaf cert to the root cert if available. It wraps SSL_get_peer_cert_chain().

SSL_get_peer_cert_chain() doesn't have to pull any additional data from the peer. The information is already exchanged for cert validation.

[tiran]

As expected it is much harder to get the full certification chain from OpenSSL than I initially expected. SSL_get_peer_cert_chain() doesn't return the root CA's certificate. The new patch introduces a validation mode and uses X509_verify_cert(*X509_STORE_CTX) + X509_STORE_CTX_get1_chain() to build a full chain.

[tiran]

From Rietveld review:

---
http://bugs.python.org/review/18233/diff/8422/Modules/_ssl.c#newcode1203
Modules/_ssl.c:1203: chain = X509_STORE_CTX_get1_chain(store_ctx);
This isn't appropriate for this method. Specifically, you are asking for
the peer cert chain, which purposefully does not include root CA certs
that you trust. What you are giving here a complete validate chain from
a peer cert to a trusted root. This is a valuable piece of information,
but should be returned via another method (perhaps exposed in python as
get1chain in SSLContext). But this method should always return the
result of SSL_get_peer_cert_chain if a peer cert chain is available.
---

You are making a good point. I'm either going to split it up into two function or provide a way to look up a cert by issuer.

[dsoprea]

I was about to submit a feature request to add exactly this. The [second] patch works like a charm. When are you going to land on a particular resolution so that it can get committed in?

Dustin

[pitrou]

The patch needs a test, a proper doc, and reviewing.

[pitrou]

Sorry for the incorrect answer. I just noticed there was a test in the patch!
Further looking at it, I notice the new function is returning a tuple. Wouldn't it be better to return a list here?

[dsoprea]

My two-cents is to leave it a tuple (why not?).

Dustin

[tiran]

I'd rather return a list or tuple of X509 objects but bpo-18369 won't be ready for 3.4. Ideas?

[pitrou]

@dustin

My two-cents is to leave it a tuple (why not?).

Because tuples are more used for struct-like data. Here we are returning an unknown number of homogenous objects, which generally calls for a list.

@christian

I'd rather return a list or tuple of X509 objects but bpo-18369 won't be ready for 3.4. Ideas?

Unless the feature is really important to have right now, I think it's ok to defer it until we have X509 objects.

[tiran]

It's just nice to have for debugging and extended verification.

[underrun]

I could really use this sooner than later... and sometimes having a full-featured (or even secure) interface is not what you want.

Consider zmap and masscan etc and ssl mapping (similar to what the EFF did a couple years back - https://www.eff.org/observatory - but with the full chain instead of just the cert). The desire here would be low level, low overhead, no validation on the fly: All you want is the cert chain.

There are plenty of research and security applications where a simple wrapper around OpenSSL that returns DER bytes would be desirable. Please reconsider this patch for inclusion in 3.4 ...

[ashemedai]

Given that cryptography.io is fast becoming the solution for dealing with X.509 certificates on Python, I would like to add my vote to add my vote for this feature. Right now, getting the full chain in DER is what I am missing to complete a task at work.

[dsoprea]

Forget it. This project is dead.

Dustin
On May 28, 2015 11:58 AM, "Jeroen Ruigrok van der Werven" <
report@bugs.python.org> wrote:

Jeroen Ruigrok van der Werven added the comment:

Given that cryptography.io is fast becoming the solution for dealing with
X.509 certificates on Python, I would like to add my vote to add my vote
for this feature. Right now, getting the full chain in DER is what I am
missing to complete a task at work.

----------
nosy: +asmodai

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue18233\>

---