curl -I https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/policies
curl: (60) SSL certificate problem: certificate has expired

I think we should just tell bodhi to use the new URL for greenwave, it's been using this legacy one for a while now...

Proposed fix: https://pagure.io/fedora-infra/ansible/pull-request/172

Looking around, it looks like we'll need to update that certificate. Nagios, waiverdb, bodhi, greenwave are all relying on this domain.

So the symptoms have been fixed by migrating bodhi and greenwave to the newer URL format but the underlying issue (cert expired) has not been fixed.

We may still have to do it. Especially considering it is in the redirect_uris field of the client_secrets.json for waiverdb, so this may impact user's capabilities to login against waiverdb.

Thanks, https://bodhi.fedoraproject.org/updates/FEDORA-2020-cfbed9c9ff now shows that fedora-ci.koji-build.rpminspect.static-analysis was run.

We should setup cert-manager in our openshift and get all these endpoints to use letsencrypt and then it would auto renew them, etc.

For the record, @pingou 's similar change to the checkcompose group vars was fine and appropriate. I've also updated the default in check-compose's own code. check-compose asks Greenwave for the gating status of a Rawhide compose when it's checking it, and includes that in the report; this was intended as a precursor to actually turning on compose gating (which we still haven't done), the idea being the compose check reports let us see at a glance how often composes are passing or failing the planned gating requirements.

So the symptoms have been fixed by migrating bodhi and greenwave

This still breaks sending waivers with waiverdb-cli:

requests.exceptions.SSLError: HTTPSConnectionPool(host='waiverdb-web-waiverdb.app.os.fedoraproject.org', port=443): Max retries exceeded with url: /api/v1.0/waivers/ (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1108)')))

This still breaks sending waivers with waiverdb-cli:

This may work via bodhi (bodhi updates waive) but I would not be surprised if it does not either.

@pingou : Interesting, bodhi updates waive did indeed work. Thanks for the hint, I wasn't aware of that command yet.

As soon as I can stand up the staging openshift cluster, we can install cert-manager and have it handle these... then roll to prod.

We sent several bodhi updates yesterday where tests were triggered fine, and talking to greenwave worked. Sounds like this got resolved?

The bodhi/greenwave interaction has been fixed quickly after this ticket was opened. The underlying issue still remains and makes waiverdb-cli fail as you reported here :)

Updating the title here so we can find the remaining issue easier.

To update status I have asked our cert provider to try and issue this cert (which for technical reasons is not easy) I will ask them for a status update.

I've again asked for a status update, and I am starting another possible way to get around this.

This is finally fixed. In both staging and prod.

Enjoy!