Certificate creation error only on certain project.

[FaisalDefry]

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

[tnozicka]

@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

[FaisalDefry]

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: @FaisalDefry<https://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 GitHub<#37 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AMeBpUX5SvMmvIvYGf3R_g2gNlcP9iN8ks5spLzUgaJpZM4PupM6>.

[tnozicka]

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).

[FaisalDefry]

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}

[tnozicka]

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.

[openshift-bot]

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

[openshift-bot]

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

[openshift-bot]

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-ci-robot]

@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]

/reopen
/remove-lifecycle rotten
/lifecycle frozen
/kind feature

[openshift-ci-robot]

@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.