On Jul 2, 2017, at 9:58 PM, Jason Litzinger <jlitzingerdev@gmail.com> wrote:

The cryptography APIs for making certs are pretty straightforward and well
documented. But if another example helps, here's some code that creates a
self-signed ca cert and a client cert with an intermediate cert in between:

https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L17-L29

https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/test/test_authentication.py#L276-L309

I'm diving into adding benchmarks for testing HTTPS and this has been
very helpful. I did have one question, in the cert function
neither the pubkey or privkey parameters are used, rather, a_key is
always used as both the public and the signing key. Is that
intentional?

Or, should the public key be the pubkey value and the signing key the
privkey value? Meaning, each cert uses the supplied public key and the
signing order is:

   a signs a
   a signs b
   b signs c

If so, do you want me to send you a PR for this change?

I don't know much about txkube, but my understanding of certificate chains suggests that this is what it is trying to test. It looks like this might succeed by accident since everything is signed by the root, and therefore trusted?

It also appears to be implied that the chain is verified somehow, but the invariant is actually just about the subject/issuer pairs: https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1bd798eb54b08/src/txkube/_authentication.py#L47-L59 so something else must be validating the chain.