Shibboleth IdP fails to download metadata then never tries again

[Cantor, Scott]

On 8/16/17, 2:09 PM, "users on behalf of shibboleth655 at lewenberg.com" <users-bounces at shibboleth.net on behalf of shibboleth655 at lewenberg.com> wrote:

> But on the problematic server, after the error message about not being 
> able to download the metadata file, no more messages, good or bad, in 
> the process log about that metadata file.

If there are bugs crashing the reload thread, nobody has reported them or observed them in a long time, so there's really nothing much to be said. Without a logged exception, which I thought we caught now, I don't see that there's any way to learn anything. If we're not catching Throwable, then I suppose the answer is that it must have crashed and it seems to me we should be catching Throwable, at least to log it.

The other point I would make is that it is not really correct to use a file with a validity that long. That undermines the trust model of a long-lived key due to the threat of old metadata injection. That's equivalent to using a 30 year cert and never checking a CRL in a traditional PKI. And using a short lived window is how the IdP can best monitor and log any problems with refreshing the metadata, though that logging fix is not in 3.3.

But of course SP metadata has a different risk profile than IdP metadata, so the downsides aren't as drastic.

> Note that the source metadata file itself has not changed since January 2017.

If it hasn't changed, I don't understand why any of them are updating the file unless the web server isn't handling the conditional requests it should be receiving. It should never update on the IdP end at all outside of restarts.

-- Scott