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/faa0374fcef6d089af39a98310f1bd...
https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1bd...
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/faa0374fcef6d089af39a98310f1bd... <https://github.com/LeastAuthority/txkube/blob/faa0374fcef6d089af39a98310f1bd...> so something else must be validating the chain. -glyph