metadata-support - RE: [Metadata-Support] Expired certificate in our metadata file
Subject: InCommon metadata support
List archive
- From: "Cantor, Scott" <>
- To: "" <>
- Subject: RE: [Metadata-Support] Expired certificate in our metadata file
- Date: Fri, 5 Aug 2016 21:02:16 +0000
- Accept-language: en-US
- Authentication-results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> I am currently looking into a problem regarding an expired certificate in
> our
> metadata. Per our previous administrator, its presence is necessary due to
> multiple SPs referencing it, and removing it will be a concerted effort. He
> stated that the fact that it is expired shouldn't matter, unless an SP is
> explicitly configured not to accept it, and that is the situation in which
> we
> now find ourselves with Educause.
If you have multiple signing certificates in your configuration, then you
have to have rules in your configuration dictating when they get used. I
don't know who you need to use them with, whether any of those relationships
rely on InCommon's metadata, and that all has to be factored in. Anybody
relying on InCommon's metadata is totally under your control, you decide
which keys you register and you can use any of them to sign with and it will
work. So definitionally, the problems are the rest of them and you have to
control which key you use with them, and control the timing of altering it
with them.
> We have a non-expired certificate in our metadata, but Educause is
> referencing the expired one and not accepting it.
I don't know if educause has a metadata-capable SP or not. They used to use
Shibboleth and now they use Ping, so they went from "it works" to "I have no
idea". Without knowing...
> Is there a way that we can make our
> non-expired one the preferred or default one, so that unless an SP
> explicitly
> requests to use a different one, we use that one?
You already have to be doing this in your IdP config or you wouldn't have
multiple keys in the mix. Controlling which signing key is used with an SP is
covered by the documentation and you can control it per-SP as needed, though
you should absolutely get out of that nightmare asap.
You can't just fix a problem by switching from an expired certificate. If the
relying party doesn't know about the key you switch to, it's going to stay
broken, though I suppose you can't make it worse.
-- Scott
- [Metadata-Support] Expired certificate in our metadata file, seale, 08/05/2016
- Re: [Metadata-Support] Expired certificate in our metadata file, Mike Flynn, 08/05/2016
- RE: [Metadata-Support] Expired certificate in our metadata file, Cantor, Scott, 08/05/2016
Archive powered by MHonArc 2.6.19.