Root Ca is always not Before: Aug 31 00:00:00 2013 GM about kms-issuer HOT 6 CLOSED

#14 i think this behavior is introduced with this PR. NotBefore is truncated with duration - renewBefore. I tried to use the default of renewBefore which is 2/3 of Duration but the Validity is still weird:

2019-08-30 00:00:00 +0000 UTC
2039-08-25 00:00:00 +0000 UTC

If i override Rounding and set 1h (Which will never computed). it makes more sense:

2022-06-03 11:00:00 +0200 CEST
2032-05-31 11:00:00 +0200 CEST

i do not exactly understand the behavior of Rounding and why it is set to this calculation. The outcome of this calulation does not make any sense to me

from kms-issuer.

The rational for using time.Truncate was to ensure the ca.pem is generated across multiple kubernetes clusters but the same kms key (which requires setting NotBefore/NotAfter to the same value). But as you mentioned the very first set of dates are just weird. This isn't great.

I think this could be refactored because it's just confusing. Having different root-ca pem isn't a real issue.

from kms-issuer.

Hey chaudyg,

but at some point the kms Issuer will create a new CA with new value in NotBefore/NotAfter. I did not understand when this will happen. I tested this with a simple go script and modified time.Now() but it is not really clear when i lose my current Issuer when i recreate them.

Does it make sense to build a feature to set notBefore and notAfter to a certain value. With that i would have more control how long my rootCA would last. So if i set spec.NotBefore and spec.NotAfter the kmsIssuer would generate me a RootCa with these validity and if i set this in every cluster to the same value i would get the same RootCA every time.

from kms-issuer.

but at some point the kms Issuer will create a new CA with new value in NotBefore/NotAfter. I did not understand when this will happen.

As you said, this should be renewed by default 2/3rds of the way through the certificate’s duration. So, if your CA is valid for 21 years, a new PEM will be renerated 7 years before expiration.

Does it make sense to build a feature to set notBefore and notAfter to a certain value.

kms-issuer uses the same strategy as cert-manager: the private key is unchanged by the public ca pem is automatically renewed. Hard-coding some dates would force the users to manage those dates manually.

I think there is something not clear, but I am not sure what it is. I am answering your question?

from kms-issuer.

Hello @derbauer97, is there any action you would like us to take or are you happy with the answer from @chaudyg?

from kms-issuer.

Sorry for the late answer. I think i understand now how it works. We stick to the default behavior rather then setting renew by ourself. Now we get a much better Validity. Thanks for your help!

from kms-issuer.