Support certs with GeneralTime
#167
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: omertuc The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
# Background
Recert until now only supported certs with asn1 `UTCTime` and not
`GeneralizedTime`.
# Problem
When golang creates certs with expiration way out in the future, it uses
`GeneralizedTime` instead of `UTCTime`.
For example:
```
4:d=2 hl=2 l= 13 prim: UTCTIME :240607174402Z
19:d=2 hl=2 l= 17 prim: UTCTIME :340605194402+0200
```
vs
```
4:d=2 hl=2 l= 13 prim: UTCTIME :240607174406Z
19:d=2 hl=2 l= 19 prim: GENERALIZEDTIME :21240514194406+0200
```
Usually this is not a problem, because a typical OCP cluster doesn't
have certs this far in the future, but eventually it will become a
problem. Also RHOAI has a component (tektoncd) that has certs with
expiry 100 years in the future [1] (despite the misleading name that
says "Decade" rather than "Century").
Trying to recert a cluster with tektoncd will therefore lead to the
following error:
```
error: |-
scanning and recertification
Caused by:
0: processing discovered objects
1: regenerating crypto
2: re-signing cert with subject CN=tekton-triggers-core-interceptors.openshift-pipelines.svc, O=knative.dev
3: mutating cert
4: extending expiration
5: forcefully expiring
6: evaluating current expiration
7: GeneralTime not supported
```
# Solution
This PR adds support for asn1 generalized time in recert. It's simply a
matter of casting the type correctly, the x509_certificate crate already
supports it.
# Testing
This PR is untested, waiting for feedback from the user that reported
the issue.
[1] https://github.com/tektoncd/triggers/blob/59da11dd50424c9ccef883b558671e34efc0eba5/pkg/interceptors/server/server.go#L36
We had an issue [1] with long expiration so I noticed the name was wrong [1] rh-ecosystem-edge/recert#167
We had an issue [1] with long expiration so I noticed the name was wrong [1] rh-ecosystem-edge/recert#167
We had an issue [1] with long expiration so I noticed the name was wrong [1] rh-ecosystem-edge/recert#167 Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
We had an issue [1] with long expiration so I noticed the name was wrong [1] rh-ecosystem-edge/recert#167 Signed-off-by: Omer Tuchfeld <omer@tuchfeld.dev>
|
/retest |
|
@javipolo did you get a chance to test this? |
Nope, I didn't find the moment .... I'll see if I can make some time to do it and verify that it works |
No stress, just popped up in my notifications because the bot was rerunning the job |
|
@omertuc: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Background
Recert until now only supported certs with asn1
UTCTimeand notGeneralizedTime.Problem
When golang creates certs with expiration way out in the future, it uses
GeneralizedTimeinstead ofUTCTime.For example:
vs
Usually this is not a problem, because a typical OCP cluster doesn't have certs this far in the future, but eventually it will become a problem. Also RHOAI has a component (tektoncd) that has certs with expiry 100 years in the future (despite the misleading name that says "Decade" rather than "Century").
Trying to recert a cluster with tektoncd will therefore lead to the following error:
Solution
This PR adds support for asn1 generalized time in recert. It's simply a matter of casting the type correctly, the x509_certificate crate already supports it.
Testing
This PR is untested, waiting for feedback from the user that reported the issue.