Changes to SPF metadata don't propagate to all federations

[kosarko@ufal.mff.cuni.cz]

Our shibboleth certificate is about to expire. We've started the rollover process - we've added the new certificate to the metadata in svn, beside the old one. After a week the new certificate still didn't make it to all the federations. HAKA to name one.
Is there some timeschedule when we can/should expect the change to happen, is there something we can do to speed things up?

[Sander Maijers]

Hi Ondřej,

I'm administering the SPF for CLARIN together with Willem Elbers and Dieter van Uytvanck. I've added your new certificate today to ACOnet, Haka/Kalmar? Union and SURFconext. Belnet refuses all SAML metadata with ‘accentuated characters’, which is of course very silly, and I'm actively discussing with them to get it through.

However, please note that they may take some time to process the change. I hope before next Saturday when your certificate expires, but this could even be exceeded.

What can you do to speed things up:

• Use certificates with a long validity term.
• Do not manage the SAML metadata yourself at identity federations, esp. those other than your home federations (the latter is just for political reasons, technically, just let us do it). I saw your e-mails about discussions on your certificate with DFN-AAI, which for some reason led me to skip managing this process for other federations, without much thought jumping to the conclusion that you manage your SAML metadata yourself universally.
• Do use self-signed certificates. DFN-AAI will not make a problem but you were alarmed by their red-colored error messages in the administration interface. You just have to contact them and all will be fine immediately. Or ideally, let us contact them, as we know about these details.

Please follow these guidelines: ​https://spaces.internet2.edu/display/InCFederation/X.509+Certificates+in+Metadata#X.509CertificatesinMetadata-Requirements

The expired certificates have no consequences for your security or user functionality. They are not verified by Shibboleth at all, just the public key in them is extracted. You will just be nagged over e-mail by some identity federations. Which is why you should only supply long-lived certificates with strong public keys.

[kosarko@ufal.mff.cuni.cz]

Replying to sander@…:

• Do not manage the SAML metadata yourself at identity federations, esp. those other than your home federations (the latter is just for political reasons, technically, just let us do it). I saw your e-mails about discussions on your certificate with DFN-AAI, which for some reason led me to skip managing this process for other federations, without much thought jumping to the conclusion that you manage your SAML metadata yourself universally.

I see, sorry about that. Before we were part of SPF we already were in DFN, that's why we have a possibility to modify our metadata there. Good to know we don't have to do that anymore.

As for the self signed certificates - it currently seems more manageable for us to have the same certificate for SSL and shibboleth. There's only one expiry date we have to keep in mind, only one key to take care of...
That being said I've noticed in the link you've posted, the suggestion actually is to have the self-signed certificates long lived > 10 years (but before 2038). That's quite interesting, because I though some federations have a limit of 3 years. See the often cited SWITCHaai rollover guide(​https://www.switch.ch/aai/guides/sp/certificate-rollover/) where they generate a certificate that lives for three years.

In your opinion are the long lived (ten and more years) certificates reasonable?

[Sander Maijers]

Yes, it's very true that across identity federations even the public key crypto standards and requirements are not harmonized at all. Yes, some will complain about properties of certificates they have rules for. As I understood, the reasons they are limiting this validity time is for potential future cryptography compromises. If you let us manage it, then at least they will only complain once and to one party.

In the near future, you can get X.509 certificates for TLS for free using e.g. ​Let's Encrypt , and they will be replaced more often and automatically. In that light, it would not be smart to put the same certificate you use for TLS in your SAML metadata, as changing the SAML metadata is very involved and takes lot of human effort, sadly.

[Sander Maijers]

I'm including your e-mail on the Trac, so that other SP operators can use this information as well.

Hi,
I'd like to check whether I've understood everything correctly, so please bear with me.
We still need to change the order of the keys/certificates in our SP configuration and eventually delete the expired one from the metadata. We should only do this after you let us know the new cert is in all the federations - waiting only for belnet now?

You can check the status of the distribution of the SAML metadata about your SP, as in which SAML metadata is known by which identity federation, by clicking on the delta symbols at ​https://centres.clarin.eu/spf. This also shows, though you have to look for it, what certificates are known by each identity federation. This shows that SURFconext and Kalmar Union still only know the old certificate. Both of them should not, so I will contact them. (Though SURFconext has simply not responded to the change request yet.)

Only thing that should happen if the expired cert is in the metadata as active one after 24th is that we'll get emails; will all the users still be able to log in?

First of all, you will probably not get such e-mails if you also have a valid/unexpired certificate in your metadata. Your users will be able to log in using IdPs? that know the public key of at least one key pair that your SP is configured to use. So if you have at least the new certificate both at the identity federations (we have) and at your SP at the time the old one has expired, then it works. See: ​https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCredentials

Perhaps some overeager identity federation will remove your SAML metadata because of the expired certificate, then of course everything still breaks down. But I've never seen examples of that, in fact I've seen many examples of long-expired certificates being in the SAML metadata batches of various identity federations. So I expect no problems with logging in, though we should of course do everything to avoid such a situation.

We only need to delete the expired cert from one place - clarin svn, because you are able to make this change in all the member federations - even eduID.cz and DFN.

I am able to change it everywhere, but eduID.cz will not carry it out because they know that you at UFAL are already managing your entity. DFN-AAI may carry it out but will first ask the contacts at UFAL. In summary, you will need to really decide and inform all parties who manages the SAML metadata at identity federations for UFAL.

Are there any more steps?
Thanks and best regards
Ondrej Kosarko

[Sander Maijers]

I believe all identity federations have new your certificate now (they told me, did not check again). If you get any complaints about the old certificate still being present alongside the new one, then I will make sure it is removed with an explicit action by me.