Add explicit startTime and endTime parameters to
cryptoservice.GenerateCertificate and trustmanager.NewCertificate.
trustmanager.NewCertificate as a low-level data manipulation function
should not be hard-coding policy (10-year expiration); that policy
belongs to its callers, or one more level higher to callers of
cryptoservice.GenerateCertificate.
These places hard-coding policy now also have an explict comment to
that effect.
In addition to conceptual cleanliness, this will allow writing tests
of certificate expiry by generating appropriate expired or nearly-expired
certificates.
Tests which don't care about the policy much will continue to use the
just added cryptoservice.GenerateTestingCertificate.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Various tests have been calling trustmanager.NewCertificate and
open-coding most of cryptoservice.GenerateCertificate. So, add
cryptoservice.GenerateTestingCertificate. It differs only by using
crypto.Signer instead of data.PrivateKey because the tests
have a crypto.Signer more frequently available, and converting
from data.PrivateKey to crypto.Signer is easier than the other way.
This will make it easier to add policy parameters which the tests don't
care about to trustmanager.NewCertificate and
cryptoservice.GenerateCertificate in the future.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The commented code is not converting DER to PEM, it is parsing DER into
an in-memory data structure, and is hopefully just as clear without a
comment.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Miloslav Trmač
Diogo Monica
David Lawrence
Ying Li