adfs token signing rollover not working

[shea...@colchsfc.ac.uk]

Hi,

Hopefully someone might be able to help/answer this,

We currently have simplesamlphp configured with our ADFS server set up as an IDP with automated metadata updating.

We have configured it to use an array of certificates to validate the incoming metadata when it updates, but when ADFS performs it's certificate renewal the automated metadata update no longer works, we have to renew the certificates, even though one of them is still valid. It seems like it only checks the primary certificate and not the secondary certificate that has just been rolled over.

current.crt and rollover.crt are in the correct folder and being read as it's working when the certificates are updated, however it seems harder to test the rollover.crt as this seems optional? Removing the current.crt to test will generate an error that current.crt is missing and required, however removing rollover.crt will cause no problems at all. Removing current.crt from the config will end up with the same issue as had before updating the certificates, in that the update fails to verify against the certificate. So it does seem like the secondary cert can't verify the metadata?

I've tried to update to 1.19.1 but I'm still getting the same issue.

Is this an issue with how ADFS presents the rolled over cert? Do we have a config issue? Or is something else going on here? Any help would be appriciated,

Thanks!

our config is here:

$config = array(

    'sets' => array(

        'colchsfc' => array(

            'cron'        => array('hourly'),

            'sources'    => array(

                array(

                    'src' => 'https://<ADFSURL>/FederationMetadata/2007-06/FederationMetadata.xml',

                    'certificates' => array(

                        'current.crt',

                        'rollover.crt',

                    ),

                    'template' => array(

                        'tags'    => array('colchsfc'),

                        'authproc' => array(

                            51 => array('class' => 'core:AttributeMap', 'oid2name'),

                        ),

                    ),

                    'types' => array('saml20-idp-remote'),

                ),

            ),

            'expireAfter'         => 60 * 60 * 24 * 4, // Maximum 4 days cache time

            'outputDir'     => 'metadata/metarefresh-colchsfc/',

            'outputFormat' => 'flatfile',

            'types' => array('saml20-idp-remote'),

        ),

    ),

);

[pra...@gmail.com]

The  signature validation code (https://github.com/simplesamlphp/simplesamlphp/blob/59e08962c3890fc7be737591c3743fcbf770baa3/lib/SimpleSAML/Metadata/SAMLParser.php#L1456-L1481)

looks like it loops through the certificates and tries them in order. 

I didn't understand your steps for debugging. If you want to test if the order of the certificates matters then I would put rollover.crt first and current.crt second.

If you want to test if your rollover.crt can validate the metadata signature then I would:

1. Download the metadata.xml file to my computer

2. Look at the X509Certificate element in the signature (the key will likely appear multiple times in different contexts)

3. See if it is same data as your rollover.crt.

Or perhaps I'm not understanding the question.

- Patrick

[shea...@colchsfc.ac.uk]

Hi Patrick,

Thanks for answering and apologies if I wasn't clear, my understanding of the issue shifted a bit while testing!

I removed current.crt from the config completely and it would not validate on rollover.crt

The rollover.crt is found in the metadata.xml multiple times, completely identical to the contents of rollover.crt

My original concern was that the rollover.crt was not being used, but it looks more like it's not being recognised as valid, even though it's in the metadata.xml,

Are there any known issues with rollover certs on adfs working with simplesamlphp?

Or is there another part of the config we need to do to enable simplesamlphp to understand the secondary certificate in the adfs metadata.xml?

Thanks!

[pra...@gmail.com]

There are two types of certificate rotation:

1. Rotating the certificate used to sign the metadata file.

2. Rotating the certificate used by the idp to sign the assertions when users login.

The ADFS IdP is adding the rollover certificate as a second certificate that can be used for signing assertions (use case 2).

The metadata file can only be signed by a single certificate. It is signed by current.crt. Once they rollover to the new cert, then it will be signed by rollerover.crt.  This is why I was suggesting to look at the specific xml element, the cert used in the signature rather than one present in the metadata file (X509Certificate element in the signature).

I believe you are trying to test scenario 1. You cannot test what happens unless the IdP starts signing the metadata with the second certificate instead of the first.

You can only prepare for the transition by either:

1. Adding the rollover.crt (as you did) so that it can be used to validate the metadata signature when the IdP rotates the cert used for signing. You'll need to make adjustments each time the IdP metadata signing cert changes.

2. Give up on verifying the signature and rely on TLS to provide adequate protection in retrieving the metadata. You won't have to make future changes.  You'll need to evaluate the risk vs maintainability trade off.

For scenario 2,  as long as you can periodically pull the ADFS metadata, then you will learn about the new certificates that the IdP will use for signing.

- Patrick

[shea...@colchsfc.ac.uk]

Hi Patrick,

Thank you for the detailed explanation!

My mistake seems to be thinking the rollover of the token signing certificate would mean the metadata was signed by both current and rollover certificates, as the documentation on the simplesamlphp for automated metadata suggests should be possible? I guess thinking about it harder a system that supported a metadata signature rollover would end up with a current and rollover metadata.xml? Though there is still only one src url which can have an array of certificates to verify the signature of the metadata, so I'm still confused as to how that process is supposed to work!

Regardless, it makes sense that the metadata file itself coming from ADFS is only signed by the primary token, I've since found a few sources that seem to confirm that as well, now that I know what I'm looking for!

So yes, as you say, my routes forward are updating the current.crt on the servers using the ADFS idp to verify the metadata.xml source, or trust TLS to be enough protection to be given a valid metadata.xml from the correct source. Both server and ADFS server are internal to each other, so it should be fine here to rely on TLS where we can.

Scenario 2 has been working fine, it was just the metadata refresh being blocked when the signing cert switched over.

ADFS signs the metadata with the primary token signing cert, so I think this led me to some wrong conclusions by mixing up both processes, so thank you very much for helping me get this cleared up!

Chris.