On Mon, Jul 3, 2017 at 12:58 AM, 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?
Heya Jason, Thanks for pointing this out. Yes, it's a bug. Also, it turns out re-using serial numbers is a bad idea too. I don't think their mistake *currently* hurts the tests but it would be great to get them both fixed. So a PR would be quite welcome. Regarding Glyph's comments about where the chain is verified - that's still handled by the TLS library. The Chain invariant in _authentication.py is just a superficial sanity check to catch the common problem of "a-b-c" vs "c-b-a" chain certificate order. Thanks! Jean-Paul