Coverity badge always gets "inaccessible" status

[mity]

Are you experiencing an issue with...

• shields.io
• My own instance
• gh-badges NPM package

🪲 Description

The Coverity Scan badge for MD4C project always shows in a gray color with the status message as "inaccessible". Noticed this few days ago for the first time. But before that it used to work correctly for a long time.

I've just checked https://scan.coverity.com/projects/mity-md4c/badge.json and it seems to get the following JSON correctly:

{"project":"mity/md4c","status":"passed","message":"passed"}

🔗 https://img.shields.io/coverity/scan/mity-md4c.svg?label=coverity%20scan

[calebcartwright]

Thanks @mity taking a look now, will update when we have more info

[calebcartwright]

Looks like there's an issue in the cert chain, below is the error we're getting internally:

Inaccessible: unable to verify the first certificate

Very similar underlying issue to #1956

https://www.ssllabs.com/ssltest/analyze.html?d=scan.coverity.com&hideResults=on

[mity]

I see.

Well, the question is whether it makes any sense to be stricter then browsers are.

[calebcartwright]

Well, the question is whether it makes any sense to be stricter then browsers are.

This isn't due to anything we're doing explicitly. It's just the default behavior of many http clients. Why the browsers operate the way they do vs. those http clients is an entirely separate conversation 😄

The underlying issue is related to what sounds like a recently introduced issue in Coverity's certificate chain. We're mulling some options on if/how we could potentially work around such issues in the upstream services (like Coverity). However, ideally those services would resolve their certificate issues vs. us having to disable/relax ssl validation on our end.

[mity]

This isn't due to anything we're doing explicitly. It's just the default behavior of many http clients. Why the browsers operate the way they do vs. those http clients is an entirely separate conversation 😄

Ok.

The underlying issue is related to what sounds like a recently introduced issue in Coverity's certificate chain. We're mulling some options on if/how we could potentially work around such issues in the upstream services (like Coverity). However, ideally those services would resolve their certificate issues vs. us having to disable/relax ssl validation on our end.

I can fully understand that. But my attempts to contact them (for some other minor issue like the service not working at all for some project) all failed, and I never got any response from them, so I am skeptical. :-(

[calebcartwright]

Understood. I'll make sure that if we add a work around on our end, that we include that support for our Coverity badge as well.

[jarun]

This affects one of my projects (bcal) too.

[calebcartwright]

All Coverity badges are going to show as inaccessible due to an issue in the Coverity service's cert chain.

We may deploy a work around in the near future, but I'd still suggest that folks try to get in touch with Coverity to see if they can resolve those cert issues

[jarun]

Thanks for the quick response. I'll drop a mail right away. However, their response time is painfully slow in my experience.

[calebcartwright]

FYI we've updated things on our end so that requests for Coverity badges will explicitly disable the strict ssl check, thus restoring Coverity badges.

Once #3336 is deployed to prod, your badges will automatically start working again (this comment will track the status of that deployment).

For a visual, here's the two Coverity badges referenced above from our staging app:

https://shields-staging.herokuapp.com/coverity/scan/mity-md4c.svg?label=coverity%20scan

https://shields-staging.herokuapp.com/coverity/scan/jarun-bcal.svg

[jarun]

Thank you!

[jarun]

Thank you!