Closed kebugcheckex closed 2 years ago
@kebugcheckex Overall I like the direction you are taking.
It looks like the /api/v1/ca
end point will remain backwards compatible if the parentCommonName
field is omitted from the payload. Great!
I would suggest renaming goca.New()
to something like goca.NewCA()
or something along those lines. Then we could preserve the old signature of goca.New()
taking only the commonName
and identity
arguments but calling goca.NewCA()
under the hood with the parentCommonName
set to the empty string for us. This way we preserve the API for consumers of the GoCA package as well, not just the REST API. Effectively goca.New()
will implicitly create only root CAs going forwards.
Something similar could be done with cert.CreateRootCert()
and cert.CreateCACert()
My only other comment is that we should get TestFunctionalRevokeCertificate
passing. As you have already identified this boils down to the root CA not finding the intermediate certificate on-disk.
Did you have a design in mind for this or were you looking for guidance here?
@necheffa I don't have a well-polished design. This is merely the attempt to get intermediate CA working. I'll refactor the code over the weekend according to your suggestions.
Accidentally messed up my git history. Fixed with git push -f
. Will create another PR.
I'm attempting to fix the intermediate CA issue #21
The x509 package of go doesn't create intermediate CA by signing a CSR. Instead, the intermediate CA's certificate is created when passing the parent CA's certificate and private key when calling
x509.CreateCertificate
. There is no CSR involved.Here I added a util function
LoadParentCACertificate
. There's a bit duplicated code but the trade-off should be acceptable.I fixed a few tests but others are still failing. One more problem to be solved is to store the intermediate CA's certificate in the parent CA's
cert
directory. This is no longer "automatic" after the change.Feedback is welcome.