openshift-acme
openshift-acme copied to clipboard
tnozicka
Certificate creation error only on certain project.
Hi, i got some weird behaviour when trying to use the acme controller on our openshift v 3.6.
- it successfully generate the certificate for some project (either already existing project or newly created project)
- it got the following error on a certain project
2017-10-05T06:11:38.148164248Z INFO finished validating domains
2017-10-05T06:11:37.700152663Z TRACE acme.Client ObtainCertificate duration=448.030325ms start=2017-10-05T06:11:37.700152794Z end=2017-10-05T06:11:38.148183119Z
2017-10-05T06:11:38.148239952Z ERROR dbcertentry.go:79 [domain: domain.company.us, error: 403 urn:acme:error:unauthorized: No registration exists matching provided key]
- it doesn't even caught the annotation and wont't start the request for project "default" and some other project.
we're using same deployment config & same service to expose on every project to test. And i think there shouldn't be any difference on all that project (except of the "default" project maybe ) as we don't do any special configuration for all the project we created.
Do you have any idea how do we begin to trace this different behaviour ?
Thank you in advance
@FaisalDefry any chance you run openshift-acme for a while with staging an then switched to prod? if that's the case there is a secret (named acme-account) that has a key to a different realm (staging) that is not compatible with prod - just delete the secret in that namespace
Ah, okay. That explain the specific project that throw the error.
But for the “default” project and some other project who didnt get the request after i change the anotation, do you have any clue?
Either way, Thank you for pointing that out
Sent from my iPhone
On 5 Oct 2017, at 18.26, Tomáš Nožička <[email protected]mailto:[email protected]> wrote:
@FaisalDefryhttps://github.com/faisaldefry any chance you run openshift-acme for a while with staging an then switched to prod? if that's the case there is a secret (named acme-account) that has a key to a different realm (staging) that is not compatible with prod - just delete the secret in that namespace
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/tnozicka/openshift-acme/issues/37#issuecomment-334437004, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMeBpUX5SvMmvIvYGf3R_g2gNlcP9iN8ks5spLzUgaJpZM4PupM6.
But for the “default” project and some other project who didnt get the request after i change the anotation, do you have any clue?
Which annotation? the one on the acme-account secret or on route?
Also try running the controller in debug mode (OPENSHIFT_ACME_LOGLEVEL=9).
Nevermind, i think i found the problem. It looks like if we already set the route to mode "passtrough" . the controller won't change it to "edge". Is it the expected behaviour?
2017-10-05T14:41:23.351221118Z ERROR dbcertentry.go:41 the server rejected our request due to an error in our request; detail: '{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Route \"testing\" is invalid: [spec.tls.certificate: Invalid value: \"redacted certificate data\": passthrough termination does not support certificates, spec.tls.key: Invalid value: \"redacted key data\": passthrough termination does not support certificates]","reason":"Invalid","details":{"name":"testing","kind":"Route","causes":[{"reason":"FieldValueInvalid","message":"Invalid value: \"redacted certificate data\": passthrough termination does not support certificates","field":"spec.tls.certificate"},{"reason":"FieldValueInvalid","message":"Invalid value: \"redacted key data\": passthrough termination does not support certificates","field":"spec.tls.key"}]},"code":422}
Well, with passthrough generating certificates doesn't make sense but I am not sure if the controller should change it for you or report proper error. I'll keep it here as a reminder to enhance it.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen. Mark the issue as fresh by commenting/remove-lifecycle rotten. Exclude this issue from closing again by commenting/lifecycle frozen./close
Instructions 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/test-infra repository.
@tnozicka: Reopened this issue.
In response to this:
/reopen /remove-lifecycle rotten /lifecycle frozen /kind feature
Instructions 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/test-infra repository.