ページ履歴

SPの設定変更手順

新しい署名鍵で署名されたフェデレーションメタデータおよび新しい検証用証明書が公開されておりますので、本手順に従い設定変更を実施してください。

新しい検証用証明書を以下のURLからダウンロードして「/etc/shibboleth/cert/gakunin-signer-2017.cer」に置きます。
https://metadata.gakunin.nii.ac.jp/gakunin-signer-2017.cer

/etc/shibboleth/shibboleth2.xml を次のように編集します。

1. <MetadataProvider>のuriに指定するメタデータダウンロードURLを以下の通り、末尾に ?generation=2 を付加します。

   コード ブロック
   language diff title 差分（unified diff形式）
   <MetadataProvider type="XML" validate="true" - uri="https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml" + uri="https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml?generation=2" backingFilePath="federation-metadata.xml" reloadInterval="7200"> (......)

2. <MetadataFilter>のcertifiateに指定する署名検証用証明書のファイル名を以下の通り、2010 の部分を 2017 に修正します。

   コード ブロック
   language diff title 差分（unified diff形式）
   <MetadataProvider type="XML" validate="true"   (......) backingFilePath="federation-metadata.xml" reloadInterval="7200"> - <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2010.cer"/> + <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2017.cer"/> (......) </MetadataProvider>

   ヒント

   バージョン2.6およびそれ以降をお使いの場合、万一設定ミスした場合もしくはダウンロードに失敗した場合の保険として、さらにverifyBackup="false"を追加していない場合は追加することをお勧めします。そうでなければ、後述の再起動時、旧署名証明書で署名されたバッキングファイルに対して新署名証明書で検証するため失敗し、当該バッキングファイルが効果を失います。ただし、バッキングファイルが他者によって変更されないことが確実な場合のみこれを行ってください。 コード ブロック language diff title 差分（unified diff形式） <MetadataProvider type="XML" validate="true"   (......) backingFilePath="federation-metadata.xml" reloadInterval="7200"> - <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2017.cer"/> + <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2017

...

1. .cer" verifyBackup="false"/> (......) </MetadataProvider> もちろんバッキングファイルが新メタデータで上書きされた後は上記問題は起こりませんが、起動時にバッキングファイルが使われる場合署名検証がスキップされ起動が速くなりますのでいずれにしろお勧めです。

shibdを再起動し、設定を再読み込みします。

(CentOS 7の場合)
$ sudo systemctl restart shibd
(CentOS 6の場合)
$ sudo service shibd restart

新しい署名鍵で署名されたメタデータがダウンロードされているか、保存されたメタデータファイル（/var/cache/shibboleth/federation-metadata.xmlもしくはshibboleth2.xmlの<MetadataProvider>のbackingFilePathで指定されたパス）を確認してください。
まず、ファイルの更新日時を確認し、上記再起動コマンド実行より後であることを確認してください。
次に、メタデータファイルの先頭から検索し、最初にマッチする</ds:X509Certificate>の直前の行が以下のようになっていれば成功です。

$ grep -B 1 "/ds:X509Certificate" /var/cache/shibboleth/federation-metadata.xml | head -n 2
nwU/H9ROp1cl
</ds:X509Certificate>

以下のようになっている場合は古い署名鍵で署名されたものですので、ログ（/var/log/shibboleth/shibd.log）でメタデータのダウンロードが行われているか、ダウンロードURLが ?generation=2 付きになっているかを確認してください。

7NVe3mIUWLcYEtdbC8Ip5OA2TXvA
</ds:X509Certificate>

また、エラーログ（/var/log/shibboleth/shibd_warn.log）に以下のように記録されている場合は署名検証に失敗しておりますので、shibboleth2.xmlの証明書ファイルの指定が -2017 のほうになっているか、および上述の証明書のフィンガープリントを今一度確認してください。

2017-11-16 14:19:44 WARN OpenSAML.MetadataFilter.Signature : filtering out group at root of instance after failed signature check: CredentialResolver did not supply any candidate keys.

...

Procedure for Changing the SP Configuration to Use New GakuNin Signing Certificate

As new federation metadata signed by a new signing key and corresponding certificate were released, please change the configuration according to the procedure outlined here.

Download the new signing certificate from the URL below and place it in: /etc/shibboleth/cert/gakunin-signer-2017.cer
https://metadata.gakunin.nii.ac.jp/gakunin-signer-2017.cer

...

notice:The following description is diff format.

Edit /etc/shibboleth/shibboleth2.xml as follows:

1. Amend the metadata URL for <MetadataProvider> as follows: 
   

   コード ブロック
   language xml

...

1. <MetadataProvider type="XML" validate="true"

...

1. - uri="https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml"

...

1. + uri="https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml?generation=2"

...

...

1. backingFilePath="federation-metadata.xml" reloadInterval="7200">

...

1. (...

...

1. ...)

...

2. Amend the certifiate for <MetadataFilter> as follows:
   

   コード ブロック
   language xml
   <MetadataProvider type="XML" validate="true"

...

1. (...

...

1. ...)

...

...

1. backingFilePath="federation-metadata.xml" reloadInterval="7200">

...

1. - <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2010.cer"/>

...

1. + <MetadataFilter type="Signature" certificate="/etc/shibboleth/cert/gakunin-signer-2017.cer"/>

...

1. (...

...

1. ...)

...

1. </MetadataProvider>

Restart shibd and refresh the configuration.

(For CentOS 7)

3. shibdを再起動し、設定を再読み込みします。

  (CentOS 7の場合)
  $ sudo systemctl restart shibd

(For CentOS (CentOs 6の場合6)
  $ sudo service shibd restart

After a sufficient amount of time, please make sure that the signed metadata with the new signing key is downloaded.
It is success that just before the first match "</ds:X509Certificate>" of the GakuNin metadata backing file (/var/cache/shibboleth/federation-metadata.xml or similar) is as follows:

$ grep -B 1 "/ds:X509Certificate" /var/cache/shibboleth/federation-metadata.xml | head -n 2
nwU/H9ROp1cl
</ds:X509Certificate>

 If it looks like as follows, it is the metadata with a signature by the OLD signing key. You should check the log file to confirm that a metadata was downloaded and also check your configuration of download URL has a query string "?generation=2".

7NVe3mIUWLcYEtdbC8Ip5OA2TXvA
</ds:X509Certificate>

 Furthermore, if your log file (/var/log/shibboleth/shibd_warn.log) has following lines, it failed signature verification. You should check that your configuration of certificate path contains  "-2017" and also check the fingerprint of the certificate again.

2017-11-16 14:19:44 WARN OpenSAML.MetadataFilter.Signature : filtering out group at root of instance after failed signature check: CredentialResolver did not supply any candidate keys.